Subject: RE: [Sip] Bis-05 question: CANCEL -- Proposed solution

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 16:41:58 -0500

> -----Original Message-----
> From: Shan Lu [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 11:31 AM
> To: 'Jonathan Rosenberg'; 'IETF SIP Mailing List'
> Subject: RE: [Sip] Bis-05 question: CANCEL -- Proposed solution
> 
> 
> Hi,
> 
> > > I'd like to point out two facts with wait-for-1xx: 1) the 
> > > phone could be
> > > ringing much longer than a few seconds after the caller has 
> > > hung up and
> > 
> > How is that? The first server transaction will generate some kind of
> > response (1xx or the final response) pretty much immediately. 
> > Sure, this
> > could be lost, but the CANCEL itself could also be lost, so I 
> > don't see the
> > difference.
> > 
> 
> The first server along the route is entirely irrelevant. The 1xx
> response from the UAS (which is the last server) must be 
> received by the
> previous-hop stateful proxy or UAC before the CANCEL can be 
> sent to the
> UAS on the last hop. Remember SF proxy must also follow the
> wait-for-1xx-then-CANCEL rule.  

OK, so what? I still don't see how this implies that the phone will ring for
any substantial amount of time. The phone starts ringing when the UAS gets
the INVITE; it sends the 1xx, and then the previous hop proxy can send the
cancel. This will be some number of milliseconds. 

> > Maybe I missed something, but isn't the point of sending an 
> > INVITE to ring a
> > phone? Sure, people can change their mind, but it is not 
> reasonable to
> > expect that they will be able to beat out the network and end 
> > up not causing
> > the phone to ring. This expectation does not exist in the 
> PSTN today.
> 
> But the PSTN does NOT ring the phone each and every time a 
> user dials a
> number and then immediately hangs up. That's what would 
> happen when you
> wait-for-1xx-then-cancel. 

As Keith and others have pointed out, this is NOT the case in the PSTN. The
PSTN will have this exact problem.

> By the time the 1xx is received by the SF
> proxy or UAC, assuming it's not 100 Trying, the callee phone 
> has already
> started to ring. It's true that CANCEL itself may be lost or 
> the caller
> may just hang up too late. But I don't think the protocol should be
> designed in such a way that it is guaranteed to cause 
> user-objectionable
> scenario and just hope user will put up with it. 

I think user expectation is that if you dial the phone and then hangup, the
far end phone may briefly ring and then stop. 

> 
> > I strongly object to your proposal. We have worked hard in 
> > bis-05 to have a
> > set of state machines which work in both proxies and UAs. The 
> > goal is to
> > eliminate special cases for transaction machines, which was the case
> > previously in proxies (2xx not retransmitted, ACK not sent). 
> > What you are
> > proposing is to define YET ANOTHER transaction machine that 
> is method
> > specific. I think we have had enough of that, thank you.
> > 
> 
> Let me point out that of the two modifications that I 
> proposed, only one
> requires FSM change for CANCEL (i.e., a 481 does not put FSM in
> "completed" state). The other (i.e., CANCEL is handled statelessly at
> server side if no matching INVITE) is not new and SF proxy already
> follows this and does not change FSM at all. If you really 
> want to keep
> FSM intact, then the transaction user can destroy CANCEL FSM upon 481
> response at the client side and resend CANCEL. In that case, no FSM
> change is required.

This in itself is a change in behavior, since the client FSM is supposed to
stick around for a little to absorb additional response retransmissions. 

I still think this is much ado about nothing. The treatment that is
prescribed in bis is no different than the way any other signaling protocol
that runs on an ordered transport would operate. System behavior is no
different than the PSTN. It is consistent with the transaction models
already defined an in operation.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 12 Nov 2001 09:55:27 -0500

Hello,

> PSTN will have this exact problem.

No matter what has been said about PSTN, the simple fact is the phone
doesn't ring if the caller hangs up quickly. Try it for yourself.  If
you can not conclude one way or the other because the PSTN setup time
tends to be very short and leaves little room for user to "change mind",
then make a call between your desktop phone and cell phone. There you
have around one second to hang up before the phone starts to ring. This
actually brings up the point that wait-for-1xx-then-cancel will be even
more objectionable in a network where call setup is slow -- the caller
would hang up and one second later (or however long the call setup
takes) the callee phone would ring. If I'm a service provider/user, this
would bother me very much.

Regards,

Shan Lu
sentitO Networks