[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ipcdn] pktcSigDevCodecTable request for clarification
Thank you for your comments, Jean-François. See inline.
> > 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.
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.
> > 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.
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.
> > 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?
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.
> > 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.
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)".
> > 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.
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.
> > 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.
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.
> > 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.
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
_____________________________________________________
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn