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

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Nov 2005 03:08:34 +0000

I think the ptime area is worth addressing. It appears that some
implementations have a minimum packet time for receipt, below which they are
likely to encounter performance problems. Likewise some may have a maximum
packet time for receipt, governed by buffer sizes. It would be good to have
a way of expressing these upper and lower bounds to what a device is able to
receive. The existing ptime parameter is unable to express this. Of course,
these bounds are likely to differ according to codec, e.g., for G.711 a
device might accept between 5 ms and 20ms, but for G.723 it might accept
between 30ms and 60ms.

John 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 09 November 2005 16:39
> To: IETF MMUSIC WG
> Subject: [MMUSIC] comments on draft-xu-mmusic-sdp-codec-param
> 
> 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-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: Randell Jesup <[email-masked]>
Date: 12 Nov 2005 00:42:26 -0500

>device might accept between 5 ms and 20ms, but for G.723 it might accept

        And then there's iLBC, which uses 20 or 30ms (only), with specific
offer/answer rules (20ms default, use 30ms if either side requests it).  
This is done via fmtp (a=fmtp XX mode=NN), though.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]