Subject: re:[MMUSIC] comments on draft-xu-mmusic-sdp-codec-param

From: xupeili 18916 <[email-masked]>
Date: Wed, 09 Nov 2005 10:03:00 -0800

Hi Jonathan,

Thank you for your comments.
The ptime issue is accually not a new one, I think it`s time to be solved now.

For the codec level transport address problem, actually I don`t have strong opition about what the solution would be. The popose for this draft is to 
start discussion about the requirement, and then try to find the suitable solution.

Sorry, I can not answer the question until I have a study on ICE ;-), maybe other experts may have some suggestion.

Although these 2 cases are separate, they are all related to codec level parameters, so, actually, my original idea is that can we find out a general way to provide codec level parameter whatever it might be.

regards
Peili

----- Origine -----

> The draft is discussing two separate things, one of which I think 
> is 
> good, the other I have concerns about.
> 
> On the ptime parameter, this has been a disconnect between the 
> specs and 
> the implementation community for a while. The intent of ptime was 
> always 
> to say "here is the packetization interval i'm going to use" in an 
> advisory fashion. In principal, a recipient should be able to 
> receive 
> RTP packets with any packetization interval and still decode them. 
> However, as you point out, many implementations have only supported 
> fixed packetization intervals and have sought a mechanism for 
> negotiating the packetization itnerval much like the codec itself.
> 
> I support aligning our standards with the reality of 
> implementation, and 
> as such, would support work to fix this problem. My main comment is 
> that 
> if folks want to do this, we might want to consider using a new 
> parameter instead of ptime.
> 
> The other half of the draft talks about using differnet ports for 
> different codecs. A specific example is given of a transcoder, 
> where you 
> want to send RTP to the transcoder if certain types of codecs are 
> used, 
> and to the endpoint if others are used. I think doing that would be 
> a 
> huge mistake. It will completely break SRTP. It will completely 
> break 
> ICE. It will completely break preconditions. Do not do this.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-
> 2711Cisco 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, 09 Nov 2005 14:22:53 -0500

inline.

xupeili 18916 wrote:

> Although these 2 cases are separate, they are all related to codec
> level parameters, so, actually, my original idea is that can we find
> out a general way to provide codec level parameter whatever it might
> be.

Thats fair, my main point here is that I don't think this should apply 
to ports.

-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