It should be noted that the UA with which I am testing (Freeswitch) does
not CANCEL or otherwise hang up the first dialog.
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
--
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
