[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ipcdn] Comments on draft-ietf-ipcdn-pktc-signaling-07.txt
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
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn