[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

 



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)
<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
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn