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

From: Aron Rosenberg <[email-masked]>
Date: Mon, 08 Nov 2004 11:55:16 -0800

Have we considered making the use of symmetric RTP mandatory or 
suggested with ICE? Wouldn't that solve numerous of these corner case 
issues? Aside from that, the algorithm suggested below works quite well 
to fix the keep alive problem mentioned.

-Aron Rosenberg

>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.
>  
>

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 13:24:44 -0500

Symmetric RTP will basically be what you get with the behavior below. As 
such, it is effectively mandatory as an implicit by-product of the 
algorithm below.

-Jonathan R.

Aron Rosenberg wrote:

>> definite problem in the specification, since right now those 
>> keepalives are not happening.
>>
>> 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.
>>
>>
>>
>> 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.

-- 
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