Hi Vivek, Yes, that *can be* a function of a B2BUA. Whether or not it is a requirement here is unclear, Umesh did not share those details. Since his call flow was showing forwarded 180s from multiple callee's, I assumed that forking transparency was not required.
It is also still unclear what requirement makes it a B2BUA instead of a proxy Regards, Jeroen Vivek Gupta wrote: > 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
