Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-signaling-07.txt

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 8 Dec 2004 19:37:54 -0800

After looking at the Signaling MIB draft-07
(draft-ietf-ipcdn-pktc-signaling-07.txt) more closely, here are some
comments/concerns we would like to be addressed for the next release of
the draft:

1. PktcCodecType:

The following sentence in the DESCRIPTION clause:

		"Literal Codec Name Column 
             contains the codec name used in the local connection 
             descriptor (LCD) of the NCS messages create connection 
             (CRCX)/modify connection (MDCX) and is also used to 
             identify the codec in the Call Management System (CMS) 
             Provisioning Specification."

Should be changed as follows:

change/local connection descriptor (LCD)/local connection options (LCO)/

		"Literal Codec Name Column 
             contains the codec name used in the local connection 
             options (LCO) of the NCS messages create connection 
             (CRCX)/modify connection (MDCX) and is also used to 
             identify the codec in the Call Management System (CMS) 
             Provisioning Specification."

2. PktcRingCadence:

In the DESCRIPTION clause:

I. Delete/(Note: A minimum number of octets required to encode the
bit-string MUST be used)./

The "note" is not making much sense as each additional '0' bit requires
the tone to be encreased by the 50msec, therefore the required time
length of the tone will define the actual number of octets, rather than
the requirement in the "note".

II. change/the former value indicating 'repeatability' 
          and the latter indicating 'non-repeatability'/
          the latter value indicating 'repeatability' 
          and the former indicating 'non-repeatability'./

This has been already noticed in some other e-mail but is mentioned here
just for the sake of completeness.

3. pktcNcsEndPntConfigTSMax:

The existing DESCRIPTION clause is:

           " This object is used as part of a MTA retransmission 
            algorithm when communicating with a call agent. This object 
            contains the maximum time in seconds since the sending of 
            the initial datagram to a call agent. If more than 
            pktcNcsEndPntConfigTSMax time has elapsed, the endpoint 
            becomes disconnected."  

The description is incorrect. With the latest NCS specifications you do
not become disconnected after TsMax, but only after 2*Thist with no
response.

The following DESCRCIPTION is proposed instead of the existing one:

           " This object is used as part of a NCS retransmission 
            algorithm which MTA must follow when communicating with a
call agent. 
            This object contains the maximum time in seconds which any
datagram can 
            be sent to the callagent for. If more time elapsed than this
object contains, 
            then the retransmission must cease."

4. pktcNcsEndPntConfigTdinit:

The existing DESCRIPTION clause is:

           "This object contains the initial number of seconds the MTA  
            waits after a disconnect, before initiating the 
            disconnected procedure with the call agent."  

The description is incorrect. It is not the actual initial number of
seconds but it is the maximum value that the disconnected timer can be
initialized to randomly between 0 and TdInit. 

The following DESCRCIPTION is proposed instead of the existing one:

          " This object is used as part of a MTA disconnect procedure
when 
            communicating with a call agent. The object contains the
maxumum 
            value of the randomly generated number which initializes the
            disconnected timer. When the latter elapses, the MTA
initiates 
            the disconnect procedure for the particular endpoint."

5. pktcNcsEndPntConfigTdmin:

The existing DESCRIPTION clause is:

           " This object contains the minimum number of seconds the MTA

             waits after a disconnect, before initiating the 
             disconnected procedure with the call agent."   

The description is incorrect. This is only the minimum amount of time to
wait to begin the disconnected procedure in the case that local user
activity has triggered the sending of the RSIP message. That is the only
case that Tdmin applies.

The following DESCRCIPTION is proposed instead of the existing one:

           " This object is used as part of a MTA disconnect procedure
when 
             communicating with a call agent. This is the minimum amount
of 
             time to wait to begin the disconnected procedure only in
the case 
             that local user activity has triggered the sending of the
RSIP message."

6. pktcNcsEndPntConfigMinHookFlash
pktcNcsEndPntConfigMaxHookFlash
pktcNcsEndPntConfigPulseDialMinMakeTime
pktcNcsEndPntConfigPulseDialMaxMakeTime
pktcNcsEndPntConfigPulseDialMinBreakTime
pktcNcsEndPntConfigPulseDialMaxBreakTime

Issue: The MIB currently allows for pulse dial and hook flash to
overlap. This creates confusion when a change is detected on the line,
whether to report a pulse digit or hookflash. Therefore, the MIB must
either enforce that the two don't overlap (ie. minHookFlash must be
greater than pulseDialMaxMake) or there should be other criteria for the
MTA to decide which of the two to report. Standard PSTN telephone
interface reports pulse dial only before the connection is established
(call setup) and hookflash once a call is up and running. However, from
a NCS perspective either DTMF (pulse dial) and hook-flash can be
requested at any time independent of connection status.

Proposed the following:

Add the following sentence to the description clause of the
pktcNcsEndPntConfigMinHookFlash:

           " Because of the possibility for pulse dial and hook flash to
overlap,
             the value of this object MUST be greater than the value in
the 
             pktcNcsEndPntConfigPulseDialMaxMakeTime MIB Object."

Add the following sentence to the description clause of the
pktcNcsEndPntConfigPulseDialMaxMakeTime :

           " Because of the possibility for pulse dial and hook flash to
overlap,
             the value of this object MUST be less than the value in the

             pktcNcsEndPntConfigMinHookFlash MIB Object."

7. pktcSigDevToneType:

The existing DESCRIPTION clause is:

           "Unique value ranging from 1 to 21 that will correspond to 
            the different tone types. These tones can be provisioned 
            based on country specific needs. This object defines the 
            type of tone being accessed. The alertingSignal, 
            specialDial, specialInfo, release, congestion and 
            userDefined1-4 tone types are used in the E line package."  
 
Issue: The tones alertingSignal, specialDial, specialInfo, release,
congestion and userDefined1-4 are not defined in the E line package that
we can find. In fact, it is unclear how these tones would be signaling
via NCS. 

Potential solutions:
	- the last sentence of the descriptoin clause is removed,
	- remove or clarify the following from the SYNTAX clause of the
object:
                    alertingSignal(13), 
                    specialDial(14), 
                    specialInfo(15), 
                    release(16), 
                    congestion(17), 
                    userDefined1(18), 
                    userDefined2(19), 
                    userDefined3(20), 
                    userDefined4(21)  

8. pktcSigDevCIDMode, pktcSigDevCallerIdSigProtocol:
 
Existing default values for these two objects are 

       DEFVAL { dtAsETS }   -- for pktcSigDevCIDMode
       DEFVAL { fsk}        -- for pktcSigDevCallerIdSigProtocol

Issue: The existing default values for the on-hook Caller ID items do
not make sense. The DTAS alerting mode is mainly used for off-hook
caller ID, not on-hook. There are very few countries that deploy DTAS
alerting for on-hook caller ID (Denmark, Brazil) but they require dtmf
signalling protocol not fsk. 

Proposed: the default on-hook caller ID mode (pktcSigDevCIDMode) to
change to rpAsETS.

Eugene Nechamkin,

Broadcom Corp.
Ph: (604) 233-8500

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn