Subject: RE: [SIP] :BYE for pending INVITE was Further editorial nit in th e bis draft

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Apr 2001 13:28:30 -0400

> -----Original Message-----
> From: Vijay Gurbani [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2001 10:39 AM
> To: Arunachalam Venkatraman
> Cc: [email-masked]
> Subject: Re: [SIP] :BYE for pending INVITE was Further 
> editorial nit in
> the bis draft
> 
> 
> Arunachalam Venkatraman wrote:
> > 
> > If the INVITE was responded to with 100 Trying (thus disabling
> > retransmissions) and the BYE with 200 OK (since the INVITE has not
> > completed), the UAS and the proxies en-route would have 
> cleared the call 
> > on receipt of the 200 OK to the BYE. What is the value of 
> the 487 to 
> > INVITE ? Other than the protocol rule that each transaction 
> completes 
> > independently. Is there going to be any stack that will be 
> upset if the 
> > 487 is not sent in this case?
> 
> I would be careful about making too many assumptions here.  
> There maybe
> call-stateful proxies that may have allocated some resources 
> on proxying
> the INVITE transaction.  These proxies will need a final 
> response (even a 
> non-200 one) from the UAS in order to release the resources.  
> These proxies 
> may never see a BYE since they R-R but R-R does not take 
> effect on a non-2xx 
> response to the INVITE (except on certain 4xx responses -- 
> namely 401 Un-
> authorized and 484 Address Incomplete; 487 is not one of them).

Let me make a bit of a stronger statement than Vijay has.

Arunachalam has made a statement above which I hear often, and which is a
very, very wrong statement:

>If the INVITE was responded to with 100 Trying (thus disabling
>retransmissions) and the BYE with 200 OK (since the INVITE has not
>completed), the UAS and the proxies en-route would have 
>cleared the call 
>on receipt of the 200 OK to the BYE

Proxies as TRANSACTIONAL elements. Their default operation is to not know
about calls or call state. There is nothing in rfc2543 about a proxy
"clearing call state". Proxies are not the same as switches. THey are not
the same as gatekeepers. Because of their transactional nature, and because
of the transactional nature of SIP, we have the golden rule, or "mantra", of
SIP, which is worth repeating three times for its importance:

All transactions complete independently.
All transactions complete independently.
All transactions complete independently.

Without this, state maintenance in proxies is a nightmare. Whenever in doubt
about some aspect of SIP operation, recite this mantra, and see if it
doesn't answer the question.

Specifically, it is because of this golden rule that we now require a
cancelled request to be responded to with a 487. Why? To clear transaction
state in proxies.

-Jonathan R.
---
Jonathan D. Rosenberg                       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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.