RE: [ipcdn] pktcSigDevCodecTable request for clarification

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

David,
Inline.
Jean-François 

You wrote:
> > > 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. 
Yes, DTMF relay using RFC2833 (or for some implementations using the upcoming RFC2833bis) is out of scope of PacketCable 1.0. More news on this later, probably next week but as far as this version of the ipcdn sig MIB is concerned, I would say that this is out of scope.
Note that vendors are free to implement it as they are to implement a bunch of other codecs we don't put in the table.

[snip]

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

DTMF relay is using in many VoIP services today. The use of dtmf relay/rfc 2833 has several benefits to the operators:
 - reliable transmission of the DTMF tone and tone duration (see timestamp + duration fields in 2833) when the voice path has been established especially when using low-bit rate codecs (post cut-through);
 - more reliable detection and notification of telephony events like fax tones for detection of fax transmission and switch over to protocols like t.38 fax relay.
 

> 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)".
Are u suggesting we remove other? It means "more" codecs are support but it is not specific.

> > > 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.
ok
> 
> 
> > > 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 
                         ^^^^^^^^^^^^^^^^^^^
Because this is really outside the scope of the specs this mib covers.

> 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;
Isn't your pb solved by this MUST NOT though? An MTA vendor that includes 2833 events as part of this table fails to meet this requirement, no? 

But that is missing the point. Again RFC2833 support means various levels of implementations (dtmf0-9, abcd, flash,..., or named events like ANS, etc.). It you want to know whether a device supports 2833, we should have a more granular object syntax mapping the media attribute line the implementation would advertise in SDP:
 for e.g. a=fmtp:100 0-15,66,70
The idea would be to map the section 3 of RFC2833 and telephone event capabilities into some kind of a mib syntax.

My 2 cents.
Jean-François 


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

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