Subject: Re: [MMUSIC] Clarification about ICE Management of Resources

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 08 Nov 2004 06:47:01 -0500

inline.

Awais Ali wrote:

> I would like to verify if my understanding of the Management of 
> Resources section in the ICE draft is correct.
> 
> Let us assume device A and device B want to establish an RTP/RTCP 
> session. A and B have 3 addresses each, as follows:
> 
> AL: local address of A
> AS: Stun derived address for A
> AT: Turn derived address for A
> 
> BL: local address of B
> BS: Stun derived address for B
> BT: Turn derived address for B
> 
> After A completes its connectivity checks, A's connection table for RTP 
> will look like this
> 
> 1. AS     BS   ... ... ... 0.2    GOOD
> 2. AS     BT   ... ... ... 0.1    GOOD
> 3. AS     BL   ... ... ... 0.4    BAD
> 4. AT     BS   ... ... ... 0.2    GOOD
> 5. AT     BT   ... ... ... 0.1    GOOD
> 6. AT     BL   ... ... ... 0.4    BAD
> 7. AL     BS   ... ... ... 0.2    GOOD
> 8. AL     BT   ... ... ... 0.1    GOOD
> 9. AL     BL   ... ... ... 0.4    BAD
> 

Right so far.

> Lets say A selects Line 7 to send RTP packets, then A will keep the 
> other five connections open by sending keep-alive packets on them. 

No. In the current draft, it would only keep alive the one its using, 
since keepalives are done at the application layer and therefore imply 
usage of the address.

> Similarly there will be 5 RTCP channels. So in total A has to keep-alive 
> 10 connections.

No, just two (RTP and RTCP).

> 
> B will also have a simillar connnection table. If B also selects the BL 
> AS line for sending Media packets, then in the above exampe, we will 
> have the situation where A is sending from a different port than it is 
> receiving on. 

Hmm, in -03, yes it would appear that this would happen.

In this case then A must send keep alive packets from AS
> to keep the NAT binding open, even if it decides not to keep the other 
> connections as backup.

This is an excellent point, thank you for pointing it out. It is a 
definite problem in the specification, since right now those keepalives 
are not happening.

What needs to happen is that you end up with a symmetric relationship, 
where both sides send to, and receive from, the same address. As such, 
you need to add an algorithm to the spec to select the source address in 
a much more deterministic way. I'd suggest that the following algorithm 
works:

A client MUST send from the transport address on which it most recently 
received an RTP packet. If there is no such address (as no RTP packets 
are being received yet), it SHOULD send from the transport address of 
highest local priority on which a STUN connectivity check has been 
received. If there is no such address (as no connectivity checks have 
been received yet), it SHOULD send from the local transport address of 
highest priority.

The first sentence of this paragraph achieves the desired effect - it 
will force media to be sent from the same port on which it is being 
received. The remaining sentences help avoid flaps. That is, they help 
ensure that you start sending RTP packets initially from the place where 
you are likely to receive them. There is no guarantee, so its really an 
optimization of sorts, which is why I put it at SHOULD strength.

Comments on this algorithm?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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