On 7/16/18 2:00 PM, Alex Balashov wrote:
It should be noted that the UA with which I am testing (Freeswitch) does
not CANCEL or otherwise hang up the first dialog.
In this case, since the proxy did the forking, it SHOULD (MUST?) send a
CANCEL. So it will probably be ok.
Thanks,
Paul
On Mon, Jul 16, 2018 at 01:56:34PM -0400, Alex Balashov wrote:
Oh, yes — they're different dialogs, for sure. I just wasn't sure if
that would nevertheless pose a problem for some low-budget UAs.
On Mon, Jul 16, 2018 at 01:47:32PM -0400, Paul Kyzivat wrote:
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
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
