Subject: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 28 Jan 2004 23:53:04 -0800

Please find the following are comments Broadcom has for on Signaling MIB draft-03 candidate:
 
Section 1: 
First, on the 5 topics that were raised on the reflector and below: 
 
Issue #1 - We support the proposed modifications of the pktcSigDevCodecTable table to reflect MTA codec capabilities.
 
Issue #2 - Modification of the pktcSigPulseSignalTable to include 5 additional signals 
Opinion: We are fine with most of the changes for the pulse metering objects (see some suggestions below). As well, the e-mails seem to discuss removal of pktcSigDevRtCadence in this item. We agree with Motorola. This should be removed.
 
Issue #3 - Modification of pktcSigDevToneType and elimination of DTMF 0-15, A-D, etc. 
Opinion: Draft-03 looks correct, tones that we wanted eliminated are gone. Motorola feels that several of the tones should be brought back into the specification. They stated that they are undergoing an effort to get the signaling mechanism enhanced to be able to use these. We do not disagree with this proposal as long as there is some way to initiate these from NCS signaling. DTMF should stay out independent of this decision.
 
Issue #4 - Proposed need for dB power levels for individual frequencies in the pktcSigDevToneTable table 
Opinion: Agree with Motorola - leave this as a single value per tone profile, not a different MIB setting for each frequency. However, we do need to clarify the wording to indicate that the value in this setting applies to each tone frequency, not the overall tone level. We have suggested this previously, but it hasn't yet been incorporated.
 
Issue #5 - Proposed introduction of country codes for telephony parameters 
Opinion: Tend to agree with Motorola - leave this out unless there  ius a very strong reason for doing otherwise.  *IF* it is added then each country default settings need to be very well documented.
 
Summary: Existing draft-03 canditate looks OK to us, provided that corresponding wording is added to address our clarification in Issue #4 (per frequency).
 
Section 2: 
 
New issues that we feel need to be accommodated in the draft-03. 
 
Issue #6 - ranges for some values need to be changed 
a) pktcSigDevCIDFskAfterRing - minimum should be 50 (not 0) 
b) pktcSigDevCIDFskAfterDTAS - minimum should be 50 (not 0) 
c) pktcSigDevCIDRingAfterFSK - minimum should be 50 (not 0) 
d) pktcSigDevCIDDTASAfterLR  - minimum should be 50 (not 0) 
e) pktcSigDevVmwiDTASAfterLR - minimum should be 50 (not 0) 
 
Issue #7 - definition of pktcSigDevToneDbLevel 
In draft-02, this object was specified as follows: 
pktcSigDevToneDbLevel    OBJECT-TYPE 
    SYNTAX       Integer32 (-60..4) 
    UNITS        "dbm" 
    MAX-ACCESS   read-write 
    STATUS       current 
    DESCRIPTION 
        " This is the decibel level at which tones could be 
          generated." 
    DEFVAL { -4 } 
    ::={pktcSigDevToneEntry 2 } 
 
In the current draft-03, this object is specified as follows: 
 
pktcSigDevToneDbLevel    OBJECT-TYPE 
    SYNTAX       Integer32 (-60..4) 
    UNITS        "dbm" 
    MAX-ACCESS   read-write 
    STATUS       current 
    DESCRIPTION 
        " This is the decibel level at which tones could be 
          generated at the a and b terminals (TE connection point)." 
    DEFVAL { -4 } 
    ::={pktcSigDevToneEntry 2 } 
 
The change initially resulted from us asking for clarification of the reference point of the tone generation. It was discussed and decided that the analog TE connection point would be a good reference. However, after more discussions, we think this was not the right decision. The combination of defining this at the analog interface along with the large range (specifically the very high value of 4) places certain restrictions on the DSP architecture in order to meet the worst case requirements. The primary problem this approach leads to is loss of SNR due to quantization at high attenuation values. 
 
As well, we are not convinced that the change was really a good thing. First, it creates a discrepancy between the dB reference level in the RTP stream and that requested by the tone generation. Take for example Belgium, which has a 10dB loss in the digital->analog direction defined in its loss plan. A -5 dB tone passed over the G.711 RTP stream will be heard on the analog interface at a level of -15dBm. However, if the MIB asks for -5dBm then the tone will be played out at -5 dBm. In addition, generating tones with such high levels (+4dBm) in countries that have a high loss plan is not a realistic scenario - it will never be used.
 
