> On 30 Mar 2016, at 16:08, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > > On 3/30/16 2:58 AM, Arun Arora wrote: >> On Sun, 20 Mar 2016 23:32:44 +0530, Paul Kyzivat <pkyzi...@alum.mit.edu> >> wrote: >> >>> On 3/20/16 12:26 PM, Neelakantan, Neel wrote: >>>> Please review RFC 3261. This is addressed in it. >>>> >>>> The provisional response must be forwarded by proxy to the UAC. >>>> >>>> The answer ( 200 OK) can be from any of the UAS and there is no way >>>> of Proxy knowing it. >>>> >>>> The UAC should be prepared to handle forked responses. >>> >>> Of particular note, you may get a 1xx that initiates early media from >>> one fork, and then a 2xx from a *different* fork. In that case you >>> must shift your processing to the media from the 2xx fork. >>> >>> You may also get 1xx responses from multiple forks, and early media >>> from more than one of them. You need to think hard how you want to >>> handle that, rather than being caught unaware. >>> >>> And this explicitly includes being prepared for getting multiple >>> forked 2xx responses. This will happen rarely if ever in many >>> deployments, but it is a possibility, and it is a bug not to handle >>> it. (You *may* simply send a BYE to any 2xx after the first, or you >>> can do something more sophisticated. But you must do *something*.) >> >> In my view, on getting the early media from more than one resource the >> UA should continue with the first early media response it processed. For >> rest there need to be some handling, for e.g. silently ignoring them as >> any of them can send a 2xx response. > > That is one approach. Another might be to always play out the one that > started most recently. Or, when you discover you have more than one you could > drop them all and play local ringback. Or, if you have the right capabilities > you might do speech to text and display all the text. Plenty of room for > innovation here. At SIPit we’ve set up tests for multiple early media streams and we have indeed seen a lot of different innovative solutions. And some bad, like sticking to the early media stream even after 200 OK.
/O > >> For multiple 2xx responses, its always a BYE after acceptance of first >> 2xx response. > > That is the *easy* (minimal) way. Again there are alternatives for those that > want to do a better job. E.g., > > - send a prerecorded message to the one you are dropping before dropping it. > > - conference all together. (This is a natural approach if the invite was a > callout from a conference mixer.) > > - monitor the audio from each one for a bit and try to figure out which one > to keep. Then drop the others. > > Thanks, > Paul > >> Thanks, >> Arun >> >> >>> >>> Thanks, >>> Paul >>> >>>> Thanks, >>>> >>>> Neel >>>> >>>> ________________________________________ >>>> From: sip-implementors-boun...@lists.cs.columbia.edu >>>> <sip-implementors-boun...@lists.cs.columbia.edu> on behalf of >>>> Ramachandran, Agalya (Contractor) <agalya_ramachand...@comcast.com> >>>> Sent: Tuesday, March 15, 2016 10:38:34 AM >>>> To: sip-implementors@lists.cs.columbia.edu >>>> Subject: [Sip-implementors] Query in handling 180 response by proxy >>>> >>>> Hi All, >>>> >>>> If an Invite request is received to a proxy, proxy then forks the >>>> Invite message to two destinations. >>>> 180 Ringing Response is received from both the destinations to the >>>> proxy. >>>> Proxy is now forwarding both 180 Response to the request originator. >>>> Is this right behavior of proxy or it should forward only the ringing >>>> response in which call leg it has been answered ? >>>> Can anyone clarify me on this.? >>>> >>>> Regards, >>>> Agalya >>>> _______________________________________________ >>>> Sip-implementors mailing list >>>> Sip-implementors@lists.cs.columbia.edu >>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> _______________________________________________ >>>> Sip-implementors mailing list >>>> Sip-implementors@lists.cs.columbia.edu >>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> >>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> >> > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors