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
