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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Mar 2014 21:45:30 -0600

Once again, my apologies for the slow reply.

On 1/9/14, 10:31 AM, Jonathan Lennox wrote:
> I was thinking about the issue that unlike RFC 5245, XEP-176's
> definition of ICE doesn't support fallback to a non-ICE mode.

Correct.

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

> My concern, though, is whether there are a) endpoints that implement
> RFC 5245 but not RFC 5768, or b) non-media-terminating B2BUAs that
> will pass ICE parameters through, but will reject calls with Require
> headers they don't know.  In either of these cases, adding this
> Require header would cause a call that would otherwise have worked to
> fail.

That would be bad.

> Any thoughts, especially from folks who know the state of deployed
> SIP better than I do?

Inquiring minds want to know. :-)

Peter

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 25 Mar 2014 09:55:20 +0100

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

> Inquiring minds want to know. :-)

FWIW, in Blink we do use the option tag in the Contact header but we don't add the Requires header, since we can work fine without ICE. Can't say what SBCs do though...

--
Saúl Ibarra Corretgé
AG Projects

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 25 Mar 2014 14:15:46 +0000

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

> FWIW, in Blink we do use the option tag in the Contact header but we don't add the Requires header, since we can work fine without ICE. Can't say what SBCs do though…

When you say “can work fine without ICE”, do you mean you support full RFC 5245 fallback to the use of the m/c line for media?  That does indeed sound like the case when you should have the Contact tag but not the requires header.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 25 Mar 2014 18:37:21 +0100

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

Emil

-- 
https://jitsi.org

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 25 Mar 2014 18:03:55 +0000

On Mar 25, 2014, at 1:37 PM, Emil Ivov <[email-masked]> wrote:

> There's also "XEP-0177: Jingle Raw UDP Transport Method" which is basically equivalent to ICE-less SIP.
> 

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.

RFC 5768 allows a signaling-only XMPP-to-SIP gateway to (mostly) express the XMPP semantic that ICE is required, with no fallback supported.  However, using it would mean failures if you hit a device that supports (or passes) RFC 5245 but not RFC 5768.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 25 Mar 2014 19:12:10 +0100

> RFC 5768 allows a signaling-only XMPP-to-SIP gateway to (mostly) express the XMPP semantic that ICE is required, with no fallback supported.  However, using it would mean failures if you hit a devi…

Agreed!

-- 
https://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Mar 2014 16:12:29 -0600

On 3/25/14, 12:03 PM, Jonathan Lennox 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.
>>>>>
>>>> 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, 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

Peter

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 26 Mar 2014 12:09:24 +0100

> Right, of course.  I was talking about how you’d want to handle a signaling-only gateway.

Ah, by bad, sorry. As Peter pointed out there is a fallback mechanism, so if the Jingle endpoint advertised support for raw UDP it should be possible to fallback. In case it didn't there is nothing that can be done.

> When you say “can work fine without ICE”, do you mean you support full RFC 5245 fallback to the use of the m/c line for media?  That does indeed sound like the case when you should have the Contact…

Yep.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 26 Mar 2014 15:50:16 +0000

On Mar 25, 2014, at 6:12 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 25, 2014, at 1:37 PM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé
<[email-masked]<mailto:[email-masked]>> wrote:

Right, of course.  I was talking about how you’d want to handle a
signaling-only gateway.

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:

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.