RE: RE: IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments

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 protected]] 
	Sent: Thu 1/15/2004 1:17 PM 
	To: '[email protected]' 
	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 protected]' 
	> 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 protected] 
	>