> Has anyone else faced this problem before? > If yes, how did you solve it?
The finalized offer/answer text mentioned within rfc3261, rfc3262, rfc3263, rfc3311, rfc3959, and rfc3960 introduces restrictions upon B2BUAs which previously handled the forking complications so that the caller did not have to support forking proxies. To comply and for other early dialog reasons, the B2BUA should provide different To tags within the responses to simulate what would occur if it were a forking proxy. And unfortunately as discussed within the following thread, there still isn't an easy way for a proxy to indicate that one of the early dialogs has been released. https://lists.cs.columbia.edu/pipermail/sip-implementors/2005-November/0 10928.html And for completeness... in some situations, the B2BUA potentially could make use of 100rel and UPDATE instead of changing To tags (simulating a forking proxy). However this can introduce extra complications. Some of these are discussed within the following thread. http://www1.ietf.org/mail-archive/web/sip/current/msg13240.html > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Umesh > Sent: Wednesday, November 08, 2006 11:24 AM > To: [email protected] > Subject: [Sip-implementors] Clarification on offer/answer > > > Hello All, > We have a B2BUA server which needs to support a > particular call flow. > The initial set up call flow is as shown > > > CALLER B2BUA CALLEE1 > CALLEE2 > |--------INVITE(SDP1)-->| | | > > | |-------INVITE(SDP1)--->| | > | |<--------180(SDP2)-----| | > |<-------180(SDP2) -----| | | > | |<---------4xx ---------| | > | |----------ACK----------| | > | |-------INVITE(SDP1)------------------->| > | |<------180(SDP3)-----------------------| > | | | > > > The flow here is of sequential routing wherein if one user is > not responding then the next number configured has to be > tried until one person answers. > But as you can see the issue with the flow is that the 180 > with SDP3 cannot be forwarded to the caller directly. > As per rules of RFC 3261,3262 as I understand when a reliable > provisional response contains a session description, and is > the first to do so, then that session description is the > answer to the offer in the INVITE request. > SDP should not be included in the subsequent 1xx-rel once > offer/answer has been completed. > > Due to this we cannot refresh the SDP to the caller. Even use > of UPDATE would result in a race condition. > > Please let me know if there is a solution to update the SDP( > SDP3) on the caller side. Is there any other way of handling > this situation? > > Thanks and Regards, > Umesh _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
