Umesh, 180(SDP2) and 180(SDP3) should have different to-tags, so for the CALLER they are two distinct dialogs. Forwarding 180(SDP3) would not be a refresh, but an initial answer for a second dialog. Your B2BUA can safely forward 180(SDP3)
A different question is whether the CALLER UA properly supports responses from multiple callees. If not, your B2BUA will have to do the honors: hold the SDP until a 2xx response is received (forward ringing responses from a single callee, stripping the SDP body), then continue with the dialog that succeeds. There are limits to this solution however, it gets complicated when 100rel is used for example. Better to take a proper caller UA Regards, Jeroen Umesh wrote: > 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 > > > **************************************************************************** > *********** > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, > please notify the sender by phone or email immediately and delete it! > > > _______________________________________________ > 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
