That's great Uttam Da, Raikkme:
A UA compliant to RFC-3261 can not send BYE on early dialog as pointed by Uttam. But rfc3261 does allow for handling the calls from devices compatible with prior specification rfc-2543. So could you clarify whether your UA-A and UA-B are not compliant to RFC-3261, but are expecting backward compatibility to rfc-2543 and thus sending BYE method in early dialog or 180 without contact header ?? Even then if the B2BUA is compliant to rfc-3261, then I recommend you change the BYE rcvd from UA-A to a CANCEL towards UA-B and release the call This way the B2BUA can maintain backward compatibility with rfc2543 as recommended in rfc-3261. Regards, Indresh K Singh >>-----Original Message----- >>From: ext Uttam Sarkar [mailto:[email protected]] >>Sent: Tuesday, August 18, 2009 3:49 PM >>To: Singh, Indresh (NSN - US/Boca Raton); ext raikkme rrrrr; >>[email protected] >>Subject: RE: [Sip-implementors] 18X response with no Contact Header >> >> >> >>As per page 258 of RFC 3261(28.1 Major Functional Changes) >> >> o A UA cannot send a BYE for a call until it has received an ACK for >> the initial INVITE. This was allowed in RFC 2543 but leads to a >> potential race condition. >> >>-----Original Message----- >>From: Singh, Indresh (NSN - US/Boca Raton) >>[mailto:[email protected]] >>Sent: Tuesday, August 18, 2009 3:32 PM >>To: Uttam Sarkar; ext raikkme rrrrr; >>[email protected] >>Subject: RE: [Sip-implementors] 18X response with no Contact Header >> >>Uttam Da, >> >>As per Section 15 Terminating a session Pg 89 >> >>A caller's UA MAY send a BYE for either confirmed or early dialogs and >>the callee's UA MAY send a BYE on confirmed dialogs, but MUST >>not send a >>BYE on early dialogs. >> >>In our implementations we normally send CANCEL on the early >>dialogs, but >>as per RFC section above sending BYE is allowed on early dialogs from >>the caller side. >> >>Best Regards, >> >>Indresh K Singh >> >>>>-----Original Message----- >>>>From: ext Uttam Sarkar [mailto:[email protected]] >>>>Sent: Tuesday, August 18, 2009 3:00 PM >>>>To: Singh, Indresh (NSN - US/Boca Raton); ext raikkme rrrrr; >>>>[email protected] >>>>Subject: RE: [Sip-implementors] 18X response with no Contact Header >>>> >>>>You will not be able to send BYE as call is not yet connected. >>>>You can send CANCEL to the INVITE. >>>> >>>>-----Original Message----- >>>>From: [email protected] >>>>[mailto:[email protected]] On Behalf Of >>>>Singh, Indresh (NSN - US/Boca Raton) >>>>Sent: Tuesday, August 18, 2009 2:43 PM >>>>To: ext raikkme rrrrr; [email protected] >>>>Subject: Re: [Sip-implementors] 18X response with no Contact Header >>>> >>>>Assuming that your call-flow is like >>>> >>>>UA-A B2BUA >>>>UA-B >>>> >>>>INVITE ----------------------------> >>>>INVITE-----------------------------> >>>> >>>> 180 >>>>without contact <-------------- >>>>180 with contact<--------------- >>>> >>>>BYE -----------------------------> >>>>BYE---------------------------------> >>>> >>>> >>>>The BYE on the A-side of the call-leg should be sent based on the >>>>contact header present in 18x. >>>> >>>>BYE to be sent from B2BUA is little open question as >>suggested in the >>>>previous responses, that it would be invalid for UA-B to send a 180 >>>>ringing response without contact based on reference from >>section 12.1 >>>>and 12.1.1 ( if 180 had a to-tag, then the UA must include a contact >>>>header ). >>>> >>>>If it was a CANCEL method, then the CANCEL would have >>>>followed the same >>>>path as initial INVITE ( contact header would have been >>>>irrelevant ) and >>>>normally in this initial setup phase of the call ( ringing ) >>>>a CANCEL is >>>>commonly used instead of BYE, but definitely BYE is allowed >>to be sent >>>>on early dialogs. So question is how do we send a BYE to UA-B on an >>>>early dialog where the UA-B never provided the contact header >>>>information in 180 response ( to be saved in the dialog >>>>remote target ) >>>>and release the call. If sending a BYE is mandatory, then I >>>>think we can >>>>send it to same address where we sent the initial INVITE. But since >>>>there is a B2BUA involved here and in B2BUA each side is >>>>independent, so >>>>even if UA-A sends a BYE to B2BUA, the B2BUA can send a >>CANCEL method >>>>towards UA-B to release the call which is in early dialog stage. >>>> >>>>Please note that for simple case sending BYE on the same path >>>>as INVITE >>>>may seems fine. But if proxies were involved between B2BUA >>>>and UA-B and >>>>the call was forked, then if one sends the BYE based on the initial >>>>INVITE data ( no contact in 18x ), then I am not sure how >>the proxies >>>>would have forwarded BYE ... >>>> >>>>But if we would have sent CANCEL towards UA-B there would >>not have any >>>>issue, as it is hop to hop and CANCEL is sent based on >>initial INVITE. >>>>So I would recommend below call-flow if feasible. >>>> >>>>UA-A B2BUA >>>>UA-B >>>> >>>>INVITE ----------------------------> >>>>INVITE---------------------------------> >>>> >>>> 180 >>>>without contact <----------------- >>>>180 with contact<--------------- >>>> >>>>BYE -----------------------------> CANCEL >>>>---------------------------------> >>>> >>>>Regards, >>>> >>>>Indresh K Singh >>>> >>>>>>-----Original Message----- >>>>>>From: [email protected] >>>>>>[mailto:[email protected]] On >>>>>>Behalf Of ext raikkme rrrrr >>>>>>Sent: Tuesday, August 18, 2009 12:03 PM >>>>>>To: [email protected] >>>>>>Subject: Re: [Sip-implementors] 18X response with no >>Contact Header >>>>>> >>>>>>Hi Indresh, >>>>>>Just one small clarification. As the entity behaves as B2B, >>>>>>18x is sent >>>>>>towards A side with contact header(B2B's address), after >>>>receiving 18x >>>>>>without contact header from B side. >>>>>> >>>>>>Query is that, how the release from A side(as indicated in >>>>>>the picture) to >>>>>>be treated? Or 18x from A side, at first place, should be >>discarded? >>>>>> >>>>>>Thanks, >>>>>>kumar >>>>>> >>>>>>On Tue, Aug 18, 2009 at 8:04 PM, Singh, Indresh (NSN - >>>>>>US/Boca Raton) < >>>>>>[email protected]> wrote: >>>>>> >>>>>>> Still the figure is not very clear. >>>>>>> >>>>>>> But as Vikram pointed out that contact header is an >>>>>>optional header in >>>>>>> 1xx responses. If no contact header is present in 1xx >>>>>>response then if a >>>>>>> method has to be sent out immediately after this 1xx >>>>>>response ( prior to >>>>>>> receiving another response with contact header ) then the >>>>>>message will >>>>>>> be routed back to the same location where the initial >>>>>>INVITE was sent >>>>>>> out ( assuming no record-route is involved, since you >>mentioned RR >>>>>>> below. For RR case we need more info as in that case the >>>>>>routing will >>>>>>> happen based on route set built based on RR present in 1xx >>>>>>responses and >>>>>>> also the type of RR LooseRoute or no LooseRoute ). >>>>>>> >>>>>>> Based on your figure below it seems that you rcvd a 18x >>>>>>without contact >>>>>>> and then you rcvd a 18x with contact and then a BYE is >>>>being sent by >>>>>>> originator. In that case BYE should be sent based on the >>>>>>latest contact >>>>>>> header information received in 18x header ( if any assuming >>>>>>> Record-Routing is not involved ). >>>>>>> >>>>>>> I also do not think that it is mandatory for the case of >>>>>>even reliable >>>>>>> 18x response as well. I do not think if a 18x response >>is received >>>>>>> without contact header a PRACK request can not be >>>>>>constructed. Vikram >>>>>>> could you kindly explain why would this be the case as >>>>>>mentioned below >>>>>>> ?? >>>>>>> >>>>>>> >>> a unreliable 18x response without Contact as it is optional. >>>>>>> >>> It is definitely needed in a reliable 18x as without it, a >>>>>>> >>UAC can not >>>>>>> >>> construct a PRACK request. In this case, 18x will >>>>>>timeout and the >>>>>>> >>> early dialog will be terminated. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Indresh K Singh >>>>>>> >>>>>>> >>-----Original Message----- >>>>>>> >>From: [email protected] >>>>>>> >>[mailto:[email protected]] On >>>>>>> >>Behalf Of ext raikkme rrrrr >>>>>>> >>Sent: Tuesday, August 18, 2009 12:27 AM >>>>>>> >>To: [email protected] >>>>>>> >>Subject: Re: [Sip-implementors] 18X response with no >>>>>>Contact Header >>>>>>> >> >>>>>>> >>I tried to translate the picture in notepad. I hope, it >>>>>>is received as >>>>>>> >>intended. Please find below. >>>>>>> >> >>>>>>> >>A >>>>>>> >>side >>>>>>> >>B side >>>>>>> >> ______________ >>>>>>> >>---------------------------------> | B | >>>>>>> >>Invite | >>>>>>> >>|-------------------------------> Invite >>>>>>> >> | >>>>>>> >>|<------------------------------ 100 Trying >>>>>>> >><--------------------------------- | | 18x >>>>>>> >>without contact >>>>>>> >>header >>>>>>> >>100 Trying | 2 >>>>>>> >>|<------------------------------ >>>>>>> >> | | >>>>>>> >><--------------------------------- | | >>>>>>> >>18x with contact | | >>>>>>> >>---------------------------------->| B >>>>>>> >>|---------------------------------> ???????? >>>>>>> >>BYE | | >>>>>>> >> >>>>>>> >> >>>>>>> >>18x from B side received without contact header. 18x response >>>>>>> >>has "To tag" >>>>>>> >>and without Record Route. >>>>>>> >> >>>>>>> >>Thanks, >>>>>>> >>kumar >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >>On Mon, Aug 17, 2009 at 11:24 PM, Vikram Chhibber >>>>>>> >><[email protected] >>>>>>> >>> wrote: >>>>>>> >> >>>>>>> >>> We can not see the attachment. A UAC should have no problem >>>>>>> >>processing >>>>>>> >>> a unreliable 18x response without Contact as it is optional. >>>>>>> >>> It is definitely needed in a reliable 18x as without it, a >>>>>>> >>UAC can not >>>>>>> >>> construct a PRACK request. In this case, 18x will >>>>>>timeout and the >>>>>>> >>> early dialog will be terminated. >>>>>>> >>> On Wed, Aug 12, 2009 at 3:03 AM, raikkme >>>>>>> >>rrrrr<[email protected]> >>>>>>> >>> wrote: >>>>>>> >>> > What should be the behaviour, in case 18X response is >>>>>>> >>received with no >>>>>>> >>> > Contact header for the below case? >>>>>>> >>> > >>>>>>> >>> > Please refer the attached document for sample scenario. >>>>>>> >>> > >>>>>>> >>> > The entity is behaving as a B2B, where BYE is received >>>>>>> >>from one side. >>>>>>> >>> > >>>>>>> >>> > Thanks, >>>>>>> >>> > kumar >>>>>>> >>> > >>>>>>> >>> > _______________________________________________ >>>>>>> >>> > Sip-implementors mailing list >>>>>>> >>> > [email protected] >>>>>>> >>> > >>>>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>>> >>> > >>>>>>> >>> >>>>>>> >>_______________________________________________ >>>>>>> >>Sip-implementors mailing list >>>>>>> >>[email protected] >>>>>>> >>>>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>>> >> >>>>>>> >>>>>>_______________________________________________ >>>>>>Sip-implementors mailing list >>>>>>[email protected] >>>>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>> >>>> >>>>_______________________________________________ >>>>Sip-implementors mailing list >>>>[email protected] >>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>> >> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
