Hi Umesh, Proxy behaviour is defined very clearly in 3261. It says that only the BEST error response and only ONE 1XX/2XX response is to be passed back to the UAC.
In your example, however, you talk about a B2BUA. There are really no rules that define how a B2BUA should behave. Hence I think that the defined behaviour would be application specific. Let's make the following assumptions 1) The SDP in the 180 ringing would play the RBT from the remote (Note, this could also be a remote RBT) 2) CALLEE1 and CALLEE 2 are NOT automata and there is actually someone who would answer the call Taking the assumptions made above into consideration, it doesn't make sense to forward SDP3 to the caller. It would be a weird user experience to suddenly start hearing a different ring back tone. In this scenario, I would assume that you could ignore SDP3 and renegotiate SDP's after CALLEE2 answers. To make sure that the remote side doesn't start transmitting RTP as soon as it receives an INVITE, it would be prudent to send the initial offer to both callees with a hold SDP. If CALLEE1 was an automaton like a Media Server, then I would assume that the INVITE would be answered immediately with a 200 OK and you have no problems here. What I am basically trying to say is that your flow would be specific to the application that you are developing. Has anyone else faced this problem before? If yes, how did you solve it? HTH, Darshan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Umesh Sent: Wednesday, November 08, 2006 11:24 AM To: sip-implementors@cs.columbia.edu 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 Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
