So, it boiling down to be 'implementation specific' behavior :)
But, I guess the original question from Ramachandran is answered i.e. the
proxy should forward all forked 18x responses to the INVITE originator
irrespective of (or waiting for) the call to get answered on any of the
forked leg.
Rama, does this answer your question?
Thanks,
Arun.
On Wed, 30 Mar 2016 19:58:42 +0530, Olle E. Johansson <o...@edvina.net>
wrote:
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
--
Using Opera's mail client: http://www.opera.com/mail/
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
