Subject: RE: [ipcdn] pktcSigDevCodecTable request for clarification

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 21 Jan 2005 11:00:07 -0700

Hi David,
See inline.
Jean-François 

> -----Original Message-----
> From: David De Reu [mailto:[email-masked]] 
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "David De Reu" <[email-masked]>
Date: Mon, 24 Jan 2005 10:23:38 +0100

Thank you for your comments, Jean-François. See inline.

> 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.

Me too, as a matter of fact. I hope that some of the actual "users" of this
table are following this thread and are willing to provide some input.

> 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.

Of course, I didn't mean to suggest a change here. I merely wanted to give
some exampes of what I meant by "real" voice codecs, since this is far from
an official term.

> Where is the spec you are refering to? Can we have a look at it?

Unfortunately, PacketCable specs are a bit vague about this, and IPCablecom
seems to have left it out entirely. I believe RFC2833 was primarily intended
for use in the Line Control Signaling architecure: see
PKT-TR-ARCH-LCS-V01-010730, which is unfortunately rather outdated and
strictly speaking a technical report instead of a specification, but also
PKT-SP-EC-MGCP-I10-040402 (the NCS specification) for example uses.

The bottom line is: RFC 2833 (called "telephone-event" in PacketCable), can
be present in the NCS LocalConnectionOptions and in SDP (both in the m= and
a=rtpmap lines, via a dynamic payload type and the "telephone-event"
encoding name). A number of MTA vendors support this feature. I have no idea
whether it's used by operators in practice.

> In the SDP 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.

Exactly.

> I would say no based on the current definition and description

Until now, that was my interpretation as well. However, some people have
interpreted this differently, and it would be useful to agree on the exact
interpretation. The problem is that "other(1)" has no strict interpretation.
If it would be impossible to include RFC 2833, things would be clear, but
now there is a "back door" through "other(1)".

> If an integer value is not given for other codecs, or represented
> in the TC, then testers cannot expect vendors to advertise it.

True, hence the "other(1)" some vendors currently use if they feel they have
to include it. Given the requirement that all combinations have to be listed
in the codec table, this gives you a table that is half filled with
"other(1)" in a manner of speaking.

> RFC3551 does not make a special case for RFC 2833 either.

Again true, another argument not to include it in the TC and hence the codec
table.

> In my opinion, they should not be included.

Agreed.

> If what you want is
> the MTA to indicate support for RFC2833, then this belongs to
> another MIB object.

Currently, there is no such MIB object indeed, but by using an NCS "Audit
Endpoint" command, the MTA can be asked for its capabilities - support for
"telephone-event" being one of these. I understand that you are not
suggesting that we need such an object, but before someone does: I see no
reason to include MIB objects for all of these capabilities, because you
would then actually be doing "NCS over SNMP" :)

Which is, in my opinion, another reason not to include RFC2833 in the codec
table. Things like the supported voice codecs and silence suppression
capability etc. are rather fundamental, and do belong in the MIBs, but extra
features like support for RFC2833, proprietary solutions for DTMF relay,
additional NCS signaling packages, etc. belong in the capabilities returned
upon an "Audit Endpoint" command.

> But then this is not a valid codec literal name as the TC
> mandates so that is not a good option to me.

Agreed.

To relieve all doubt, and to make things simpler for vendors, I would
suggest a subtle change of the DESCRIPTION of pktcSigDevCodecTable.

A first suggestion:

   pktcSigDevCodecTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF PktcSigDevCodecEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           " This table describes the MTA supported voice codec types.
             This table MUST NOT include non-voice codecs. A MTA MUST
             populate this table with all possible combinations of
             codecs it supports for simultaneous operation. For
             example, ..."

"Design decisions" behind this wording:

- if the actual codecs (all but "other(1)", "unknown(2)" and "reserved(4)")
from the PktcCodecType TEXTUAL-CONVENTION are used, the new "MUST NOT"
requirement is automagically fulfilled and nothing changes for existing
implementations;

- the "other(1)", "unknown(2)" and "reserved(4)" from the TC are limited to
*voice* codecs within the context of the pktcSigDevCodecTable, which was the
original intention.

Any support for or objections against this change?

Thanks,

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
_____________________________________________________