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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Nov 2005 11:39:19 -0500

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Nov 2005 09:07:07 +0000

Yes, I would support a generic solution, rather than codec-specific.

John

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 24 November 2005 07:09
> To: Randell Jesup; Elwell, John
> Cc: IETF MMUSIC WG
> Subject: RE: [MMUSIC] comments on draft-xu-mmusic-sdp-codec-param
> 
> 
> Hi,
> 
> A solution pretty much identical to the proposed x-codecparam 
> attribute,
> where the payload type is present (similar to the fmtp attribute), has
> been discussed before - and the discussion seems to come up over and
> over again. So, I agree that we need to find a solution for this. The
> same discussion has also taken place in other standardization bodies,
> related e.g. to H.248 usage of SDP.
> 
> The draft proposes that one can list ptime values in the attribute. I
> also think it should be possible to list the min and max value, as has
> been propsed by others.
> 
> Something like: a=x-codecparam: <PT> "max"=<time> "min"=<time>
> 
> Personally I don't think using fmtp would be the best choise for this,
> since the syntax of the attribute would be generic, and not codec
> specific.
> 
> Regards,
> 
> Christer
> Ericsson
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Randell Jesup
> > Sent: 12. marraskuuta 2005 7:42
> > To: Elwell, John
> > Cc: IETF MMUSIC WG
> > Subject: Re: [MMUSIC] comments on draft-xu-mmusic-sdp-codec-param
> > 
> > "Elwell, John" <[email-masked]> writes:
> > >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.
> > 
> >         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]
> > 
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 24 Nov 2005 12:42:32 +0100

Hi,

I would propose that we split the issues into separate work items.

For the ptime-per-codec issue it seems like we agree on the need, and it
also seems like we have a pretty good understanding on how to implement
it.

Regards,

Christer

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: 24. marraskuuta 2005 12:18
> To: Christer Holmberg (JO/LMF)
> Cc: Randell Jesup; Elwell, John; IETF MMUSIC WG
> I also support work on a more generic per payload type 
> specified packetization indication and negotiation parameter. 
> I agree with Jonathan that a new attribute shall be used. 
> Changing ptime at this point in time would be a nightmare.
> 
> I would also like to point out: STOP USING X-!!!
> 
> Sorry for shouting, but this bad idea seems impossible to 
> kill, independently of if it is SDP, SIP or RTSP.
> 
> I also have grave concerns with an mechanism specifying 
> alternative addresses within a single media block. As each 
> alternative address for this usage would be its own RTP 
> session using it in this way has several severe issues. They 
> all originates from the assumption that one media block is 
> its own RTP session (or part of a session) and indicates 
> individual streams. Putting multiple streams with different 
> semantics in the same media block do break:
> 
> - SRTP
> - ULP (now that we have fixed it)
> - pre-conditions
> 
> I would also like to point out that some work has been done 
> for allowing the indication using the grouping of media lines 
> framework to indicate that different streams are alternatives 
> to each other where only one of them should be used at any 
> point in time. See FID semantics in RFC 3388 which would 
> allow to indicate different media lines and c= for different 
> codecs part of the same media flow, thus allowing redirection 
> to transcoder for specific codecs.
> 
> Cheers
> 
> Magnus
> 
> 
> 
> Christer Holmberg (JO/LMF) wrote:
> > Hi,
> > 
> > attribute, where the payload type is present (similar to the fmtp 
> > attribute), has been discussed before - and the discussion seems to 
> > come up over and over again. So, I agree that we need to find a 
> > solution for this. The same discussion has also taken place 
> in other 
> > standardization bodies, related e.g. to H.248 usage of SDP.
> > 
> Magnus Westerlund
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 25 Nov 2005 11:30:15 +0100

Hi,

BTW, in RFC3108 there is a "vsel" attribute defined. Have you looked at
that?

It does not allow max/min/list values, but it does allow to specify a
value per codec (the codec name is used instead of the PT number).

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Cc: Elwell, John; IETF MMUSIC WG

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 25 Nov 2005 17:33:18 +0000

Christer,

This looks like the sort of thing we need. We could define a new attribute
in this style, but I would prefer PT numbers to codec types.

John

> Sent: 25 November 2005 10:30
> To: Magnus Westerlund (KI/EAB)