RFC 3525
Gateway Control Protocol Version 1
ANNEX C - Tags for media stream properties
Parameters for Local, Remote and LocalControl descriptors are specified as tag-value pairs if binary encoding is used for the protocol. This annex contains the property names (PropertyID), the tags (Property tag), type of the property (Type) and the values (Value). Values presented in the Value field when the field contains references shall be regarded as "information". The reference contains the normative values. If a value field does not contain a reference, then the values in that field can be considered as "normative". Tags are given as hexadecimal numbers in this annex. When setting the value of a property, a MGC may underspecify the value according to one of the mechanisms specified in 7.1.1. It is optional to support the properties in this Annex or any of its sub-sections. For example, only three properties from C.3 and only five properties from C.8 might be implemented. For type "enumeration" the value is represented by the value in brackets, e.g., Send(0), Receive(1). Annex C properties with the types "N bits" or "M Octets" should be treated as octet strings when encoding the protocol. Properties with "N bit integer" shall be treated as an integers. "String" shall be treated as an IA5String when encoding the protocol. When a type is smaller than one octet, the value shall be stored in the low-order bits of an octet string of size 1.C.1 General media attributes
PropertyID Property Type Value tag Media 1001 Enumeration Audio(0), Video(1), Data(2) Transmission 1002 Enumeration Send(0), Receive(1), mode Send&Receive(2) Number of 1003 Unsigned 0-255 Channels integer Sampling 1004 Unsigned 0-2^32 rate integer Bitrate 1005 Integer (0..4294967295)NOTE - Units of 100 bit/s.
ACodec 1006 Octet string Audio Codec Type:
Ref.: ITU-T Q.765
Non-ITU-T codecs are defined
with the appropriate standards
organization under a defined
Organizational Identifier.
Samplepp 1007 Unsigned Maximum samples or frames per
integer packet: 0..65535
Silencesupp 1008 Boolean Silence Suppression: True/False
Encrypttype 1009 Octet string Ref.: ITU-T H.245
Encryptkey 100A Octet string Encryption key
size Ref.: ITU-T H.235
(0..65535)
Echocanc 100B Not Used. See H.248.1 E.13 for
an example of possible Echo
Control properties.
Gain 100C Unsigned Gain in dB: 0..65535
integer
Jitterbuff 100D Unsigned Jitter buffer size in ms:
integer 0..65535
PropDelay 100E Unsigned Propagation Delay: 0..65535
integer Maximum propagation delay in
milliseconds for the bearer
connection between two media
gateways. The maximum delay
will be dependent on the bearer
technology.
RTPpayload 100F Integer Payload type in RTP Profile for
Audio and Video Conferences
with Minimal Control
Ref.: RFC 1890
C.2 Mux properties
PropertyID Property tag Type Value H222 2001 Octet string H222LogicalChannelParameters Ref.: ITU-T H.245 H223 2002 Octet string H223LogicalChannelParameters Ref.: ITU-T H.245 V76 2003 Octet string V76LogicalChannelParameters Ref.: ITU-T H.245 H2250 2004 Octet string H2250LogicalChannelParameters Ref.: ITU-T H.245C.3 General bearer properties
PropertyID Property Type Value tag Mediatx 3001 Enumeration Media Transport TypeTDM Circuit(0), ATM(1), FR(2), Ipv4(3), Ipv6(4), ... BIR 3002 4 octets Value depends on transport technology NSAP 3003 1-20 octets See NSAP. Ref.: Annex A/X.213C.4 General ATM properties
PropertyID Property Type Value tag AESA 4001 20 octets ATM End System Address VPVC 4002 4 octets: VPCI VPCI/VCI in first two least Ref.: ITU-T Q.2931 significant octets, VCI in second two octets
SC 4003 Enumeration Service Category: CBR(0),
nrt-VBR1(1), nrt VBR2(2),
nrt-VBR3(3), rt-VBR1(4),
rt VBR2(5), rt-VBR3(6),
UBR1(7), UBR2(8), ABR(9).
Ref.: ATM Forum UNI 4.0
BCOB 4004 5-bit integer Broadband Bearer Class
Ref.: ITU-T Q.2961.2
BBTC 4005 7-bit integer Broadband Transfer Capability
Ref.: ITU-T Q.2961.1
ATC 4006 Enumeration I.371 ATM Traffic
CapabilityDBR(0), SBR1(1),
SBR2(2), SBR3(3), ABT/IT(4),
ABT/DT(5), ABR(6)
Ref.: ITU-T I.371
STC 4007 2 bits Susceptibility to clipping:
Bits
2 1
---
0 0 not susceptible to
clipping
0 1 susceptible to
clipping
Ref.: ITU-T Q.2931
UPCC 4008 2 bits User Plane Connection
configuration:
Bits
2 1
---
0 0 point-to-point
0 1 point-to-multipoint
Ref.: ITU-T Q.2931
PCR0 4009 24-bit integer Peak Cell Rate (For CLP = 0)
Ref.: ITU-T Q.2931
SCR0 400A 24-bit integer Sustainable Cell Rate (For
CLP = 0)
Ref.: ITU-T Q.2961.1
MBS0 400B 24-bit integer Maximum Burst Size (For CLP =
0)
Ref.: ITU-T Q.2961.1
PCR1 400C 24-bit integer Peak Cell Rate (For CLP = 0 +
1)
Ref.: ITU-T Q.2931
SCR1 400D 24-bit integer Sustainable Cell Rate (For
CLP = 0 + 1)
Ref.: ITU-T Q.2961.1
MBS1 400E 24-bit integer Maximum Burst Size (For CLP =
0 + 1)
Ref.: ITU-T Q.2961.1
BEI 400F Boolean Best Effort Indicator
Value 1 indicates that BEI is
to be included in the ATM
signaling; value 0 indicates
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 RFC 791
IPv6 6002 128 bits IPv6 Address
Ref.: IETF RFC 2460
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 (RFC 791)
(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.: RFC 2327
SDP_O B002 String Owner/creator and session ID
Ref.: RFC 2327
SDP_S B003 String Session name
Ref.: RFC 2327
SDP_I B004 String Session identifier
Ref.: RFC 2327
SDP_U B005 String URI of descriptor
Ref.: RFC 2327
SDC_E B006 String email address
Ref.: RFC 2327
SDP_P B007 String phone number
Ref.: RFC 2327
SDP_C B008 String Connection information
Ref.: RFC 2327
SDP_B B009 String Bandwidth Information
Ref.: RFC 2327
SDP_Z B00A String Time zone adjustment
Ref.: RFC 2327
SDP_K B00B String Encryption Key
Ref.: RFC 2327
SDP_A B00C String Zero or more session attributes
Ref.: RFC 2327
SDP_T B00D String Active Session Time
Ref.: RFC 2327
SDP_R B00E String Zero or more repeat times
Reference: RFC 2327
SDP_M B00F String Media type, port, transport and format
Ref.: RFC 2327
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 RFC may 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 RFC specifies
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 RFC may 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 RFC 1006, 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.