[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09
The following are the commments on the proposed.
1. General comment: all new objects are introduced in such a way that it
may change the OIDs of most of the previously existing objects in the
"pktcSigDevConfigObjects" group. To minimize the potential negative
impact, I would propose placing all new objects immediately after the
last object in the "pktcSigDevConfigObjects" group (i.e. after
pktcSigDevMultiFreqToneTable).
2. pktcSigDevCIDModePreamble & pktcSigDevCIDModePostamble objects:
The object definitions have several issues which require some more
clarifications:
- The line "This object identifies the subscriber line protocol used
for signaling caller id information" is incorrect because there is
already a MIB Object identifying the caller id signaling protocol -
"pktcSigDevCallerIdSigProtocol".
- The description should emphasize that the the new object is
applicable only when pktcSigDevCallerIdSigProtocol = dtmf(2)
- Object Naming is not aligned with ETSI EN 300 659-1 Spec's
terminology. The latter one uses "start code" and "end code" for calling
number instead of using "Preamble", and "Postamble". Proposed: change
the name pktcSigDevCIDModePreamble to be "pktcSigDevCIDStartCode" and
change the name pktcSigDevCIDModePostamble to be "pktcSigDevCIDEndCode".
- the example in the description clause of the
pktcSigDevCIDModePostable object is not correct: "The DTMF code "B" may
be sent by the network as start code for the transfer of information
values,through which special events can be indicated to the user" - as
per ETSI spec, "B" is a start code (preamble) not end code (postamble).
The description should have used "C" instead as an example of the end
code.
- reference clause for the objects would be helpfull at the
implementatoin stage as a pointer for the particular details.
The following is proposed modifcations which will address these
concerns:
pktcSigDevCIDModeDtmfStartCode OBJECT-TYPE
SYNTAX INTEGER {
DTMFcodeA (1),
DTMFcodeB (2),
DTMFcodeC (3),
DTMFcodeD (4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object identifies the 'start code' for the Dual Tone
Multi-Frequency (DTMF)
based subscriber line protocol used for signalling caller id
information.
Different countries define different caller id signalling
protocols to support caller
identification. When DTMF is used, the CID digits are
preceded by a start code digit
<A><S1>...<Sn><D><S1>...<Sn><B><S1>...<Sn><C>
the digit transmission sequence <S1>...<Sn> Digits (0 - 9)
The start code for calling number delivery may be DTMF "A"
or "D".
The DTMF code "B" may be sent by the network as a start code
for the
transfer of information values,through which special events
can be
indicated to the user. The DTMF code "D" may be sent to
indicate a
redirecting number.
The MTA must use this object only when
pktcSigDevCallerIdSigProtocol is
set to dtmf(2), and must not use it - otherwise."
REFERENCE
" ETSI-EN-300-659-1 Specification, Annex B"
DEFVAL { DTMFcodeA }
::= { pktcSigDevConfigObjects X }
pktcSigDevCIDDtmfEndCode OBJECT-TYPE
SYNTAX INTEGER {
DTMFcodeA (1),
DTMFcodeB (2),
DTMFcodeC (3),
DTMFcodeD (4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object identifies the 'end code' for the Dual Tone
Multi-Frequency (DTMF)
based subscriber line protocol used for signalling caller id
information.
Different countries define different caller id signalling
protocols to
support caller identification. When DTMF is used the CID
digits are followed
by an end code digit
<A><S1>...<Sn><D><S1>...<Sn><B><S1>...<Sn><C>
the digit transmission sequence <S1>...<Sn> Digits (0 - 9)
The DTMF code "C" may be sent by the network as an end code
after the
transfer of information or calling line identity values.
The MTA must use this object only when
pktcSigDevCallerIdSigProtocol
is set to dtmf(2), and must not use it - otherwise."
DEFVAL { DTMFcodeC }
::= { pktcSigDevConfigObjects X }
3. I agree with the idea to make the objects' names indpendent of the
CID Signaling Method chosen (FSK or DTMF). However, there are some
concerns on the consistency of the naming convention for the new names.
The previous naming convention was that "pktcSigDevCID" was the "base
name", and the rest represented the object's functionality
(FskAfterRing, RingAfterFsk, etc.). If the same base is still in use,
than some objects don't really reflect the actual functionality
(AfterRing, AfterDTAS,...). If the base is now meant to be "pktcSigDev"
than the last object has CID twice (CIDRingAfterCID).
I think if we accept that the new "name base" is "pktcSigDev", but use a
new name for the "pktcSigDevCIDRingAfterCID" MIB Object to be
"pktcSigDevRingAfterCID", then the new MIB objects names will be more
consistant.
4. MAX-ACCESS method for the MIB Objects related to the CallerID and
VMWI functionlity. Currently, its defined as "read-write" which
essentially means that the Caller ID Siganling Protocol and its
parameters can be changed "on-the-fly" by the Operator. Realistically,
the caller id protocol and parameters are not modified on the fly (if at
all) for the given country, and given conditions in the field. If so,
then "read-write" access becomes unneccessary complication in the MTA
implementation and configuration. Hence - the "read-only" access for MIB
Objects controlling the CallerID parameters seems to be sufficient for
such objects (e.g. pktcSigDevCallerIdSigProtocol,
pktcSigDevVmwiSigProtocol, pktcSigDevCIDAfterRing,
pktcSigDevCIDAfterDTAS, pktcSigDevVmwiAfterDTAS,
pktcSigDevVwmiAfterRPAS, etc). Obvioulsy, the MTA must be able to
configure these objects via the MTA Confguration File during MTA
provisioning after the reset.
Eugene.
------------------------------------------------------------------------
--------
From: Sumanth Channabasappa [mailto:sumanth at cablelabs.com]
Sent: Monday, February 20, 2006 9:51 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09
Folks,
Based on the findings of Eugene and Phil (earlier mail enclosed at the
end of this email), the following changes have been proposed (by Phil -
thanks!) to draft-09 of the IETF Signaling MIB draft. I plan to submit a
new draft soon (with the proposed changes) and hence comments and
concerns would be appreciated at the earliest (I have not received any
feedback on the IPCDN reflector with reference to earlier emails
resulting in this proposal).
Thanks!
Sumanth
New objects:
pktcSigDevVmwiSigProtocol OBJECT-TYPE
SYNTAX INTEGER {
fsk (1),
dtmf (2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies the subscriber line protocol used
for signaling the Information on Visual Message Waiting
Indicator(VMWI). Different countries define different VMWI
signaling protocols to support VMWI service. Frequency shift
keying (FSK) is most commonly used. Dual tone multi-
frequency (DTMF) is an alternative."
DEFVAL { fsk }
::= { pktcSigDevConfigObjects X }
pktcSigDevCIDModePreamble OBJECT-TYPE
SYNTAX INTEGER {
DTMFcodeA (1),
DTMFcodeB (2),
DTMFcodeC (3),
DTMFcodeD (4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object identifies the subscriber line protocol used
for signaling caller id information. Different countries
define different caller id signaling protocols to support
caller identification. When Dual tone multi-frequency (DTMF)
is used the CID digits are preceeded by a pre-amble digit
<A><S1>...<Sn><D><S1>...<Sn><B><S1>...<Sn><C>
the digit transmission sequence <S1>...<Sn> Digits (0 - 9)
The DTMF code "B" may be sent by the network as start code
for the transfer of information values,through which special
events can be indicated to the user."
DEFVAL { DTMFcodeA }
::= { pktcSigDevConfigObjects X }
pktcSigDevCIDModePostamble OBJECT-TYPE
SYNTAX INTEGER {
DTMFcodeA (1),
DTMFcodeB (2),
DTMFcodeC (3),
DTMFcodeD (4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object identifies the subscriber line protocol used
for signaling caller id information. Different countries
define different caller id signaling protocols to support
caller identification. When Dual tone multi-frequency (DTMF)
is used the CID digits are followed by a post amble digit
<A><S1>...<Sn><D><S1>...<Sn><B><S1>...<Sn><C>
the digit transmission sequence <S1>...<Sn> Digits (0 - 9)
The DTMF code "B" may be sent by the network as start code
for the transfer of information values,through which special
events can be indicated to the user."
DEFVAL { DTMFcodeC }
::= { pktcSigDevConfigObjects X }
pktcSigDevCPEDisplay OBJECT-TYPE
SYNTAX INTEGER {
SI(1),
SO(2),
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The display format varies in some locations from the normal
alphanumeric characters (SI) to Katakana graphics (SO)
display based on user preferences. This element sets a CPE
signaling protocol byte to indicate to the CPE device the
proper format for the display of CID or VMWI messages.
Reference ITU T.50 A.1.27 and A.1.28 point to ISO 2022
(refer to RFC 1468)"
DEFVAL {SI}
::= {pktcSigDevConfigObjects x }
Additionally, it has been proposed that the name and/or description of
the following MIB Objects be changed to incorporate usage of DTMF and
FSK.
- pktcSigDevCIDFskAfterRing to pktcSigDevCIDAfterRing; + description
- pktcSigDevCIDFskAfterDTAS to pktcSigDevCIDAfterDTAS; + description
- pktcSigDevCIDFskAfterRPAS to pktcSigDevCIDAfterRPAS; + description
- pktcSigDevCIDRingAfterFsk to pktcSigDevCIDRingAfterCID; + description
- pktcSigDevVmwiFskAfterDTAS to pktcSigDevVmwiAfterDTAS; + description
- pktcSigDevVwmiFskAfterRPAS to pktcSigDevVwmiAfterRPAS;
+ description
- pktcSigDevVwmiFskDTASAfterLR to pktcSigDevVwmiDTASAfterLR;
+ description
- pktcSigDevCIDMode (description)
- pktcSigDevVmwiMode (description)
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn