Subject: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09

From: "Sumanth Channabasappa" <[email-masked]>
Date: Mon, 20 Feb 2006 10:51:24 -0700

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)

  _____  

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.t
xt)
 
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)
<Details enclosed at the end of this email>
 
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 }
 
------------------------------------------------------------------------
----------------------------------------------------------

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

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 21 Feb 2006 13:02:29 -0800

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:[email-masked]] 
Sent: Monday, February 20, 2006 9:51 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09

Folks,

Thanks!

Sumanth

New objects:

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 21 Feb 2006 15:50:27 -0800

There is a new object proposed - pktcSigDevCPEDisplay - which would
require some more clarification on its meaning and, potentially, on some
use case scenarios.

Based on the description, the primary purpose of this object is to
address the ability of the MTA to deal with Katakana graphics (SO)
display in countries like Japan. However, Japan's CallerID alerting
sequence is quite complicated and cannot be described or controlled by
any of the existing MIB Objects for CID modes in the current SigMIB
draft (duringRinging, DTAS, RPAS, LRAS - none will work for Japan). The
presense of the new pktcSigDevCPEDisplay object does not seem to help
either.

So, if the purpose of this object is to allow Management Station to
control the CID display character set in such countries as Japan, then
it does not seem to be sufficient as Sigaling MIB does currently cover
the CID parameters for Japan.

If the purpose of this object is just to allow the Management Station to
control the CID display character set of the MTA in countries other than
Japan and covered by the current draft, then it's not clear how
practical such goal is, and some use case scenarios would help to
clarify that.

Regards,
Eugene.

Folks,

Thanks!

Sumanth

New objects:

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 21 Feb 2006 12:11:23 -0800

DTMFcodeA (1),

                             DTMFcodeB (2),

                             DTMFcodeC (3),

                             DTMFcodeD (4)

       } 
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  

        REFERENCE  

        DEFVAL { DTMFcodeA }

                             DTMFcodeA (1),

                             DTMFcodeB (2),

                             DTMFcodeC (3),

                             DTMFcodeD (4)

       } 
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  

            by an end code digit

        DEFVAL { DTMFcodeC } 

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.

Eugene.

________________________________

Folks,

 

Thanks!

Sumanth

New objects:

       SYNTAX       INTEGER { 

                            fsk  (1), 

                            dtmf (2) 

       } 

       MAX-ACCESS   read-write  

       STATUS       current  

       DESCRIPTION  

        DEFVAL { fsk } 

       SYNTAX       INTEGER { 

                             DTMFcodeA (1),

                             DTMFcodeB (2),

                             DTMFcodeC (3),

                             DTMFcodeD (4)

       } 

       MAX-ACCESS   read-write  

       STATUS       current  

       DESCRIPTION  

        DEFVAL { DTMFcodeA } 

 

       SYNTAX       INTEGER { 

                             DTMFcodeA (1),

                             DTMFcodeB (2),

                             DTMFcodeC (3),

                             DTMFcodeD (4)

       } 

       MAX-ACCESS   read-write  

       STATUS       current  

       DESCRIPTION  

        DEFVAL { DTMFcodeC } 

 

       SYNTAX       INTEGER { 

                    SI(1), 

                    SO(2), 

                    } 

       MAX-ACCESS read-write 

       STATUS current  

       DESCRIPTION  

           (refer to RFC 1468)" 

       DEFVAL {SI}  

 

                                                 + description

                                                 + description

________________________________

Folks,

 

 
 
 regards
Sumanth

1. Class I with FSK
2. Class I with DTMF
3. VMWI with FSK
4. VMWI with DTMF