On 7/16/18 1:17 PM, Alex Balashov wrote:
Hi,
I have a scenario where a call is forked through a proxy to an early
media announcement server and then subsequently to a SIP provider for
actual termination.
Due to the way the RTP relay works on the server side, this results in
two different SDP offers from the two respective outgoing branches being
sent back to the caller:
1. 183+SDP on branch #1.
2. 183+SDP' on branch #2.
200 OK+SDP' on branch #2.
These are both sent back to the UAC?
If so, these should arrive with different to-tags, and so will establish
distinct early dialogs. Those can coexist. Then when the 200 arrives,
(regardless of which dialog it comes on), the UAC should send a CANCEL
on the other dialog (to the Contact URI for that dialog. Or it can send
a BYE.
There is a race condition where you get a 200 on *both* early dialogs.
In that case you have two separate calls to deal with. Then you can send
a BYE on one of them, or manage them both separately, or treat them as a
conference, or whatever you want.
OTOH, if perchance the two 183 responses have the *same* to-tag, then
you have an error situation.
Thanks,
Paul
I am not sure offhand whether this is a protocol semantics violation. On
the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
So, I always understood that the first answer is the final answer,
absent a session-updating request cycle. On the other hand, RFC 3960
("Early Media and Ringing Tone Generation in the Session Initiation
Protocol (SIP)") Section 4 says:
The application server model consists of having the UAS behave as an
application server to establish early media sessions with the UAC.
The UAC indicates support for the early-session disposition type
(defined in [2]) using the early-session option tag. This way, UASs
know that they can keep offer/answer exchanges for early media
(early-session disposition type) separate from regular media (session
disposition type).
I take this, along with RFC 3959 Section 3, to imply an amendment to
3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
will handle this situation.
Any insight would be appreciated!
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
