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

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

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 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

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

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)

From: Sumanth Channabasappa
Sent: Friday, February 10, 2006 8:32 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] Feedback: draft-ietf-ipcdn-pktc-signaling-09

Folks,

I am sending across this email to solicit feedback on "draft-ietf-ipcdn-pktc-signaling-09" (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-09.txt)

The comments I have received thus far include:

a) Proposal to modify the current draft to allow for DTMF to be used fo VMWI (it currently assumes FSK)

b) Preservation of contiguous numbering (editorial?)

Details can be found at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01812.html

c) Offline comments on the need for distinction between CID v/s VMWI (Phil, can you post more details on that)?

If resolutions to the above issues are agreed upon, I plan to propose a new draft revision as early as next week.

regards

Sumanth

--------------- Usage of DTMF and FSK for VMWI (source: Eugene Nechamkin, via email)

There are currently four CallerID signalling methods defined in Telco specs. They are:

1. Class I with FSK

2. Class I with DTMF

3. VMWI with FSK

4. VMWI with DTMF

While the current draft-09 contains the means of defining the 1st two (via "pktcSigDevCallerIdSigProtocol" MIB Object), it does not allow to choose the protocol for VMWI. The draft always assumes that for VMWI, it's always FSK method which is used.

We found that in some countries (e.g. Denmark) the #4 method is required (as per "TDK-TS 900 301-5"). There are also other contries which require VMWI with DTMF (Brazil, Sweden, Netherlands). Here is the quotation from the document:

The MWI supplementary service enables the served user to receive an indication when a message has been delivered to the user's mailbox.

NOTE: The MWI supplementary service can currently only be used in conjunction with one of TDC Tele Danmark’s public voice-mailbox services.

The served user can receive a message waiting indication from the VMS in two different ways:

a) Deferred mode: when the MWI supplementary service is activated and the served user makes an outgoing call attempt, the served user is notified by means of announcement; and/or;

b) Immediate mode: when the MWI supplementary service has been activated, the served user is notified by means of DTMF based signalling. The intention with this notification is to give the user’s terminal the opportunity to visually indicate to the user (e.g. by means of an indication lamp) that a new message has been delivered to the VMS.

Assuming that everybody agrees that this is a deficiency of the current draft-09, the following new MIB object is proposed to fix that:

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 signalling the Information on Visual Message Waiting Indicator (VMWI).
            Different countries define different VMWI signalling 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 }

----------------------------------------------------------------------------------------------------------------------------------