[jitsi-dev] ICE and TURN with non-ICE peer


#1

I'm just wondering about the way a UA with ICE+TURN support should
interact with a non-ICE peer

When the peer does not support ICE, the TURN-capable UA could still
potentially achieve connectivity if it uses it's relay candidate as
default candidate.

When the ICE UA receives a call (receives an offer), it will know
immediately that the peer is non-ICE, because the offer has no ICE
attributes. In this case, the UA can immediately set up the relay and
just assume worst case scenario.

But what about when the ICE capable UA is the caller? A few hacks come
to mind:

a) keep a cache of data on peers that don't support ICE, so the next
call to the peer will use relay by default

b) as soon as the call is setup (200 received), the caller does a
re-INVITE with relay

c) similar to (b), but the peer is slightly more clever - it waits 200ms
for incoming RTCP, if nothing comes in to prove that there is
connectivity, it does the re-INVITE via relay

Does anyone know of any other examples, or any official work on this
from IETF?


#2

Hey Daniel,

I'm just wondering about the way a UA with ICE+TURN support should
interact with a non-ICE peer

When the peer does not support ICE, the TURN-capable UA could still
potentially achieve connectivity if it uses it's relay candidate as
default candidate.

When the ICE UA receives a call (receives an offer), it will know
immediately that the peer is non-ICE, because the offer has no ICE
attributes. In this case, the UA can immediately set up the relay and
just assume worst case scenario.

But what about when the ICE capable UA is the caller?

What about that? Why do you see this case as problematic?

A few hacks come to mind:

a) keep a cache of data on peers that don't support ICE, so the next
call to the peer will use relay by default

Not necessarily a good idea. What if, in the mean time, the peer logs
in with an ICE capable agent?

b) as soon as the call is setup (200 received), the caller does a
re-INVITE with relay

Why do you need to reINVITE? If relay is what you want to do in such
cases, then why not start with the relay candidate as default?

c) similar to (b), but the peer is slightly more clever - it waits 200ms
for incoming RTCP, if nothing comes in to prove that there is
connectivity, it does the re-INVITE via relay

Risky. 200ms is far too short to cover all cases. Sometimes it takes
Jitsi more than a second to actually obtain data from the capture
devices. Besides, if data isn't coming then there's no real way of
knowing exactly what was the reason. Maybe local connectivity is gone.

Does anyone know of any other examples, or any official work on this
from IETF?

I believe 5245 is actually pretty specific about this:

   It is RECOMMENDED that default candidates be chosen based on the
   likelihood of those candidates to work with the peer that is being
   contacted. It is RECOMMENDED that the default candidates are the
   relayed candidates (if relayed candidates are available), server
   reflexive candidates (if server reflexive candidates are available),
   and finally host candidates.

Hope this helps,
Emil

···

On Wed, Jan 18, 2012 at 7:54 PM, Daniel Pocock <daniel@pocock.com.au> wrote:

--
http://jitsi.org


#3

Hey Daniel,

I'm just wondering about the way a UA with ICE+TURN support should
interact with a non-ICE peer

When the peer does not support ICE, the TURN-capable UA could still
potentially achieve connectivity if it uses it's relay candidate as
default candidate.

When the ICE UA receives a call (receives an offer), it will know
immediately that the peer is non-ICE, because the offer has no ICE
attributes. In this case, the UA can immediately set up the relay and
just assume worst case scenario.

But what about when the ICE capable UA is the caller?

What about that? Why do you see this case as problematic?

The following scenario:
- SIP proxy is SER, OpenSIPS or some other stateless proxy
- proxy owner wants to throw away rtpproxy/mediaproxy and just expect
everyone to use TURN
- some users still connect to the proxy using non-ICE user agents (e.g.
hard phones)

A few hacks come to mind:

a) keep a cache of data on peers that don't support ICE, so the next
call to the peer will use relay by default

Not necessarily a good idea. What if, in the mean time, the peer logs
in with an ICE capable agent?

Agreed - that's why I called this a list of `hacks' - they are just ideas

b) as soon as the call is setup (200 received), the caller does a
re-INVITE with relay

Why do you need to reINVITE? If relay is what you want to do in such
cases, then why not start with the relay candidate as default?

Yes, for case (b), as opposed to (c) below, using the relay candidate as
default seems like the way to go, and then if ICE is available it will
try to find a better solution

c) similar to (b), but the peer is slightly more clever - it waits 200ms
for incoming RTCP, if nothing comes in to prove that there is
connectivity, it does the re-INVITE via relay

Risky. 200ms is far too short to cover all cases. Sometimes it takes
Jitsi more than a second to actually obtain data from the capture
devices. Besides, if data isn't coming then there's no real way of
knowing exactly what was the reason. Maybe local connectivity is gone.

Yes, I agree it doesn't suit all situations. It is only an approximate
solution to avoid relay, definitely not bulletproof. However, if the UA
receives RTCP packets from the peer, then it can conclude that

- incoming packets are arriving
- depending upon the RTCP content, the UA can infer whether outgoing
packets were received by the peer

so if this was made to work somehow, it could reduce load on the relay.

Does anyone know of any other examples, or any official work on this
from IETF?

I believe 5245 is actually pretty specific about this:

   It is RECOMMENDED that default candidates be chosen based on the
   likelihood of those candidates to work with the peer that is being
   contacted. It is RECOMMENDED that the default candidates are the
   relayed candidates (if relayed candidates are available), server
   reflexive candidates (if server reflexive candidates are available),
   and finally host candidates.

Thanks for pointing that out - I had only looked at the introductory
part of the RFC
http://tools.ietf.org/html/rfc5245#section-2.2

where it talks about ordering the candidates by priority

···

On 18/01/12 20:13, Emil Ivov wrote:

On Wed, Jan 18, 2012 at 7:54 PM, Daniel Pocock <daniel@pocock.com.au> wrote:


#4

Hey Daniel,

Hey Daniel,

I'm just wondering about the way a UA with ICE+TURN support should
interact with a non-ICE peer

When the peer does not support ICE, the TURN-capable UA could still
potentially achieve connectivity if it uses it's relay candidate as
default candidate.

When the ICE UA receives a call (receives an offer), it will know
immediately that the peer is non-ICE, because the offer has no ICE
attributes. In this case, the UA can immediately set up the relay and
just assume worst case scenario.

But what about when the ICE capable UA is the caller?

What about that? Why do you see this case as problematic?

The following scenario:
- SIP proxy is SER, OpenSIPS or some other stateless proxy
- proxy owner wants to throw away rtpproxy/mediaproxy and just expect
everyone to use TURN
- some users still connect to the proxy using non-ICE user agents (e.g.
hard phones)

I still don't get it. How is this a problem for the client? If the
server forces a proxy by replacing the default candidate, then this
simply kills ICE as per ice-mismatch (RFC 5245 secionts 5.1 and 6.1):

  The agent will proceed with the ICE procedures defined in this
  specification if, for each media stream in the SDP it received, the
  default destination for each component of that media stream appears
  in a candidate attribute.

  ...

  If this condition is not met, the agent MUST process the SDP based on
  normal RFC 3264 procedures

A few hacks come to mind:

a) keep a cache of data on peers that don't support ICE, so the next
call to the peer will use relay by default

Not necessarily a good idea. What if, in the mean time, the peer logs
in with an ICE capable agent?

Agreed - that's why I called this a list of `hacks' - they are just ideas

Sorry, I didn't mean this as a criticism. I was just thinking think
might get worse with this particular hack than without it.

b) as soon as the call is setup (200 received), the caller does a
re-INVITE with relay

Why do you need to reINVITE? If relay is what you want to do in such
cases, then why not start with the relay candidate as default?

Yes, for case (b), as opposed to (c) below, using the relay candidate as
default seems like the way to go, and then if ICE is available it will
try to find a better solution

If ICE is disabled because of ice-mismatch it is not necessarily a good
idea to try and outsmart the proxy. In many such cases, relaying would
be the only way to go through so you might end up adding considerable
complexity, only to resolve a handful of cases. Only my opinion of course.

c) similar to (b), but the peer is slightly more clever - it waits 200ms
for incoming RTCP, if nothing comes in to prove that there is
connectivity, it does the re-INVITE via relay

Risky. 200ms is far too short to cover all cases. Sometimes it takes
Jitsi more than a second to actually obtain data from the capture
devices. Besides, if data isn't coming then there's no real way of
knowing exactly what was the reason. Maybe local connectivity is gone.

Yes, I agree it doesn't suit all situations. It is only an approximate
solution to avoid relay, definitely not bulletproof. However, if the UA
receives RTCP packets from the peer, then it can conclude that

- incoming packets are arriving
- depending upon the RTCP content, the UA can infer whether outgoing
packets were received by the peer

Well all in all I'd say it's a slippery slope. I remember seeing a
handful of similar best-effort solutions while ICE was still in the
works (including the original STUN) and they all shared the same issue:
not 100% reliable and of modest benefit.

The strong point of ICE is that it requires no assumptions to be made
about topology.

so if this was made to work somehow, it could reduce load on the relay.

If your SIP server forces you to relay then it obviously doesn't care
about reducing load. In that case why should you? (Again, just an opinion.)

Cheers,
Emil

···

On 18.01.12 20:31, Daniel Pocock wrote:

On 18/01/12 20:13, Emil Ivov wrote:

On Wed, Jan 18, 2012 at 7:54 PM, Daniel Pocock <daniel@pocock.com.au> wrote:

Does anyone know of any other examples, or any official work on this
from IETF?

