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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 6 Nov 2001 01:58:38 -0500

> -----Original Message-----
> From: Shan Lu [mailto:[email-masked]]
> Sent: Friday, November 02, 2001 12:03 PM
> To: 'Bob Penfield'; 'IETF SIP Mailing List'
> Subject: RE: [Sip] Bis-05 question: CANCEL -- Proposed solution
> 
> > I don't see having the called party's phone ring a few 
> > seconds longer when
> > there is congestion to be all that much of the problem. How 
> > many times have
> > you picked up your ringing phone and said "hello" and there 
> > is no one there?
> > It has happened to me twice this week and I don't get that 
> > many calls. I
> > don't blame the telephone company, I just figure the calling 
> > party hung up.
> > 
> 
> 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.

> 2) In absence of 100 Trying (which some people may have very 
> good reason
> that UAS shouldn't send right away),

If a 100 is not sent right away, then that means some other response IS sent
right away. Whats the difference?

> you are guaranteed to ring the
> callee phone EVERY SINGLE time an INVITE goes out, even if 
> caller hangs
> up right away.

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.

> > 
> > The UAC is required to be re-transmitting the INVITE until it 
> > gets a 1xx.
> > Now you want it to keep retransmitting the CANCEL too? Sounds 
> > like you're
> > doing twice the work.
> 
> The UAC is required to have a FSM for CANCEL in any case. 
> With this mod,
> that state machine just remains in the "Proceeding" state a 
> bit longer.

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.

-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: Tue, 6 Nov 2001 11:31:14 -0500

Hi,

> could be lost, but the CANCEL itself could also be lost, so I 

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.  

> 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. 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. 

> 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.

Regards,

Shan Lu
sentitO Networks