We believe by defining the tone level in the MIB in this fashion, we are creating a spec requirement that: a) does not meet any real-world requirements, b) adds complexity (cost) to the MTA architecture and c) degrades the performance that could be obtained. We highly recommend changing this MIB to alleviate these problems to reference the digital reference point rather than analog. Then the DLP would apply to the tone the same as the RTP path. The new MIB would be defined as:
 
pktcSigDevToneDbLevel    OBJECT-TYPE 
    SYNTAX       Integer32 (-60..4) 
    UNITS        "dbm" 
    MAX-ACCESS   read-write 
    STATUS       current 
    DESCRIPTION 
        " This is the decibel level for each frequency at which tones should be 
          generated (reference point is the digital interface)." 
    DEFVAL { -4 } 
    ::={pktcSigDevToneEntry 2 } 

Eugene.

	-----Original Message----- 
	From: Beacham Gordon-CGB005 [mailto:[email-masked]] 
	Sent: Thu 1/15/2004 1:17 PM 
	To: [email-masked]' 
	Cc: 
	Subject: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments

	I'm resending the attachments separately since the email bounced. Gordon 

	 <<draft-ietf-ipcdn-pktc-signaling-03.rtf>> 

	>  -----Original Message----- 
	> From:         Beacham Gordon-CGB005  
	> Sent: Thursday, January 15, 2004 11:02 AM 
	> To:   [email-masked]' 
	> Subject:      IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments 
	> 
	> 
	> Attached is draft 3 of the Signaling MIB based on the changes requested in a document posted by Broadcom to the IPCDN mailing list on 11/27/2003 (also attached).

	> 
	> To date there has been no comment on any of these issues from the community. Therefore, I am making a request for last call comments on these proposed changes. Please submit any comments on the changes to the reflector by 1/29/2004.

	> 
	> There are five primary changes that I will start separate email threads for if you have comments to make: 
	> 
	> 1. Modification of the pktcSigDevCodecTable table to reflect MTA codec capabilities 
	> 2. Modification of the pktcSigPulseSignalTable to include 5 additional signals 
	> 3. Modification of pktcSigDevToneType and elimination of DTMF 0-15, A-D, etc. 
	> 4. Proposed need for dB power levels for individual frequencies in the pktcSigDevToneTable table 
	> 5. Proposed introduction of country codes for telephony parameters 
	> 
	>  << File: draft-ietf-ipcdn-pktc-signaling-03.rtf (Compressed) >> 
	>  << File: Comments on SIG MIB draft-02 (BRCM)_2003-11-27.doc >> 
	> 
	> Gordon Beacham 
	> Digital Core Gateways, BCS 
	> Motorola, Inc. 
	> 858-404-2335 
	> [email-masked] 
	> 

3fj)b�	b��3bz��m��?�0�'�~���f��f��X��)ߣ��q�

---

From: "David De Reu" <[email-masked]>
Date: Fri, 30 Jan 2004 17:29:49 +0100

> Issue #7 - definition of pktcSigDevToneDbLevel
...
>     ::={pktcSigDevToneEntry 2 } 
...
> The combination of defining this at the analog interface along with
> the large range (specifically the very high value of 4) places certain
> restrictions on the DSP architecture in order to meet the worst case
> requirements.
...

It is not that I disagree a priori with the proposed change, it just
raises a few questions:

(1) The analog reference point seems the logical reference point to use,
    since this table is about signals that will be generated on the
    analog line. When the reference point is changed to the digital
    reference point, will this not be confusing for someone who wants to
    fill out the values in the table? Maybe that person will have to do
    a quick calculation to calculate what digital dB level he must
    provide to obtain the analog dB level he wants, but if this is the
    case, can the MTA not do this calculation?

    Second, just as a tought, would the problem also be solved by
    leaving the description of the object as it is, but changing the
    range limits?

(2) Does this discussion also apply to the pktcSigPulseSignalDbLevel
    object? In other words, I think the interpretation chosen for the
    tone dB level should also be the one for the pulse signal dB level,
    and clarified in the defintion of the latter as well.

    Also, is it intentional that the SYNTAX of the
    pktcSigPulseSignalDbLevel object is TenthdBm, and that it is
    Integer32 for pktcSigDevToneDbLevel?

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn