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
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.
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
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.)
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 <firstname.lastname@example.org> wrote:
Does anyone know of any other examples, or any official work on this
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
where it talks about ordering the candidates by priority
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
email@example.com PHONE: +18.104.22.168.43.30
http://jitsi.org FAX: +22.214.171.124.47.31