Subject: Re: FW: [MMUSIC] Compromise proposal for ICE finishing algorithm

From: Peter Livesey <[email-masked]>
Date: Wed, 11 Oct 2006 11:26:12 +0100 (BST)

Like the proposal. Just looking for a clarification on
a couple of points.  

Just was wondering who would be the 'controller' in
the following situation:
A PSTN GW is initiating a call (on behalf of a POTS
phone), to a UA behind an m/c line changing (non ICE)
SBC (or ALG). The UA itself isn't behind a NAT as it's
behind the SBC. Therefore, both the PSTN and UA
advertise only 1 candidate (their local address).  

Are the 'inserted' candidates used in the controller
decision? If so wouldn't both the PSTN GW and the UA
believe the other is the 'controller', as they would
have 1 candidate but the received SDP would have 2
(original + 'inserted')?

If the 'inserted' candidate isn't taken into account
then the PSTN GW is the 'controller', as it's the
offerer. Assuming STUN checks on 'inserted' candidate
succeed, is it correct that in this case the PSTN GW
wouldn't have to send a re-invite as it would just be
the same as the original?

Would be worth documenting GW algorithm to avoid
incorrect implementations due to misinterpretations.

Cheers,

Pete L.    
> 
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 10 October 2006 16:16
> To: IETF MMUSIC WG
> Subject: [MMUSIC] Compromise proposal for ICE
> finishing algorithm
> 
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Oct 2006 12:51:16 -0400

inline.

> have 1 candidate but the received SDP would have 2

No. They don't count. Its quite literally a count of the a=candidate 
lines in the SDP. In this case it would be a tie and the offerer would win.

> the same as the original?

Right.

> incorrect implementations due to misinterpretations.

This came up as an open issue - whether to document this and where. I'm 
inclined to not bulk back up the core ICE spec now that we got it thinner...

-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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 11 Oct 2006 18:48:19 -0400

On 11-Oct-06, at 12:51 , Jonathan Rosenberg wrote:

> This came up as an open issue - whether to document this and where.  
> I'm inclined to not bulk back up the core ICE spec now that we got  
> it thinner...
>

My opinion is that, if we are going to take the time to worry about  
this issue,
and add the extra complexity to the specification to make it simpler  
for some classes of nodes,
then we need to (a) document it, (b) make sure that it really does  
simplify these nodes.

I am OK if the former happens in a separate document, but I don't  
feel the ICE spec should
be finalized before that other document is well advanced.

As for the latter, I guess that writing this all down would be a good  
first step to seeing
how much simpler it makes things.

- Philip
   (who is still somewhat unsure that adding extra complexity to the  
ICE spec to make life easier
    for Gateways will really have any measurable effect).