Subject: Re: [MMUSIC] ICE Finishing: Design choices

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Oct 2006 12:56:01 -0400

There is no extra complexity in ICE for dealing with symmetric RTP; I 
think there is a fair bit of complexity to get away from it. ICE has 
been architected around the symmetric RTP assumption.

I have listed many times the rationale for symmetric RTP. It includes:

* working with offpath QoS installation mechanisms (IMS kind of stuff)
* working with monitoring tools which look at SDP and match it to media 
streams
* working with more stringent firewalls that are looking for RTP to 
keepalive

and so on.

Thanks,
Jonathan R.

[email-masked] wrote:

> Hi,
> 
> On 26 September 2006,  Jonathan Rosenberg wrote:
> 
>>This came up on last weeks call. It was suggested that with 
>>the keepalives being generated on the media stream, it was not 
>>so important to retain symmetric RTP. I remain opposed to 
>>this. Symmetric RTP seems to be the assumption these days, and 
>>I think it will be maximally interoperable with firewalls and 
>>various other intermediate things if we retain this property.
> 
> 
> I don't have strong opinions on this, but what would be the use cases
> where symmetric RTP is really needed when ICE is used? 
> 
> As clients cannot really assume a continuous flow of RTP packets 
> throughout a session (due to aggressive VAD for instance), you anyways
> need to send STUN packets to keep the RTP/RTCP flows alive. From
> middle-box
> point of view, each client will have "two symmetric-RTP flows" per
> session (one
> for receiving and one for sending, but both have the STUN traffic). 
> 
> Symmetric RTP does have some benefits (only one flow needed at stateful 
> middle-boxes), but it's not that obvious that the benefits outweight
> possible 
> added complexity in ICE to always achieve one symmetric RTP flow.
> 

-- 
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: Cullen Jennings <[email-masked]>
Date: Tue, 3 Oct 2006 21:46:15 -0700

Just as side not to the discussion, I'm never quite sure what people  
mean when they say SBC or middlebox. I can see  Hadriel's point that  
a B2BUA in the path might have a better idea than the originating UA  
about optimal - however, I can't think of a use case where a proxy or  
ALG in a NAT has a significantly better idea.

On Sep 27, 2006, at 8:15 PM, Hadriel Kaplan wrote:

>
>
>> -----Original Message-----
>> From: Rohan Mahy [mailto:[email-masked]]
>> Sent: Tuesday, September 26, 2006 4:05 PM
>> To: Jonathan Rosenberg
>> Cc: IETF MMUSIC WG
>> Subject: Re: [MMUSIC] ICE Finishing: Design choices
>>
>> I'm including my opinions in-line.  I think questions 2 and 3 imply a
>> choice between business as usual for middleboxes and some very  
>> minimal
>> level of ICE-support for at least one middlebox in any network that
>> wants to enforce non-optimal paths.
>
> I don't know why people keep claiming they're non-optimal paths.   
> The UA has
> no idea what the "optimal" path is.  The middlebox path may be more  
> optimal,
> or less, or the same.  It depends on many things, most of which are
> unknowable to a UA, some of which are knowable to a middlebox.
>
> (size(1) != all.fit();)
>
> -hadriel
>
>
>