Subject: [MMUSIC] Compromise proposal for ICE finishing algorithm

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Oct 2006 11:16:00 -0400

I've been considering this issue about how to have ICE finish over the
last week. I've come up with a compromise proposal which I hope
works for everyone.

The proposal has the following properties:

* has one agent acting as controlling, and that agent selects the final 
pairs that get used and signals those pairs through STUN, allowing for 
the forwards compatibility we are anxious to have
* requires nothing more than a two more bits to be added to the STUN 
messaging
* has no additional latency for call setup as long as the agents are 
using the default selection algorithm (highest priority pairs that 
succeed get used)
* uses the candidates in the m/c-line always but only if they worked; if 
checks through them failed, the one selected by the STUN signaling is used
* should interoperate with existing SBC and SIP ALG; see below for caveats
* Will 'bypass' faulty SBC and ALG in cases where their suggested media 
paths don't work. For example, if a SIP ALG is broken and doesn't 
hairpin properly, and both endpoints are behind the same NAT/ALG, 
they'll take the direct path
* relieves PSTN gateways of the responsibility for ever having to 
generate a re-invite, compute and maintain a valid list. However they 
would still perform checks. Inter-GW calls would not require a re-invite.

All of this comes at the cost of complexity, and it centers around this 
bigger question of whether it is a requirement for ICE to help calls 
work in cases where there are SBC or ALG 'in the way'. Some folks have 
expressed a strong opinion that it should, though this is far from 
unanimous.

The high level approach is a synthesis of what has been suggested
throughout the various discussions. Once the offer/answer exchanges
are done, each agent checks to see if there is a candidate line for
the m/c-line. If there isn't, each agent adds the address and port in
the m/c-line as a candidiate, and assigns it the highest priority
(see below on exactly how). Fortunately, as of ICE-10, the
username/passwords are a function of the media stream and NOT
individual candidates, so the username and password are known. This
remote candidate is marked as being of a special type, which I'll call
'inserted' for now.

After the offer/answer exchange, one agent takes the role of
'controlling'. This will be the agent which had the most number of
candidates across all media streams. If it was a tie, the controlling
agent is the offerer. The controlling agent gets to decide when the
checks finish and what the selected pairs are. However it is somewhat
constrained in that, if there was an inserted candidate, that one has
to be used if it validated.

When the controlling agent selects a pair to be used, it includes a
flag in a STUN check for that pair which indicates that this is the
pair that was selected. The non-controlling agent will use the
resulting pair if and only if it has successfully completed a check in
the reverse direction. If multiple checks succeed with the flag set, the 
highest priority one which worked is used. The reason it gets specified 
this way is that it allows you to avoid an extra set of checks just to 
indicate you are done. An implementation which just wants to use the 
'highest priority' selection algorithm in ICE-10 would set the flag in 
all checks it does for the last component of each media stream. As soon 
as one completes, it would get used. However, an agent looking to use a 
more complex algorithm would omit the flags initially, perform checks, 
and when it decides, redo checks for the selected pairs. This way, the 
latency penalty on setup comes only for implementations doing something 
more complex than the baseline.

Another important aspect of the checks is this. When an agent receives a 
STUN check, and the source address of the Binding Request matches an 
inserted candidate, the STUN resposne contains a flag informing the 
client that this mapped address was an inserted one. This alerts the 
client that this is not a 'normal' peer derived address, but rather one 
that was forcefully inserted by an intermediary. If that candidate gets 
selected (and it probably will as its highest priority), when the agent 
does the reinvite - it doesnt actually place this addess into the 
m/c-line. Rather, it places whatever it put in the previous offer or 
answer. Without this feature, I think there will be interoperability 
problems with existing SBCs. In particular, without it, the re-invites 
would convey, from the UAC and UAS, the transport addresses assigned by 
the SBCs themselves. I fear that this reinvite will seriously confuse 
existing SBC.

