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

[Peter Saint-Andre - &yet <[e-mail]>]

On 3/26/14 9:50 AM, Jonathan Lennox wrote:
>
> On Mar 25, 2014, at 6:12 PM, Peter Saint-Andre <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>> On 3/25/14, 12:03 PM, Jonathan Lennox wrote:
>>>
>>> On Mar 25, 2014, at 1:37 PM, Emil Ivov <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>> On 25.03.14, 15:15, Jonathan Lennox wrote:
>>>>>
>>>>> On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé
>>>>> <[e-mail] <mailto:[e-mail]>> 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.
>
> 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.

Peter

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