I believe 5245 is actually pretty specific about this:

   It is RECOMMENDED that default candidates be chosen based on the
   likelihood of those candidates to work with the peer that is being
   contacted. It is RECOMMENDED that the default candidates are the
   relayed candidates (if relayed candidates are available), server
   reflexive candidates (if server reflexive candidates are available),
   and finally host candidates.

Thanks for pointing that out - I had only looked at the introductory
part of the RFC
http://tools.ietf.org/html/rfc5245#section-2.2

where it talks about ordering the candidates by priority

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#5

Hey Daniel,

Hey Daniel,

I'm just wondering about the way a UA with ICE+TURN support should
interact with a non-ICE peer

When the peer does not support ICE, the TURN-capable UA could still
potentially achieve connectivity if it uses it's relay candidate as
default candidate.

When the ICE UA receives a call (receives an offer), it will know
immediately that the peer is non-ICE, because the offer has no ICE
attributes. In this case, the UA can immediately set up the relay and
just assume worst case scenario.

But what about when the ICE capable UA is the caller?

What about that? Why do you see this case as problematic?

The following scenario:
- SIP proxy is SER, OpenSIPS or some other stateless proxy
- proxy owner wants to throw away rtpproxy/mediaproxy and just expect
everyone to use TURN
- some users still connect to the proxy using non-ICE user agents (e.g.
hard phones)

I still don't get it. How is this a problem for the client? If the
server forces a proxy by replacing the default candidate, then this
simply kills ICE as per ice-mismatch (RFC 5245 secionts 5.1 and 6.1):

I was referring to the situation when the rtpproxy has already been
disabled - so the SIP proxy may be fixing the contact address, but not
modifying the SDP

The idea is to keep using OpenSIPS or SER, but to avoid using rtpproxy

Consider the following:

[Device behind NAT, with ice4j]--[OpenSIPS]--[Asterisk on public IP]

In this case, the Asterisk box has a public IP, but no ICE support.
Relay is not needed and should be avoided if possible.

A few hacks come to mind:

a) keep a cache of data on peers that don't support ICE, so the next
call to the peer will use relay by default

Not necessarily a good idea. What if, in the mean time, the peer logs
in with an ICE capable agent?

Agreed - that's why I called this a list of `hacks' - they are just ideas

Sorry, I didn't mean this as a criticism. I was just thinking think
might get worse with this particular hack than without it.

Yes, I agree it would need things like timeout capability as a bare minimum

b) as soon as the call is setup (200 received), the caller does a
re-INVITE with relay

Why do you need to reINVITE? If relay is what you want to do in such
cases, then why not start with the relay candidate as default?

Yes, for case (b), as opposed to (c) below, using the relay candidate as
default seems like the way to go, and then if ICE is available it will
try to find a better solution

If ICE is disabled because of ice-mismatch it is not necessarily a good
idea to try and outsmart the proxy. In many such cases, relaying would
be the only way to go through so you might end up adding considerable
complexity, only to resolve a handful of cases. Only my opinion of course.

I'm only referring to cases where one side has no ICE support and no SDP
mangling takes place. The whole reason for removing rtpproxy is so that
there is no risk of SDP mangling: does that make sense?

It would also be possible for OpenSIPS to continue using rtpproxy, but
avoid the SDP mangling if it notices any ICE attributes in the SDP.

c) similar to (b), but the peer is slightly more clever - it waits 200ms
for incoming RTCP, if nothing comes in to prove that there is
connectivity, it does the re-INVITE via relay

Risky. 200ms is far too short to cover all cases. Sometimes it takes
Jitsi more than a second to actually obtain data from the capture
devices. Besides, if data isn't coming then there's no real way of
knowing exactly what was the reason. Maybe local connectivity is gone.

Yes, I agree it doesn't suit all situations. It is only an approximate
solution to avoid relay, definitely not bulletproof. However, if the UA
receives RTCP packets from the peer, then it can conclude that

- incoming packets are arriving
- depending upon the RTCP content, the UA can infer whether outgoing
packets were received by the peer

Well all in all I'd say it's a slippery slope. I remember seeing a
handful of similar best-effort solutions while ICE was still in the
works (including the original STUN) and they all shared the same issue:
not 100% reliable and of modest benefit.

The strong point of ICE is that it requires no assumptions to be made
about topology.

I agree: whatever the solution is, if one exists, it should never leave
the user with one-way audio or some similarly bad experience. There is
no faster way to scare people away from VoIP.

so if this was made to work somehow, it could reduce load on the relay.

If your SIP server forces you to relay then it obviously doesn't care
about reducing load. In that case why should you? (Again, just an opinion.)

It is important because anyone running OpenSIPS+nathelper+rtpproxy needs
to review their SDP mangling if they want ICE clients to work.

···

On 18/01/12 20:55, Emil Ivov wrote:

On 18.01.12 20:31, Daniel Pocock wrote:

On 18/01/12 20:13, Emil Ivov wrote:

On Wed, Jan 18, 2012 at 7:54 PM, Daniel Pocock <daniel@pocock.com.au> wrote: