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

[Jonathan Lennox <[e-mail]>]

On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé <[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.

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