So, when the re-invite comes, if the m/c-lines match the selected pairs, 
great. If not, they get used if and only if the m/c-lines were already 
validated by checks. If the m/c-line is known as a candidate, but didn't 
validate, it is NOT used. If the m/c-line in the re-invite is new 
(meaning its not a known candidate), a check is immediately performed 
for it, and then as above it is used if it works, otherwise not.

Another thing - I believe the re-INVITE can be skipped if the m/c-lines 
would be unchanged from the previous offer/answer. This makes ICE nice 
for inter-gateway operation since you'll never need a re-invite there. 
However you'd still have checks, which is a good thing I think.

I worked through some call flows for this, and it works with SIP ALG and 
SBCs under the following assumptions:

* If a SIP ALG sees an SDP from the inside to the outside, but the 
m/c-line is NOT an internal address, it leaves the m/c-line alone. I 
don't know if this assumption is always true, but if not, ICE will have 
serious problems through such ALG no matter what we do.

* An SBC will pass STUN packets as if they were RTP packets

In terms of the priority for the inserted candidates, the idea is to 
reserve the largest type preference value, and use that only for 
inserted candidates. Indeed the astute reader will note that I already 
left provision for that in ICE-11.

We'll discuss on the call today.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: <[email-masked]>
Date: Tue, 10 Oct 2006 22:03:40 +0300

Hi,

all in all this proposal looks good. Some comments:

On 10 October, 2006 Jonathan Rosenberg wrote:
>'controlling'. This will be the agent which had the most 
>number of candidates across all media streams. If it was a 
>tie, the controlling agent is the offerer. The controlling 

what if a comedia style approach would be used here? Offerer
could advertise willingness to be in the 'controlling' role. This would
seem more robust approach for supporting simple ICE implementation 
at gateways -- these boxes could then advertise themselves as 
passive (not capable of being in the 'controlling' ICE role). Relying
on low number of candidates at gateways seems somewhat brittle.

[inserted candidate]
>forcefully inserted by an intermediary. If that candidate gets 
>selected (and it probably will as its highest priority), when 
>the agent does the reinvite - it doesnt actually place this 
>addess into the m/c-line. Rather, it places whatever it put in 
>the previous offer or answer. Without this feature, I think 
>there will be interoperability problems with existing SBCs. In 

This is somewhat nasty, but I guess there are no real alternatives
to this if we wish to play nice with already deployed SBCs.

>Another thing - I believe the re-INVITE can be skipped if the 
>m/c-lines would be unchanged from the previous offer/answer.

This is a nice addition.
 
>I worked through some call flows for this, and it works with 
>SIP ALG and SBCs under the following assumptions:
[...]
>* If a SIP ALG sees an SDP from the inside to the outside, but 
>the m/c-line is NOT an internal address, it leaves the 
>m/c-line alone. I don't know if this assumption is always 
>true, but if not, ICE will have serious problems through such 
>ALG no matter what we do.

I guess any middle-box that is mainly there for policy control, not
because of NAT problems, would insert itself on the media
path in any case. And I guess this is fairly common in deployed
networks. 

But I don't think ICE should fight this. Either the STUN checks
go through the inserted candidate (in which case we are fine), or we 
need to fall back to non-ICE mode (see below).

>* An SBC will pass STUN packets as if they were RTP packets

This might not always be the case, but then it's also likely that
other checks will fail as well (unless the clients are in the same
LAN). So what to do in these cases - none of the candidate pairs 
validate and we have a modified m/c-line (inserted candidate)? In
practise 
you'd probably want to use the m/c-line in this case even though the
STUN 
checks won't go through (-> fallback to non-ICE mode).

The trickiest case is when a middlebox does not let STUN packets
through, but we have some lower-prio pair (e.g. clients in the
same LAN) that validates ok. We don't want to use the m/c-line as we 
don't know if it works, but neither can we upgrade the lower-prio pair, 
as that would potentially confuse the middlebox.

-- 
[email-masked] (Kai Vehmanen)
Networking Technologies Laboratory, Nokia Research Center