> 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

Reply via email to