Hi Jeroen Looking at your comment, I have a doubt.
Being a B2BUA, the ingress leg and egress leg are completed independent where the incoming call is terminated on B2BUA and a new call is initiated on the egress leg. So the forking on the egress leg shouldn't be transparent on the ingress leg. With regards Vivek Gupta Jeroen van Bemmel wrote: > 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 > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
