[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09
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.
------------------------------------------------------------------------
--------
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
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn