that BEI is not to be
included in the ATM
signaling.
Ref.: ATM Forum UNI 4.0
TI 4010 Boolean Tagging Indicator
Value 0 indicates that
tagging is not allowed; value
1 indicates that tagging is
requested.
Ref.: ITU-T Q.2961.1
FD 4011 Boolean Frame Discard
Value 0 indicates that no
frame discard is allowed;
value 1 indicates that frame
discard is allowed.
Ref.: ATM Forum UNI 4.0
A2PCDV 4012 24-bit integer Acceptable 2-point CDV
Ref.: ITU-T Q.2965.2
C2PCDV 4013 24-bit integer Cumulative 2-point CDV
Ref.: ITU-T Q.2965.2
APPCDV 4014 24-bit integer Acceptable P-P CDV
Ref.: ATM Forum UNI 4.0
CPPCDV 4015 24-bit integer Cumulative P-P CDV
Ref.: ATM Forum UNI 4.0
ACLR 4016 8-bit integer Acceptable Cell Loss Ratio
Ref.: ITU-T Q.2965.2, ATM
Forum UNI 4.0
MEETD 4017 16-bit integer Maximum End-to-end transit
delay
Ref.: ITU-T Q.2965.2, ATM
Forum UNI 4.0
CEETD 4018 16-bit integer Cumulative End-to-end transit
delay
Ref.: ITU-T Q.2965.2, ATM
Forum UNI 4.0
QosClass 4019 Integer 0-5 QoS Class
QoS Class Meaning
0 Default QoS
associated
with the ATC
as defined
in ITU-T
Q.2961.2
1 Stringent
2 Tolerant
3 Bi-level
4 Unbounded
5 Stringent
Bi-level
Ref.: ITU-T Q.2965.1
AALtype 401A 1 octet AAL Type
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 0 AAL for
voice
0 0 0 0 0 0 0 1 AAL type 1
0 0 0 0 0 0 1 0 AAL type 2
0 0 0 0 0 0 1 1 AAL type
3/4
0 0 0 0 0 1 0 1 AAL type 5
0 0 0 1 0 0 0 0 user-
defined AAL
Ref.: ITU-T Q.2931
C.5 Frame Relay
PropertyID Property Type Value
tag
DLCI 5001 Unsigned Data link connection
integer id
CID 5002 Unsigned sub-channel id
integer
SID/Noiselevel 5003 Unsigned silence insertion
integer descriptor
Primary Payload 5004 Unsigned Primary Payload Type
type integer Covers FAX and codecs
C.6 IP
PropertyID Property tag Type Value
IPv4 6001 32 bits Ipv4Address Ipv4Address
Ref.: IETF RFC791
IPv6 6002 128 bits IPv6 Address
Ref.: IETF RFC2460
Port 6003 Unsigned integer 0..65535
Porttype 6004 Enumerated TCP(0), UDP(1), SCTP(2)
C.7 ATM AAL2
PropertyID Property Type Value
tag
AESA 7001 20 octets AAL2 service endpoint
address as defined in
the referenced
Recommendation.
ESEANSEA
Ref.: ITU-T Q.2630.1
BIR See C.3 4 octets Served user generated
reference as defined in
the referenced
Recommendation.
SUGR
Ref.: ITU-T Q.2630.1
ALC 7002 12 octets AAL2 link
characteristics as
defined in the
referenced
Recommendation.
Maximum/Average CPS-SDU
bit rate;
Maximum/Average CPS-SDU
size
Ref.: ITU-T Q.2630.1
SSCS 7003 I.366.2: Audio (8 Service specific
octets); Multirate (3 convergence sublayer
octets), or I.366.1: information as defined
SAR-assured (14 in:
octets);SAR-unassured - ITU-T Q.2630.1,and
(7 octets). used in:
- ITU-T I.366.2:
Audio/Multirate;
- ITU-T I.366.1: SAR-
assured/unassured.
Ref.: ITU-T Q.2630.1,
I.366.1 and I.366.2
SUT 7004 1..254 octets Served user transport
parameter as defined in
the referenced
Recommendation.
Ref.: ITU-T Q.2630.1
TCI 7005 Boolean Test connection
indicator as defined in
the referenced
Recommendation.
Ref.: ITU-T Q.2630.1
Timer_CU 7006 32-bit integer Timer-CU
Milliseconds to hold
partially filled cell
before sending.
MaxCPSSDU 7007 8-bit integer Maximum Common Part
Sublayer Service Data
Unit
Ref.: ITU-T Q.2630.1
CID 7008 8 bits subchannel id: 0-255
Ref.: ITU-T I.363.2
C.8 ATM AAL1
PropertyID Property Type Value
tag
BIR See table 4-29 octets GIT (Generic Identifier
in C.3 Transport)
Ref.: ITU-T Q.2941.1
AAL1ST 8001 1 octet AAL1 Subtype
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 0 null
0 0 0 0 0 0 0 1 voiceband
signal transport on 64 kbit/s
0 0 0 0 0 0 1 0 circuit
transport
0 0 0 0 0 1 0 0 high-quality
audio signal transport
0 0 0 0 0 1 0 1 video signal
transport
Ref.: ITU-T Q.2931
CBRR 8002 1 octet CBR Rate
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 1 64 kbit/s
0 0 0 0 0 1 0 0 1544 kbit/s
0 0 0 0 0 1 0 1 6312 kbit/s
0 0 0 0 0 1 1 0 32 064 kbit/s
0 0 0 0 0 1 1 1 44 736 kbit/s
0 0 0 0 1 0 0 0 97 728 kbit/s
0 0 0 1 0 0 0 0 2048 kbit/s
0 0 0 1 0 0 0 1 8448 kbit/s
0 0 0 1 0 0 1 0 34 368 kbit/s
0 0 0 1 0 0 1 1 139 264 kbit/s
0 1 0 0 0 0 0 0 n x 64 kbit/s
0 1 0 0 0 0 0 1 n x 8 kbit/s
Ref.: ITU-T Q.2931
MULT See table Multiplier, or n x 64k/8k/300
in C.9 Ref.: ITU-T Q.2931
SCRI 8003 1 octet Source Clock Frequency Recovery
Method
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 0 null
0 0 0 0 0 0 0 1 SRTS
0 0 0 0 0 0 1 0 ACM
Ref.: ITU-T Q.2931
ECM 8004 1 octet Error Correction Method
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 0 null
0 0 0 0 0 0 0 1 FEC - Loss
0 0 0 0 0 0 1 0 FEC - Delay
Ref.: ITU-T Q.2931
SDTB 8005 16-bit Structured Data Transfer
integer Blocksize
Block size of SDT CBR service
Ref.: ITU-T I.363.1
PFCI 8006 8-bit Partially filled cells identifier
integer 1-47
Ref.: ITU-T I.363.1
C.9 Bearer capabilities
The table entries referencing Recommendation Q.931 refer to the
encoding in the bearer capability information element of Q.931, not
to the low layer information element.
PropertyID Tag Type Value
TMR 9001 1 octet Transmission Medium
Requirement (Q.763)
Bits
87654321
--------
00000000 speech
00000001 spare
00000010 64 kbit/s
unrestricted
00000011 3.1 kHz audio
00000100 reserved for
alternate speech (service
2)/64 kbit/s unrestricted
(service 1)
00000101 reserved for
alternate 64 kbit/s
unrestricted (service
1)/speech (service 2)
00000110 64 kbit/s preferred
The assigned codepoints
listed below are all for
unrestricted service.
00000111 2 x 64 kbit/s
00001000 384 kbit/s
00001001 1536 kbit/s
00001010 1920 kbit/s
00001011
through
00001111 spare
00010000
through
00101010:
3 x 64 kbit/s through
29 x 64 kbit/s
except
00010011 spare
00100101 spare
00101011
through
11111111 spare
Ref.: ITU-T Q.763
TMRSR 9002 1 octet Transmission Medium
Requirement Subrate
0 unspecified
1 8 kbit/s
2 16 kbit/s
3 32 kbit/s
Contcheck 9003 Boolean Continuity Check
0 continuity check not
required on this circuit
1 continuity check
required on this circuit
Ref.: ITU-T Q.763
ITC 9004 5 bits Information Transfer
Capability
Bits
5 4 3 2 1
---------
0 0 0 0 0 Speech
0 1 0 0 0 Unrestricted
digital information
0 1 0 0 1 Restricted
digital information
1 0 0 0 0 3.1 kHz audio
1 0 0 0 1 Unrestricted
digital information with
tones/announcements
1 1 0 0 0 Video
All other values are
reserved.
Ref.: ITU-T Q.763
TransMode 9005 2 bits Transfer Mode
Bits
2 1
---
0 0 Circuit mode
1 0 Packet mode
Ref.: ITU-T Q.931
TransRate 9006 5 bits Transfer Rate
Bits
5 4 3 2 1
---------
0 0 0 0 0 This code shall
be used for packet mode calls
1 0 0 0 0 64 kbit/s
1 0 0 0 1 2 x 64 kbit/s
1 0 0 1 1 384 kbit/s
1 0 1 0 1 1536 kbit/s
1 0 1 1 1 1920 kbit/s
1 1 0 0 0 Multirate (64
kbit/s base rate)
Ref.: ITU-T Q.931
MULT 9007 7 bits Rate Multiplier
Any value from 2 to n
(maximum number of B-
channels)
Ref.: ITU-T Q.931
layer1prot 9008 5 bits User Information Layer 1
Protocol
Bits
5 4 3 2 1
---------
0 0 0 0 1 ITU-T
standardized rate adaption
V.110 and X.30.
0 0 0 1 0 Recommendation
G.711 m-law
0 0 0 1 1 Recommendation
G.711 A-law
0 0 1 0 0 Recommendation
G.721 32 kbit/s ADPCM and
Recommendation I.460
0 0 1 0 1 Recommendations
H.221 and H.242
0 0 1 1 0 Recommendations
H.223 and H.245
0 0 1 1 1 Non-ITU-T
standardized rate adaption.
0 1 0 0 0 ITU-T
standardized rate adaption
V.120.
0 1 0 0 1 ITU-T
standardized rate adaption
X.31 HDLC flag stuffing
All other values are
reserved.
Ref.: ITU Recommendation
Q.931
syncasync 9009 Boolean Synchronous/Asynchronous
0 Synchronous data
1 Asynchronous data
Ref.: ITU-T Q.931
negotiation 900A Boolean Negotiation
0 In-band negotiation
possible
1 In-band negotiation not
possible
Ref.: ITU-T Q.931
Userrate 900B 5 bits User Rate
Bits
5 4 3 2 1
---------
0 0 0 0 0 Rate is
indicated by E-bits specified
in Recommendation I.460 or
may be negotiated in-band
0 0 0 0 1 0.6 kbit/s
Recommendations V.6 and X.1
0 0 0 1 0 1.2 kbit/s
Recommendation V.6
0 0 0 1 1 2.4 kbit/s
Recommendations V.6 and X.1
0 0 1 0 0 3.6 kbit/s
Recommendation V.6
0 0 1 0 1 4.8 kbit/s
Recommendations V.6 and X.1
0 0 1 1 0 7.2 kbit/s
Recommendation V.6
0 0 1 1 1 8 kbit/s
Recommendation I.460
0 1 0 0 0 9.6 kbit/s
Recommendations V.6 and X.1
0 1 0 0 1 14.4 kbit/s
Recommendation V.6
0 1 0 1 0 16 kbit/s
Recommendation I.460
0 1 0 1 1 19.2 kbit/s
Recommendation V.6
0 1 1 0 0 32 kbit/s
Recommendation I.460
0 1 1 0 1 38.4 kbit/s
Recommendation V.110
0 1 1 1 0 48 kbit/s
Recommendations V.6 and X.1
0 1 1 1 1 56 kbit/s
Recommendation V.6
1 0 0 1 0 57.6 kbit/s
Recommendation V.14 extended
1 0 0 1 1 28.8 kbit/s
Recommendation V.110
1 0 1 0 0 24 kbit/s
Recommendation V.110
1 0 1 0 1 0.1345 kbit/s
Recommendation X.1
1 0 1 1 0 0.100 kbit/s
Recommendation X.1
1 0 1 1 1 0.075/1.2
kbit/s Recommendations V.6
and X.1
1 1 0 0 0 1.2/0.075
kbit/s Recommendations V.6
and X.1
1 1 0 0 1 0.050 kbit/s
Recommendations V.6 and X.1
1 1 0 1 0 0.075 kbit/s
Recommendations V.6 and X.1
1 1 0 1 1 0.110 kbit/s
Recommendations V.6 and X.1
1 1 1 0 0 0.150 kbit/s
Recommendations V.6 and X.1
1 1 1 0 1 0.200 kbit/s
Recommendations V.6 and X.1
1 1 1 1 0 0.300 kbit/s
Recommendations V.6 and X.1
1 1 1 1 1 12 kbit/s
Recommendation V.6
All other values are
reserved.
Ref.: ITU-T Q.931
INTRATE 900C 2 bits Intermediate Rate
Bits
2 1
---
0 0 Not used
0 1 8 kbit/s
1 0 16 kbit/s
1 1 32 kbit/s
Ref.: ITU-T Q.931
nictx 900D Boolean Network Independent Clock
(NIC) on transmission
0 Not required to send
data with network independent
clock
1 Required to send data
with network independent
clock
Ref.: ITU-T Q.931
nicrx 900E Boolean Network independent clock
(NIC) on reception
0 Cannot accept data with
network independent clock
(i.e., sender does not support
this optional procedure)
1 Can accept data with
network independent clock
(i.e., sender does support
this optional procedure)
Ref.: ITU-T Q.931
flowconttx 900F Boolean Flow Control on transmission
(Tx)
0 Not required to send
data with flow control
mechanism
1 Required to send data
with flow control mechanism
Ref.: ITU-T Q.931
flowcontrx 9010 Boolean Flow control on reception
(Rx)
0 Cannot accept data with
flow control mechanism (i.e.,
sender does not support this
optional procedure)
1 Can accept data with
flow control mechanism (i.e.,
sender does support this
optional procedure)
Ref.: ITU-T Q.931
rateadapthdr 9011 Boolean Rate adaption header/no
header
0 Rate adaption header
not included
1 Rate adaption header
included
Ref.: ITU-T Q.931
multiframe 9012 Boolean Multiple frame establishment
support in data link
0 Multiple frame
establishment not supported.
Only UI frames allowed
1 Multiple frame
establishment supported
Ref.: ITU-T Q.931
OPMODE 9013 Boolean Mode of operation
0 Bit transparent mode of
operation
1 Protocol sensitive mode
of operation
Ref.: ITU-T Q.931
llidnegot 9014 Boolean Logical link identifier
negotiation
0 Default, LLI = 256 only
1 Full protocol
negotiation
Ref.: ITU-T Q.931
assign 9015 Boolean Assignor/assignee
0 Message originator is
"default assignee"
1 Message originator is
"assignor only"
Ref.: ITU-T Q.931
inbandneg 9016 Boolean In-band/out-band negotiation
0 Negotiation is done
with USER INFORMATION
messages on a temporary
signalling connection
1 Negotiation is done in-
band using logical link zero
Ref.: ITU-T Q.931
stopbits 9017 2 bits Number of stop bits
Bits
2 1
---
0 0 Not used
0 1 1 bit
1 0 1.5 bits
1 1 2 bits
Ref.: ITU-T Q.931
databits 9018 2 bits Number of data bits excluding
parity bit if present
Bits
2 1
---
0 0 Not used
0 1 5 bits
1 0 7 bits
1 1 8 bits
Ref.: ITU-T Q.931
parity 9019 3 bits Parity information
Bits
3 2 1
------
0 0 0 Odd
0 1 0 Even
0 1 1 None
1 0 0 Forced to 0
1 0 1 Forced to 1
All other values are
reserved.
Ref.: ITU-T Q.931
duplexmode 901A Boolean Mode duplex
0 Half duplex
1 Full duplex
Ref.: ITU-T Q.931
modem 901B 6 bits Modem Type
Bits
6 5 4 3 2 1
-----------
0 0 0 0 0 0 through
0 0 0 1 0 1 National use
0 1 0 0 0 1 Rec. V.21
0 1 0 0 1 0 Rec. V.22
0 1 0 0 1 1 Rec. V.22 bis
0 1 0 1 0 0 Rec. V.23
0 1 0 1 0 1 Rec. V.26
0 1 1 0 0 1 Rec. V.26 bis
0 1 0 1 1 1 Rec. V.26 ter
0 1 1 0 0 0 Rec. V.27
0 1 1 0 0 1 Rec. V.27 bis
0 1 1 0 1 0 Rec. V.27 ter
0 1 1 0 1 1 Rec. V.29
0 1 1 1 0 1 Rec. V.32
0 1 1 1 1 0 Rec. V.34
1 0 0 0 0 0 through
1 0 1 1 1 1 National use
1 1 0 0 0 0 through
1 1 1 1 1 1 User specified
Ref.: ITU-T Q.931
layer2prot 901C 5 bits User information layer 2
protocol
Bits
5 4 3 2 1
---------
0 0 0 1 0 Rec. Q.921/I.441
0 0 1 1 0 Rec. X.25, link
layer
0 1 1 0 0 LAN logical link
control (ISO/IEC 8802 2)
All other values are
reserved.
Ref.: ITU-T Q.931
layer3prot 901D 5 bits User information layer 3
protocol
Bits
5 4 3 2 1
---------
0 0 0 1 0 ITU-T Q.931
0 0 1 1 0 ITU-T X.25,
packet layer
0 1 0 1 1 ISO/IEC TR 9577
(Protocol identification in
the network layer)
All other values are
reserved.
Ref.: ITU-T Q.931
addlayer3prot 901E Octet Additional User Information
layer 3 protocol
Bits Bits
4 3 2 1 4 3 2 1
------- -------
1 1 0 0 1 1 0 0
Internet Protocol (RFC791)
(ISO/IEC TR 9577)
1 1 0 0 1 1 1 1
Point-to-point Protocol (RFC
1661)
Ref.: ITU-T Q.931
DialledN 901F 30 Dialled Number
octets
DiallingN 9020 30 Dialling Number
octets
ECHOCI 9021 Not Used. See H.248.1 E.13
for an example of possible
Echo Control properties.
NCI 9022 1 octet Nature of Connection
Indicators
Bits
2 1 Satellite Indicator
---
0 0 no satellite circuit
in the connection
0 1 one satellite circuit
in the connection
1 0 two satellite
circuits in the connection
1 1 spare
Bits
4 3 Continuity check
--- indicator
0 0 continuity check not
required
0 1 continuity check
required on this circuit
1 0 continuity check
performed on a previous
circuit
1 1 spare
Bit
5 Echo control device
- indicator
0 outgoing echo control
device not included
1 outgoing echo control
device included
Bits
8 7 6 Spare
Ref.: ITU-T Q.763
USI 9023 Octet User Service Information
string Ref.: ITU-T Q.763 Clause 3.57
C.10 AAL5 properties
PropertyID Property Type Value
tag
FMSDU A001 32-bit Forward Maximum CPCS-SDU Size:
integer Maximum CPCS-SDU size sent in the
direction from the calling user to
the called user.
Ref.: ITU-T Q.2931
BMSDU A002 32-bit Backwards Maximum CPCS-SDU Size:
integer Maximum CPCS-SDU size sent in the
direction from the called user to
the calling user.
Ref.: ITU-T Q.2931
SSCS See table See table See table in C.7
in C.7 in C.7 Additional values:
VPI/VCI
C.11 SDP equivalents
PropertyID Property Type Value
tag
SDP_V B001 String Protocol Version
Ref.: RFC2327
SDP_O B002 String Owner/creator and session ID
Ref.: RFC2327
SDP_S B003 String Session name
Ref.: RFC2327
SDP_I B004 String Session identifier
Ref.: RFC2327
SDP_U B005 String URI of descriptor
Ref.: RFC2327
SDC_E B006 String email address
Ref.: RFC2327
SDP_P B007 String phone number
Ref.: RFC2327
SDP_C B008 String Connection information
Ref.: RFC2327
SDP_B B009 String Bandwidth Information
Ref.: RFC2327
SDP_Z B00A String Time zone adjustment
Ref.: RFC2327
SDP_K B00B String Encryption Key
Ref.: RFC2327
SDP_A B00C String Zero or more session attributes
Ref.: RFC2327
SDP_T B00D String Active Session Time
Ref.: RFC2327
SDP_R B00E String Zero or more repeat times
Reference: RFC2327
SDP_M B00F String Media type, port, transport and format
Ref.: RFC2327
C.12 H.245
PropertyID Property Type Value
tag
OLC C001 Octet The value of H.245
OpenLogicalChannel structure.
string Ref.: ITU-T H.245
OLCack C002 Octet The value of H.245
string OpenLogicalChannelAck structure.
Ref.: ITU-T H.245
OLCcnf C003 Octet The value of H.245
string OpenLogicalChannelConfirm structure.
Ref.: ITU-T H.245
OLCrej C004 Octet The value of H.245
string OpenLogicalChannelReject structure.
Ref.: ITU-T H.245
CLC C005 Octet The value of H.245
string CloseLogicalChannel structure.
Ref.: ITU-T H.245
CLCack C006 Octet The value of H.245
string CloseLogicalChannelAck structure.
Ref.: ITU-T H.245
ANNEX D - Transport over IP
D.1 Transport over IP/UDP using Application Level Framing (ALF)
Protocol messages defined in this RFCmay be transmitted over UDP.
When no port is provided by the peer (see 7.2.8), commands should be
sent to the default port number: 2944 for text-encoded operation, or
2945 for binary-encoded operation. Responses must be sent to the
address and port from which the corresponding commands were sent.
ALF is a set of techniques that allows an application, as opposed to
a stack, to affect how messages are sent to the other side. A
typical ALF technique is to allow an application to change the order
of messages sent when there is a queue after it has queued them.
There is no formal specification for ALF. The procedures in Annex
D.1 contain a minimum suggested set of ALF behaviours
Implementors using IP/UDP with ALF should be aware of the
restrictions of the MTU on the maximum message size.
D.1.1 Providing At-Most-Once functionality
Messages, being carried over UDP, may be subject to losses. In the
absence of a timely response, commands are repeated. Most commands
are not idempotent. The state of the MG would become unpredictable
if, for example, Add commands were executed several times. The
transmission procedures shall thus provide an "At-Most-Once"
functionality.
Peer protocol entities are expected to keep in memory a list of the
responses that they sent to recent transactions and a list of the
transactions that are currently outstanding. The transaction
identifier of each incoming message is compared to the transaction
identifiers of the recent responses sent to the same MId. If a match
is found, the entity does not execute the transaction, but simply
repeats the response. If no match is found, the message will be
compared to the list of currently outstanding transactions. If a
match is found in that list, indicating a duplicate transaction, the
entity does not execute the transaction (see D.1.4 for procedures on
sending TransactionPending).
The procedure uses a long timer value, noted LONG-TIMER in the
following. The timer should be set larger than the maximum duration
of a transaction, which should take into account the maximum number
of repetitions, the maximum value of the repetition timer and the
maximum propagation delay of a packet in the network. A suggested
value is 30 seconds.
The copy of the responses may be destroyed either LONG-TIMER seconds
after the response is issued, or when the entity receives a
confirmation that the response has been received, through the
"Response Acknowledgement parameter". For transactions that are
acknowledged through this parameter, the entity shall keep a copy of
the transaction-id for LONG-TIMER seconds after the response is
issued, in order to detect and ignore duplicate copies of the
transaction request that could be produced by the network.
D.1.2 Transaction identifiers and three-way handshake
D.1.2.1 Transaction identifiers
Transaction identifiers are 32-bit integer numbers. A Media Gateway
Controller may decide to use a specific number space for each of the
MGs that they manage, or to use the same number space for all MGs
that belong to some arbitrary group. MGCs may decide to share the
load of managing a large MG between several independent processes.
These processes will share the same transaction number space. There
are multiple possible implementations of this sharing, such as having
a centralized allocation of transaction identifiers, or
pre-allocating non-overlapping ranges of identifiers to different
processes. The implementations shall guarantee that unique
transaction identifiers are allocated to all transactions that
originate from a logical MGC (identical mId). MGs can simply detect
duplicate transactions by looking at the transaction identifier and
mId only.
D.1.2.2 Three-way handshake
The TransactionResponse Acknowledgement parameter can be found in any
message. It carries a set of "confirmed transaction-id ranges".
Entities may choose to delete the copies of the responses to
transactions whose id is included in "confirmed transaction-id
ranges" received in the transaction response messages. They should
silently discard further commands when the transaction-id falls
within these ranges.
The "confirmed transaction-id ranges" values shall not be used if
more than LONG-TIMER seconds have elapsed since the MG issued its
last response to that MGC, or when a MG resumes operation. In this
situation, transactions should be accepted and processed, without any
test on the transaction-id.
Messages that carry the "Transaction Response Acknowledgement"
parameter may be transmitted in any order. The entity shall retain
the "confirmed transaction-id ranges" received for LONG-TIMER
seconds.
In the binary encoding, if only the firstAck is present in a response
acknowledgement (see A.2), only one transaction is acknowledged. If
both firstAck and lastAck are present, then the range of transactions
from firstAck to lastAck is acknowledged. In the text encoding, a
horizontal dash is used to indicate a range of transactions being
acknowledged (see B.2).
D.1.3 Computing retransmission timers
It is the responsibility of the requesting entity to provide suitable
timeouts for all outstanding transactions, and to retry transactions
when timeouts have been exceeded. Furthermore, when repeated
transactions fail to be acknowledged, it is the responsibility of the
requesting entity to seek redundant services and/or clear existing or
pending connections.
The specification purposely avoids specifying any value for the
retransmission timers. These values are typically network dependent.
The retransmission timers should normally estimate the timer value by
measuring the time spent between the sending of a command and the
return of a response. Implementations SHALL ensure that the
algorithm used to calculate retransmission timing performs an
exponentially increasing backoff of the retransmission timeout for
each retransmission or repetition after the first one.
NOTE - One possibility is to use the algorithm implemented in
TCP-IP, which uses two variables:
- The average acknowledgement delay (AAD), estimated through an
exponentially smoothed average of the observed delays.
- The average deviation (ADEV), estimated through an exponentially
smoothed average of the absolute value of the difference between
the observed delay and the current average. The retransmission
timer, in TCP, is set to the sum of the average delay plus N times
the average deviation. The maximum value of the timer should
however be bounded for the protocol defined in this
RFC, in order to guarantee that no repeated packet
would be received by the gateways after LONG-TIMER seconds. A
suggested maximum value is 4 seconds.
After any retransmission, the entity SHOULD do the following:
- It should double the estimated value of the average delay, AAD.
- It should compute a random value, uniformly distributed between
0.5 AAD and AAD.
- It should set the retransmission timer to the sum of that random
value and N times the average deviation.
This procedure has two effects. Because it includes an exponentially
increasing component, it will automatically slow down the stream of
messages in case of congestion. Because it includes a random
component, it will break the potential synchronization between
notifications triggered by the same external event.
D.1.4 Provisional responses
Executing some transactions may require a long time. Long execution
times may interact with the timer-based retransmission procedure.
This may result either in an inordinate number of retransmissions, or
in timer values that become too long to be efficient. Entities that
can predict that a transaction will require a long execution time may
send a provisional response, "Transaction Pending". They SHOULD send
this response if they receive a repetition of a transaction that is
still being executed.
Entities that receive a Transaction Pending shall switch to a
different repetition timer for repeating requests. The root
Termination has a property (ProvisionalResponseTimerValue), which can
be set to the requested maximum number of milliseconds between
receipt of a command and transmission of the TransactionPending
response. Upon receipt of a final response following receipt of
provisional responses, an immediate confirmation shall be sent, and
normal repetition timers shall be used thereafter. An entity that
sends a provisional response, SHALL include the immAckRequired field
in the ensuing final response, indicating that an immediate
confirmation is expected. Receipt of a Transaction Pending after
receipt of a reply shall be ignored.
D.1.5 Repeating Requests, Responses and Acknowledgements
The protocol is organized as a set of transactions, each of which is
composed of a request and a response, commonly referred to as an
acknowledgement. The protocol messages, being carried over UDP, may
be subject to losses. In the absence of a timely response,
transactions are repeated. Entities are expected to keep in memory a
list of the responses that they sent to recent transactions, i.e., a
list of all the responses they sent over the last LONG-TIMER seconds,
and a list of the transactions that are currently being executed.
The repetition mechanism is used to guard against three types of
possible errors:
- transmission errors, when for example a packet is lost due to
noise on a line or congestion in a queue;
- component failure, when for example an interface to a entity
becomes unavailable;
- entity failure, when for example an entire entity becomes
unavailable.
The entities should be able to derive from the past history an
estimate of the packet loss rate due to transmission errors. In a
properly configured system, this loss rate should be kept very low,
typically less than 1%. If a Media Gateway Controller or a Media
Gateway has to repeat a message more than a few times, it is very
legitimate to assume that something else than a transmission error is
occurring. For example, given a loss rate of 1%, the probability
that five consecutive transmission attempts fail is 1 in 100 billion,
an event that should occur less than once every 10 days for a Media
Gateway Controller that processes 1000 transactions per second.
(Indeed, the number of repetition that is considered excessive should
be a function of the prevailing packet loss rate.) We should note
that the "suspicion threshold", which we will call "Max1", is
normally lower than the "disconnection threshold", which should be
set to a larger value.
A classic retransmission algorithm would simply count the number of
successive repetitions, and conclude that the association is broken
after retransmitting the packet an excessive number of times
(typically between 7 and 11 times.) In order to account for the
possibility of an undetected or in progress "failover", we modify
the classic algorithm so that if the Media Gateway receives a valid
ServiceChange message announcing a failover, it will start
transmitting outstanding commands to that new MGC. Responses to
commands are still transmitted to the source address of the command.
In order to automatically adapt to network load, this RFCspecifies
exponentially increasing timers. If the initial timer is set to 200
milliseconds, the loss of a fifth retransmission will be detected
after about 6 seconds. This is probably an acceptable waiting delay
to detect a failover. The repetitions should continue after that
delay not only in order to perhaps overcome a transient connectivity
problem, but also in order to allow some more time for the execution
of a failover (waiting a total delay of 30 seconds is probably
acceptable).
It is, however, important that the maximum delay of retransmissions
be bounded. Prior to any retransmission, it is checked that the time
elapsed since the sending of the initial datagram is no greater than
T-MAX. If more than T-MAX time has elapsed, the MG concludes that
the MGC has failed, and it begins its recovery process as described
in section 11.5. If the MG retries to connect to the current MGC it
shall use a ServiceChange with ServiceChangeMethod set to
Disconnected so that the new MGC will be aware that the MG lost one
or more transactions. The value T-MAX is related to the LONG-TIMER
value: the LONG-TIMER value is obtained by adding to T MAX the
maximum propagation delay in the network.
D.2 Using TCP
Protocol messages as defined in this RFCmay be transmitted over TCP.
When no port is specified by the other side (see 7.2.8), the commands
should be sent to the default port. The defined protocol has
messages as the unit of transfer, while TCP is a stream-oriented
protocol. TPKT, according to RFC1006, SHALL be used to delineate
messages within the TCP stream.
In a transaction-oriented protocol, there are still ways for
transaction requests or responses to be lost. As such, it is
recommended that entities using TCP transport implement application
level timers for each request and each response, similar to those
specified for application level framing over UDP.
D.2.1 Providing the At-Most-Once functionality
Messages, being carried over TCP, are not subject to transport
losses, but loss of a transaction request or its reply may
nonetheless be noted in real implementations. In the absence of a
timely response, commands are repeated. Most commands are not
idempotent. The state of the MG would become unpredictable if, for
example, Add commands were executed several times.
To guard against such losses, it is recommended that entities follow
the procedures in D.1.1.
D.2.2 Transaction identifiers and three-way handshake
For the same reasons, it is possible that transaction replies may be
lost even with a reliable delivery protocol such as TCP. It is
recommended that entities follow the procedures in D.1.2.2.
D.2.3 Computing retransmission timers
With reliable delivery, the incidence of loss of a transaction
request or reply is expected to be very low. Therefore, only simple
timer mechanisms are required. Exponential back-off algorithms
should not be necessary, although they could be employed where, as in
an MGC, the code to do so is already required, since MGCs must
implement ALF/UDP as well as TCP.
D.2.4 Provisional responses
As with UDP, executing some transactions may require a long time.
Entities that can predict that a transaction will require a long
execution time may send a provisional response, "Transaction
Pending". They should send this response if they receive a
repetition of a transaction that is still being executed.
Entities that receive a Transaction Pending shall switch to a longer
repetition timer for that transaction.
Entities shall retain Transactions and replies until they are
confirmed. The basic procedure of D.1.4 should be followed, but
simple timer values should be sufficient. There is no need to send
an immediate confirmation upon receipt of a final response.
D.2.5 Ordering of commands
TCP provides ordered delivery of transactions. No special procedures
are required. It should be noted that ALF/UDP allows sending entity
to modify its behaviour under congestion, and in particular, could
reorder transactions when congestion is encountered. TCP could not
achieve the same results.
ANNEX E - Basic packages
This annex contains definitions of some packages for use with
Recommendation H.248.1.
E.1 Generic
PackageID: g (0x0001)
Version: 1
Extends: None
Description:
Generic package for commonly encountered items.
E.1.1 Properties
None.
E.1.2 Events
Cause
EventID: cause (0x0001)
Generic error event
EventsDescriptor parameters: None
ObservedEvents Descriptor Parameters:
General Cause
ParameterID: Generalcause (0x0001)
This parameter groups the failures into six groups, which
the MGC may act upon.
Type: enumeration
Possible values:
"NR" Normal Release (0x0001)
"UR" Unavailable Resources (0x0002)
"FT" Failure, Temporary (0x0003)
"FP" Failure, Permanent (0x0004)
"IW" Interworking Error (0x0005)
"UN" Unsupported (0x0006)
Failure Cause
ParameterID: Failurecause (0x0002)
Possible values: OCTET STRING
Description: The Failure Cause is the value generated by the
Released equipment, i.e., a released network connection.
The concerned value is defined in the appropriate bearer
control protocol.
Signal Completion
EventID: sc (0x0002)
Indicates the termination of a signal for which the
notifyCompletion parameter was set to enable reporting of a
completion event. For further procedural description, see 7.1.1,
7.1.17 and 7.2.7.
EventsDescriptor parameters: None
ObservedEvents Descriptor parameters:
Signal Identity
ParameterID: SigID (0x0001)
This parameter identifies the signal which has terminated.
For a signal that is contained in a signal list, the signal
list identity parameter should also be returned indicating
the appropriate list.
Type: Binary: octet (string), Text: string
Possible values: a signal which has terminated. A signal
shall be identified using the pkgdName syntax without
wildcarding.
Termination Method
ParameterID: Meth (0x0002)
Indicates the means by which the signal terminated.
Type: enumeration
Possible values:
"TO" (0x0001) Signal timed out or otherwise completed on
its own
"EV" (0x0002) Interrupted by event
"SD" (0x0003) Halted by new Signals descriptor
"NC" (0x0004) Not completed, other cause
Signal List ID
ParameterID: SLID (0x0003)
Indicates to which signal list a signal belongs. The
SignalList ID is only returned in cases where the signal
resides in a signal list.
Type: integer
Possible values: any integer
E.1.3 Signals
None.
E.1.4 Statistics
None.
E.2 Base Root Package
PackageID: root (0x0002)
Version: 1
Extends: None
Description:
This package defines Gateway wide properties.
E.2.1 Properties
MaxNrOfContexts
PropertyID: maxNumberOfContexts (0x0001)
The value of this property gives the maximum number of contexts
that can exist at any time. The NULL context is not included in
this number.
Type: double
Possible values: 1 and up
Defined in: TerminationState
Characteristics: read only
MaxTerminationsPerContext
PropertyID: maxTerminationsPerContext (0x0002)
The maximum number of allowed terminations in a context, see 6.1
Type: integer
Possible values: any integer
Defined in: TerminationState
Characteristics: read only
normalMGExecutionTime
PropertyId: normalMGExecutionTime (0x0003)
Settable by the MGC to indicate the interval within which the MGC
expects a response to any transaction from the MG (exclusive of
network delay)
Type: integer
Possible values: any integer, represents milliseconds
Defined in: TerminationState
Characteristics: read / write
normalMGCExecutionTime
PropertyId: normalMGCExecutionTime (0x0004)
Settable by the MGC to indicate the interval within which the MG
should expects a response to any transaction from the MGC
(exclusive of network delay)
Type: integer
Possible values: any integer, represents milliseconds
Defined in: TerminationState
Characteristics: read / write
MGProvisionalResponseTimerValue
PropertyId: MGProvisionalResponseTimerValue (0x0005)
Indicates the time within which the MGC should expect a Pending
Response from the MG if a Transaction cannot be completed.
Initially set to normalMGExecutionTime plus network delay, but may
be lowered.
Type: Integer
Possible Values: any integer, represents milliseconds
Defined in: TerminationState
Characteristics: read / write
MGCProvisionalResponseTimerValue
PropertyId: MGCProvisionalResponseTimerValue (0x0006)
Indicates the time within which the MG should expect a Pending
Response from the MGC if a Transaction cannot be completed.
Initially set to normalMGCExecutionTime plus network delay, but
may be lowered.
Type: Integer
Possible Values: any integer, represents milliseconds
Defined in: TerminationState
Characteristics: read / write
E.2.2 Events
None.
E.2.3 Signals
None.
E.2.4 Statistics
None.
E.2.5 Procedures
None.
E.3 Tone Generator Package
PackageID: tonegen (0x0003)
Version: 1
Extends: None
Description:
This package defines signals to generate audio tones. This
package does not specify parameter values. It is intended to be
extendable. Generally, tones are defined as an individual signal
with a parameter, ind, representing "interdigit" time delay, and a
tone id to be used with playtones. A tone id should be kept
consistent with any tone generation for the same tone. MGs are
expected to be provisioned with the characteristics of appropriate
tones for the country in which the MG is located.
Designed to be extended only.
E.3.1 Properties
None.
E.3.2 Events
None.
E.3.3 Signals
Play tone
SignalID: pt (0x0001)
Plays audio tone over an audio channel
Signal Type: Brief
Duration: Provisioned
Additional parameters:
Tone id list
ParameterID: tl (0x0001)
Type: list of tone ids
List of tones to be played in sequence. The list SHALL
contain one or more tone ids.
Inter signal duration
ParameterID: ind (0x0002)
Type: integer
Timeout between two consecutive tones in milliseconds
No tone ids are specified in this package. Packages that extend this
package can add possible values for tone id as well as adding
individual tone signals.
E.3.4 Statistics
None.
E.3.5 Procedures
None.
E.4 Tone Detection Package
PackageID: tonedet (0x0004)
Version: 1
Extends: None
This Package defines events for audio tone detection. Tones are
selected by name (tone id). MGs are expected to be provisioned with
the characteristics of appropriate tones for the country in which the
MG is located.
Designed to be extended only:
This package does not specify parameter values. It is intended to
be extendable.
E.4.1 Properties
None.
E.4.2 Events
Start tone detected
EventID: std, 0x0001
Detects the start of a tone. The characteristics of positive tone
detection are implementation dependent.
EventsDescriptor parameters:
Tone id list
ParameterID: tl (0x0001)
Type: list of tone ids
Possible values: The only tone id defined in this package is
"wild card" which is "*" in text encoding and 0x0000 in
binary. Extensions to this package would add possible
values for tone id. If tl is "wild card", any tone id is
detected.
ObservedEventsDescriptor parameters:
Tone id
ParameterID: tid (0x0003)
Type: enumeration
Possible values: "wildcard" as defined above is the only
value defined in this package. Extensions to this package
would add additional possible values for tone id.
End tone detected
EventID: etd, 0x0002
Detects the end of a tone.
EventDescriptor parameters:
Tone id list
ParameterID: tl (0x0001)
Type: enumeration or list of enumerated types
Possible values: No possible values are specified in this
package. Extensions to this package would add possible
values for tone id.
ObservedEventsDescriptor parameters:
Tone id
ParameterID: tid (0x0003)
Type: enumeration
Possible values: "wildcard" as defined above is the only
value defined in this package. Extensions to this
package would add possible values for tone id.
Duration
ParameterId: dur (0x0002)
Type: integer, in milliseconds
This parameter contains the duration of the tone from
first detection until it stopped.
Long tone detected
EventID: ltd, 0x0003
Detects that a tone has been playing for at least a certain amount
of time.
EventDescriptor parameters:
Tone id list
ParameterID: tl (0x0001)
Type: enumeration or list
Possible values: "wildcard" as defined above is the only
value defined in this package. Extensions to this package
would add possible values for tone id.
Duration
ParameterID: dur (0x0002)
Type: integer, duration to test against
Possible values: any legal integer, expressed in
milliseconds
ObservedEventsDescriptor parameters:
Tone id
ParameterID: tid (0x0003)
Type: Enumeration
Possible values: No possible values are specified in this
package. Extensions to this package would add possible
values for tone id.
E.4.3 Signals
None.
E.4.4 Statistics
None.
E.4.5 Procedures
None.
E.5 Basic DTMF Generator Package
PackageID: dg (0x0005)
Version: 1
Extends: tonegen version 1
This package defines the basic DTMF tones as signals and extends the
allowed values of parameter tl of playtone in tonegen.
E.5.1 Properties
None.
E.5.2 Events
None.
E.5.3 Signals
DTMF character 0
SignalID: d0 (0x0010)
Generate DTMF 0 tone. The physical characteristic of DTMF 0 is
defined in the gateway.
Signal Type: Brief
Duration: Provisioned
Additional parameters:
None.
Additional values:
d0 (0x0010) is defined as a tone id for playtone
The other DTMF characters are specified in exactly the same way. A
table with all signal names and signal IDs is included. Note that
each DTMF character is defined as both a signal and a tone id, thus
extending the basic tone generation package. Also note that DTMF
SignalIds are different from the names used in a digit map.
Signal name Signal ID/Tone id
DTMF character 0 d0 (0x0010)
DTMF character 1 d1 (0x0011)
DTMF character 2 d2 (0x0012)
DTMF character 3 d3 (0x0013)
DTMF character 4 d4 (0x0014)
DTMF character 5 d5 (0x0015)
DTMF character 6 d6 (0x0016)
DTMF character 7 d7 (0x0017)
DTMF character 8 d8 (0x0018)
DTMF character 9 d9 (0x0019)
DTMF character * ds (0x0020)
DTMF character # do (0x0021)
DTMF character A da (0x001a)
DTMF character B db (0x001b)
DTMF character C dc (0x001c)
DTMF character D dd (0x001d)
E.5.4 Statistics
None.
E.5.5 Procedures
None.
E.6 DTMF detection Package
PackageID: dd (0x0006)
Version: 1
Extends: tonedet version 1
This package defines the basic DTMF tones detection. This Package
extends the possible values of tone id in the "start tone detected"
"end tone detected" and "long tone detected" events.
Additional tone id values are all tone ids described in package dg
(basic DTMF generator package).
The following table maps DTMF events to digit map symbols as
described in 7.1.14.
DTMF Event Symbol
d0 "0"
d1 "1"
d2 "2"
d3 "3"
d4 "4"
d5 "5"
d6 "6"
d7 "7"
d8 "8"
d9 "9"
da "A" or "a"
db "B" or "b"
dc "C" or "c"
dd "D" or "d"
ds "E" or "e"
do "F" or "f"
E.6.1 Properties
None.
E.6.2 Events
DTMF digits
EventIds are defined with the same names as the SignalIds defined
in the table found in E.5.3.
DigitMap Completion Event
EventID: ce, 0x0004
Generated when a digit map completes as described in 7.1.14.
EventsDescriptor parameters: None.
ObservedEventsDescriptor parameters:
DigitString
ParameterID: ds (0x0001)
Type: string of digit map symbols (possibly empty) returned
as a quotedString
Possible values: a sequence of the characters "0" through
"9", "A" through "F", and the long duration modifier "Z".
Description: the portion of the current dial string as
described in 7.1.14 which matched part or all of an
alternative event sequence specified in the digit map.
Termination Method
ParameterID: Meth (0x0003)
Type: enumeration
Possible values:
"UM" (0x0001) Unambiguous match
"PM" (0x0002) Partial match, completion by timer expiry
or unmatched event
"FM" (0x0003) Full match, completion by timer expiry or
unmatched event
Description: indicates the reason for generation of the
event. See the procedures in 7.1.14.
E.6.3 Signals
None.
E.6.4 Statistics
None.
E.6.5 Procedures
Digit map processing is activated only if an events descriptor is
activated that contains a digit map completion event as defined in