RE: Re: Signaling MIB - Draft 3 - Last Call - pktcSigDevCodecTable (Issue1)
"Eugene Nechamkin" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <24CDBA67F085904999751B3C4F9E8C0B9A4E70@nt-rmna-0740.ca.broadcom.com> |
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 protected]] 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 protected] https://www1.ietf.org/mailman/listinfo/ipcdn