Subject: RE: [ipcdn] Re: Signaling MIB - Draft 3 - Last Call - pktcSigDevCodecTable (Issue1)

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 20 Jan 2004 13:49:47 -0800

David De Reu wrote:

> In contrast, the current definition provides 
> very little extra information above having just 
> a list of supported codecs. Will the maximum number 
> of codec sessions as it is defined now not always 
> equal the number of ports the MTA has?

It depends on how you interpret the existing (draft-02) table
definition. If the interpretation is such that the table should contain
the max number of connections an MTA is capable of supporting for any
given CODEC type provided that no other CODEC is used on any other
connection, then the answer to your question is "no" as the number of
connections is not equal to the number of end-points. Also, along with
mandatory CODECs (like PCMU), an MTA might or might not have support for
optional CODECs (like G728), so the number of CODECs might be "0".

If the interpretation of the table is such that the table defines the
max number of connections when all supported CODECs are used, then the
answer is not definite as the the table structure in draft-02 cannot
accommodate this information. 

The description of the "pktcSigDevCodecMax" MIB Object in this table
makes me think that the second choice most likely was the initial intent
of the "pktcSigDevCodecTable" table in draft-02 but I think the table's
existing structure cannot fit the bill as there might be several (not
one as it's assumed in draft-02) combinations of the CODECs an MTA can
support. Depending on the particular CODEC comnbination, the max number
of connections might differ.

Eugene Nechamkin,
Broadcom Corp.

Ph: (604) 233-8500

-----Original Message-----
From: David De Reu [mailto:[email-masked]] 
Sent: Monday, January 19, 2004 8:03 AM
To: IPCDN Mailing List
Subject: [ipcdn] Re: Signaling MIB - Draft 3 - Last Call -
pktcSigDevCodecTable (Issue1)

Another advantage of having multiple indexing in the
pktcSigDevCodecTable (i.e. being able to obtain all possible codec
combinations from the MTA), is the added value when you are
debugging/troubleshooting.

Suppose you find out that an MTA refuses to create a given connection
and you want to know why. The response code in the NCS error response,
and the optional comment string, are not always very clear on the exact
reason for the failure. In this case, you can maybe use the
pktcSigDevCodecTable for troubleshooting. Having the full list of codec
combinations available can be interesting here.

In contrast, the current definition provides very little extra
information above having just a list of supported codecs. Will the
maximum number of codec sessions as it is defined now not always equal
the number of ports the MTA has?

_____________________________________________________
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