Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice?

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 09 Mar 2015 15:13:29 -0600

On 2/24/15 9:38 PM, Peter Saint-Andre - &yet wrote:
> On 3/26/14 9:50 AM, Jonathan Lennox wrote:
>>
>> On Mar 25, 2014, at 6:12 PM, Peter Saint-Andre <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> On 3/25/14, 12:03 PM, Jonathan Lennox wrote:
>>>>
>>>> On Mar 25, 2014, at 1:37 PM, Emil Ivov <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>> On 25.03.14, 15:15, Jonathan Lennox wrote:
>>>>>>
>>>>>> On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé
>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> It occurred to me that SIP has a way of saying "do ICE, or
>>>>>>>>> fail the call": putting a "Require: ice" SIP option tag
>>>>>>>>> (from RFC 5768) in the SIP INVITE.
>>>>>>>>>
>>>>>>>>> Should we recommend this?  It clearly has the right
>>>>>>>>> semantics, and will prevent interop failure when a non-ICE
>>>>>>>>> SIP endpoint answers a XEP-176 Jingle call.
>>>>>>>>
>>>>>>>> Theoretically that makes sense.
>>>>>>>
>>>>>>> Agreed. Maybe a gateway could do ICE on behalf of the non-ICE
>>>>>>> capable endpoint, so can we say this is implementation specific
>>>>>>> and thus add a MAY to it?
>>>>>>
>>>>>> Right, of course.  I was talking about how you’d want to handle a
>>>>>> signaling-only gateway.
>>>>>
>>>>> There's also "XEP-0177: Jingle Raw UDP Transport Method" which is
>>>>> basically equivalent to ICE-less SIP.
>>>>>
>>>>> That said, I don't mind mandating ICE at all.
>>>>
>>>> Right, but there’s no way for a Jingle client to offer a choice
>>>> between XEP-176 and XEP-177, whereas RFC 5245 requires that both ICE
>>>> and fallback non-ICE be supported.
>>>
>>> Well, an XMPP initiator would not offer the ice-udp transport method
>>> if the responder didn't advertise support via XMPP service discovery
>>> (i.e., only advertised support for raw-udp). So, in general, fallback
>>> shouldn't really be necessary. However, we have defined a protocol
>>> flow for it just in case:
>>>
>>> http://xmpp.org/extensions/xep-0176.html#fallback
>>
>> The problem with that flow is the statement "Based on capabilities
>> information, the gateway knows that the SIP endpoint does not support
>> ICE”.  Unfortunately, SIP doesn’t really have any workable way of
>> providing capabilities information, which is why RFC 5245 (and so much
>> of the rest of SIP) is single-exchange fallback.

True.

>> An alternative flow is possible, where you only send the
>> transport-replace on the Jingle side if the SIP answer indicates no ICE
>> support, and then send a SIP re-INVITE with the addresses in the
>> transport-accept.  It’ll result a fairly substantial post-answer delay
>> before the media will get through, though.
>>
>> Here’s a sketch:
>>
>> Romeo                    Gateway                    Juliet
>>    |                         |                         |
>>    |   session-initiate      |                         |
>>    |   (audio definition)    |                         |
>>    |------------------------>|                         |
>>    |   ack                   |                         |
>>    |<------------------------|   SIP INVITE (ICE)      |
>>    |                         |------------------------>|
>>    |   transport-replace     |   200 OK (Raw UDP)      |
>>    |   (Raw UDP)             |<------------------------|
>>    |<------------------------|                         |
>>    |   ack                   |                         |
>>    |------------------------>|                         |
>>    |   transport-accept      |                         |
>>    |------------------------>|                         |
>>    |   ack                   |                         |
>>    |<------------------------|   SIP INVITE (Raw UDP)  |
>>    |                         |------------------------>|
>>    |                         |   200 OK (Raw UDP)      |
>>    |   session-accept        |<------------------------|
>>    |<------------------------|                         |
>>    |   ack                   |                         |
>>    |------------------------>|                         |
>>    |                    MEDIA SESSION                  |
>>    |<=================================================>|
>>    |                         |                         |
>>
>
> That seems reasonable but I'll give it more thought soon.
>
>> This flow also relies on the SIP side not changing its local IP address
>> and port in response to a re-INVITE with a changed address, or the XMPP
>> side not changing its in response to a transport-replace maintaining raw
>> UDP; otherwise, the gateway can get into an infinite
>> re-INVITE/transport-replace loop.
>
> Yes, we'll want to document those possibilities.

We didn't get to that yet because of the submission deadline, but the 
authors will discuss the remaining open issues soon (and I for one plan 
to do a complete review of the document and probably add a bunch of 
examples and call flows).

Peter

-- 
Peter Saint-Andre
https://andyet.com/