Well, the first branch is disposed of with a 5xx reply. But the UAC cancels
nothing, in spite of getting two different early responses from two different
dialogs.
Granted, I haven't tried waiting around for 3 minutes or whatever the maximum
prescribed early/alerting state is.
On July 16, 2018 6:24:35 PM EDT, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
>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
-- Alex
--
Sent via mobile, please forgive typos and brevity.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
