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

[Jonathan Lennox <[e-mail]>]

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                  |
  |<=================================================>|
  |                         |                         |



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.