RE: [ipcdn] pktcSigDevCodecTable request for clarification

["Jean-Francois Mule" <jf.mule at cablelabs.com>]

Hi David,
See inline.
Jean-François 

> -----Original Message-----
> From: David De Reu [mailto:DeReu at tComLabs.com] 
> Sent: Friday, January 21, 2005 2:27 AM
> To: IPCDN Mailing List
> Subject: [ipcdn] pktcSigDevCodecTable request for clarification
> 
> 
> Dear all,
> 
> Some MTA vendors are a bit puzzled regarding what to include in the
> pktcSigDevCodecTable table. On their and my own behalf, I 

What strikes me in your introduction is the lack of operator's view on this table, I'd be curious to see what the operators' input is there.


> would like to
> request some clarification.
> 
> 
> More specifically, there actually are two types of codecs:
> 
> - First, the "real" voice codecs, like the ones listed in the 
> PktcCodecType
> TEXTUAL-CONVENTION (PCMA, PCMU, G.729... etc)

A note on this, during my review of draft00, on Tuesday, March 18, 2003 at 11:33 AM, I wrote:
> - PktcCodecType TEXTUAL-CONVENTION 
> See IETF AVT draft-ietf-avt-profile-new-13.txt, section 4.5: 
> this draft is an update to rfc1890 and it defines the latest 
> and greatest encoding names for audio video codecs. The 
> PktcCodecType object definition should use the encoding names 
> defined in AVT. In particular, g711a/mu must be replaced by 
> PCMA/PCMU, etc. These changes were made in the latest 
> PacketCable spec PKT-SP-MIB-SIG-I05-021127 and should be 
> reflected in the IETF ipcdn ID.
The ID mentioned above is now RFC 3551.

I'm not sure I understand your point or comment here but I'd recommend keeping the TC based on the literals names used in NCS-SIP/SDP to negotiate the codecs.


 
> - Second, supplementary "codecs", for example for DTMF relay 
> (RFC 2833). 
The issue here is to understand how IETF AVT wg is dealing with RFC 2833. See section 6 of RFC3551 - there is no "codec" defined as rfc2833 for a good reason: you usually don't use it in the m= line, it's not a "primary" codec. Some other codecs have dynamic payload types and dtmf relay/rfc2833 - for the RTP payload type falls in this case. 

> In
> (Euro-)PacketCable/IPCablecom, this is the "telephone-event" 
> "codec". 
Where is the spec you are refering to? Can we have a look at it? The ipCablecom spec referenced in the draft does not seem to have such a "codec".
In the DSP media connection line (m=), you still have to indicate a vocoder, even if you advertise support 2833 (which is done in the media attribute line a=). That difference is key to understand. Per se, this is not a voice codec, just an additional capability to extract tone/events inside the media payloads and encapsulate them in an RTP format so that it can be reliably regenerated on the other side.


> Other,
> proprietary solutions for DTMF relay exist as well, by the 
> way, so this is
> not limited to "telephone-event" alone.
We can't do much there. 

> >From a signaling point of view (NCS and SDP in our case), 
> the "codecs" of
> the second type, are treated as all other codecs. 
> However in 
> practice they
> cannot be used for the entire call, they have to be used in 
> conjunction with
> a "real" codec.
Yes, again, RFC2833 is a very special case (for e.g. the MTA starts a G.729E call - that is the codec, then turn on dtmf detection on your DSP and encodes those dtmf in rfc2833 while maintaining the voice payloads isnide the rtp voice channel).


> The question now is: do the codecs of the second type have to 
> be included in
> the pktcSigDevCodecTable, or is this table just intended for 
> "real" codecs?
I would say no based on the current definition and description clause of this TC. 


> Either way, a clarification of some sort in the DESCRIPTION 
> clause would be
> helpful to implementors (and testers, as a matter of fact). 
If an integer value is not given for other codecs, or represented in the TC, then testers cannot expect vendors to advertise it. RFC3551 does not make a special case for RFC  2833 either.


> If they are to
> be included, currently the only way is to use "other (1)" as 
> the type, which
> is of course allowed but not very informative.
In my opinion, they should not be included. If what you want is the MTA to indicate support for RFC2833, then this belongs to another MIB object.

> This leads me to my second point: if things like "telephone-event" are
> supposed to be included in the pktcSigDevCodecTable, then I 
> at least suggest
> extending the PktcCodecType with something like "telephoneEvent (15)".
But then this is not a valid codec literal name as the TC mandates so that is not a good option to me.

> 
> 
> Any feedback would be appreciated.
> 
> 
> Regards,
> 
> David
> 
> _____________________________________________________
> David De Reu
> tComLabs
> Stapelplein 70/004 - 9000 Ghent - Belgium
> Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74
> www.tComLabs.com
> _____________________________________________________
> 
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> IPCDN at ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 

_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn