S tandard ECMA-336
June 2002
International
Standardizing Information
and
Communication
Systems
Private Integrated Services Network (PISN) Mapping Functions for the Tunnelling of QSIG through IP Networks
Phone: +41 22 849.60.00
-
Fax: +41 22 849.60.01
-
URL: http://www.ecma.ch
-
Internet: [email protected]
.
S tandard ECMA-336
June 2002
International
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Mapping Functions for the Tunnelling of QSIG through IP Networks (Mapping/IP-QSIG)
Phone: +41 22 849.60.00 IW
Ecma-336.doc
01-07-02 16,29
-
Fax: +41 22 849.60.01
-
URL: http://www.ecma.ch
-
Internet: [email protected]
.
Brief History
This Standard is one of a series of ECMA standards defining mapping functions in exchanges of Private Integrated Services Networks required for the utilization of intervening network scenarios. The series uses the ISDN concepts as developed by ITU-T (formerly CCITT) and is also within the framework of standards for open systems interconnection as defined by ISO/IEC. It has been produced under ETSI work item DTS/ECMA-00234. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus.
This Standard has been adopted by the ECMA General Assembly of June 2002.
.
- i -
Table of contents
1
Scope
1
2
Conformance
1
3
References
1
4
Definitions 4 . 1 E x te r n a l d e f in itio n s 4 . 2 O th e r d e f in itio n s 4.2.1 Calling PINX 4.2.2 Called PINX 4.2.3 Ch a n n e l 4.2.4 Re s o u r c e Co n tr o l I n f o r ma tio n 4.2.5 Inter-PINX Connection (IPC) 4.2.6 QPKT
2 2 2 2 2 2 2 2 2
5
List of acronyms
2
6
Introduction Re f e r e n c e c o n f ig u r a tio n Specific scenarios
3 3 3
7
Capabilities at the Q reference point
4
8 8.1 8.2
Capabilities at the C reference point T CP c o n n e c tio n U D P s t r e a ms
4 4 5
9.1 9.2
Mapping functions Ma p p in g th e D Q - c h a n n e l Ma p p in g a U Q - c h a n n e l
5 5 5
6.1 6.2
9
10 IPC control functions 10.1 P r o c e d u r e f o r U Q - c h a n n e l e s t a b l i s h me n t 10.2 P r o c e d u r e f o r U Q - c h a n n e l c le a r in g
5 6 6
Annex A - Implementation Conformance Statement (ICS) Proforma
7
Annex B - Message syntax for Resource Control Information
13
1
Scope This Standard specifies functions for using a packet network that uses the Internet Protocol (IP) as its network layer protocol and UDP and TCP as its transport layer protocols, to interconnect two Private Integrated services Network eXchanges (PINXs) forming part of a Private Integrated Services Network (PISN). Interconnection is achieved by carrying the inter-PINX signalling protocol directly over the Transmission Control Protocol (TCP) and inter-PINX user information (e.g., voice) over the Real-time Transport Protocol (RTP), RTP being carried over the User Datagram Protocol (UDP). The inter-PINX signalling protocol is assumed to be QSIG, as specified in ECMA-143, ECMA-165 and other standards. The Standard provides for two types of interconnection: -
on-demand, where a separate TCP connection for QSIG is established at the start of each call and cleared down at the end of that call; and
-
semi-permanent, where a single TCP connection with an indefinite lifetime carries QSIG on behalf of many single calls.
This Standard is applicable to PINXs that can be interconnected to form a PISN using QSIG as the inter-PINX signalling protocol.
2
Conformance In order to conform to this Standard, a PINX shall satisfy the requirements identified in the Implementation Conformance Statement (ICS) proforma in annex A.
3
References The following standards contain provisions which, through reference in this text, constitute provision of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. ECMA-133
Private Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)
ECMA-142
Private Integrated Services Network (PISN) - Circuit Mode 64kbit/s Bearer Services - Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)
ECMA-143
Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - InterExchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)
ECMA-165
Private Integrated Services Network (PISN) - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11582)
ITU-T Rec. I.112
Vocabulary of terms for ISDNs (1993)
ITU-T Rec. I.210
Principles of telecommunication services supported by an ISDN and the means to describe them (1993)
IETF RFC 760
Internet Protocol
IETF RFC 761
Transmission Control Protocol
IETF RFC 768
User Datagram Protocol
IETF RFC 1889
RTP: a transport protocol for real-time applications
IETF RFC 2126
ISO Transport Service on top of the TCP (ITOT)
- 2 -
4
Definitions For the purposes of this Standard the following definitions apply.
4.1
External definitions This Standard uses the following terms defined in other documents:
4.2
5
-
IVN
(ECMA-133)
-
PINX
(ECMA-133)
-
PISN
(ECMA-133)
-
Service
(ITU-T Rec. I.112)
-
Signalling
(ITU-T Rec. I.112)
Other definitions
4.2.1
Calling PINX In the context of a call or call-independent signalling connection across an IPL, the PINX that transmits the QSIG SETUP message.
4.2.2
C a lle d P I N X In the context of a call or call-independent signalling connection across an IPL, the PINX that receives the QSIG SETUP message.
4.2.3
Channel A means of bi-directional transmission of user or signalling information between two points.
4.2.3.1
DQ-Channel A channel used to convey call control information between the Q reference points of two peer PINXs.
4.2.3.2
UQ-Channel A channel used to convey user information between the Q reference points of two peer PINXs.
4.2.4
Resource Control Information Information exchanged between peer PINXs for the purpose of establishing UDP streams
4.2.5
I n t e r - P I N X C o n n e c t io n ( I P C ) A connection provided by an IVN between two C reference points used to transport inter-PINX information from the PISN control plane and/or the PISN user plane.
4.2.6
QPKT A packet format defined within this Standard for conveying QSIG message and RCI (Resource Control Information).
List of acronyms IP
Internet Protocol
IPC
Inter-PINX connection
IPL
Inter-PINX Link
IVN
InterVening Network
PINX
Private Integrated services Network eXchange
PISN
Private Integrated Services Network
QSIG
Signalling information flows at the Q reference point
RCI
Resource Control Information
RTCP
Realtime Transport Control Protocol
RTP
Realtime Transport Protocol
- 3 -
6 6.1
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
Introduction Reference configuration ECMA-133 defines a reference configuration for a PINX. Logically the switching and call control functions of a PINX communicate over an instance of the Q reference point with a peer PINX. This communication is known as an Inter-PINX Link (IPL) and comprises a signalling channel, known as a DQ channel, and one or more user information channels, each known as a UQ -channel; see figure 1. One or more IPLs can be established between the same pair of PINXs. PINX
Switching and Call Control functions
Q reference point
PINX
Q reference point
DQ-channel UQ-channel
Switching and Call Control functions
U Q-channel
Inter-PINX link
Figure 1 – IPL concept There are many ways of implementing an IPL. In general, the IPL uses services of another network, known as an Intervening Network (IVN). A PINX interfaces to the IVN at the C reference point. The IVN provides connections, known as Inter-PINX Connections (IPCs) between the C reference points of the peer PINXs. Mapping functions within each PINX map the DQ -channel and the U Q -channels at the Q reference point onto one or more IPCs at the C reference point.
6.2
Specific scenarios This Standard specifies mapping functions for use when the IVN is an IP-based network that is used to provide the following types of IPC: -
a TCP connection for carrying signalling information and Resource Control Information; and
-
a pair of UDP streams, one stream in each direction, for carrying user information over RTP.
A single IPL requires a single TCP connection, for support of the DQ -channel, and one pair of UDP streams per U Q -channel. In addition to carrying the QSIG protocol, the TCP connection is also required to carry resource control information for establishing the UDP streams. This Standard supports two types of interconnection between peer PINXs: -
On-demand, where a single TCP connection for QSIG and a pair of UDP streams for user information are established at the start of each call and cleared down at the end of that call;
-
Semi-permanent, where a single TCP connection with an indefinite lifetime carries QSIG on behalf of many calls.
In the semi-permanent case, the TCP connection can support zero, one or more than one call at the same time. A pair of UDP streams for user information is established at the start of each call and cleared down at the end of that call. Figure 2 illustrates these concepts.
- 4 -
PINX
Q reference point
Switching and Call Control functions
C reference point
DQ-channel
IVN (IP network)
Mapping functions
C reference point
TCP connection
Mapping functions
Q reference point DQ-channel
UQ-channel
Pair of UDP streams
UQ-channel
UQ-channel
Pair of UDP streams
UQ-channel
PINX Switching and Call Control functions
Inter-PINX connections Inter-PINX link
Figure 2 – IPC concept (Semi-permanent)
7
Capabilities at the Q reference point For each instance of the Q reference point: – one signalling channel (DQ ) for carrying the inter-PINX Layer 3 signalling protocol, and – zero, one or more user channels (U Q ) shall be provided. NOTE In the special case of an on-demand interconnection used only for a call independent signalling connection, no U Q -channels are provided. For a U Q -channel the following bearer capability shall be provided: – transfer mode: circuit mode; – information transfer rate: 64 kbit/s; – information transfer capability: speech or 3,1 kHz audio; – user information layer 1 protocol: G.711 A or µ law. Other bearer capabilities are outside the scope of this Standard. For a D Q -channel the following bearer capability shall be provided: – transfer mode: packet mode; – information transfer rate: implementation-dependent; – information transfer capability: unrestricted digital information. The functions to map D Q - and U Q -channels to an inter-PINX connection (IPC) at the C reference point are described in clause 9.
8
Capabilities at the C reference point The PINX mapping functions shall meet the following requirements.
8.1
TCP connection A PINX shall support a packet network interface suitable for communication according to IETF RFC 761. The protocol stack used in this Standard is described as figure 3 below. QSIG
RCI QPKT TPKT TCP IP F ig u r e 3 – P r o t o c o l s t a c k f o r M a p p in g /I P - Q S I G
- 5 -
The RCI provides information required to establish the media path(s). A TPKT is a packet format as defined in IETF RFC 2126. It is used to delimit individual messages (PDUs) within the TCP stream, which itself provides a continuous stream of octets without explicit boundaries. A TPKT consists of a one octet version number field, followed by a one octet reserved field, followed by a two octet length field, followed by the actual data. The version number field shall contain the value “3”, the reserved field shall contain the value “0”. The length field shall contain the length of the entire packet including the version number, the reserved and the length fields as a 16-bit big-endian word. A QPKT is a packet format as defined in figure 4 below. A QPKT consists of a two octet length field, followed by a single QSIG message, followed by RCI. The first octet of the QSIG message shall be the octet immediately following the QPKT length field, the last octet shall be the octet immediately preceding the RCI. The length field indicates the length of the QSIG message and therefore indicates the start of the RCI. len.
QSIG message
RCI
Figure 4 – QPKT structure of Mapping/IP-QSIG NOTE In most circumstances, the RCI field is omitted. The D Q -channel shall be mapped to the well-known TCP port (4029) or to a dynamically assigned port. RCI shall be in accordance with annex B.
8.2
UDP streams The U Q -channel shall be mapped to a received UDP stream and a transmitted UDP stream, each carrying RTP packets. The received UDP stream shall be received at a local IP address and port as indicated in transmitted RCI and the transmitted UDP stream shall be transmitted to a remote IP address and port as indicated in received RCI. NOTE If required, PINXs can use RTCP as defined in IETF RFC 1889 to monitor the quality of RTP carried over UDP streams.
9 9.1
Mapping functions Mapping the D Q -channel For transmission, a complete QSIG message and RCI shall be embedded in a QPKT packet within a TPKT packet as defined in clause 8.1. The segmentation and reassembly procedures of ECMA-143 shall not be used. The RCI implicitly refers to the call to which the QSIG message relates. It shall be included in the first forward and first backward message of each call, and shall not be included in subsequent messages. In addition, RCI shall not be included with call-independent messages.
9.2
Mapping a U Q -channel Each U Q -channel shall be mapped to a pair of unidirectional UDP streams with suitable transport capabilities defined by the RCI. The mapping function is responsible for proper packetization, depacketization, transcoding etc. of media data.
10
IPC control functions To establish the IPC for the D Q -channel, the PINX initiating the TCP connection needs to know the IP address of the other PINX. The means for determining the IP address is outside the scope of this Standard. For the on-demand scenario, the calling PINX shall establish a TCP connection for the DQ -channel following the procedure specified in IETF RFC 761 whenever a call or call-independent signalling connection is to be established and shall clear down the TCP connection when the call or call-independent signalling connection has been cleared.
- 6 -
For the semi-permanent scenario, when a call or call independent signalling connection is to be established, if a D Q -channel (TCP connection) exists between the peer-PINXs, the calling PINX shall use that D Q -channel. If no D Q -channel exists between the peer PINXs, the calling PINX shall establish a TCP connection for the DQ channel following the procedure specified in IETF RFC 761. It is an implementation matter when to clear the TCP connection, except that it shall not to be cleared while still being used for a call or call independent signalling connection. For either scenario, UQ -channel establishment and clear down shall be in accordance with 10.1 and 10.2 respectively.
10.1
Procedure for U Q -channel establishment U Q -channel establishment shall occur whenever a call is established. In order to establish the UQ -channel, the calling PINX and the called PINX shall each transmit RCI in accordance with annex B. The calling PINX shall transmit RCI in the same QPKT packet as the QSIG SETUP message. The called PINX shall check that the received RCI information is acceptable and if so transmit RCI in the same QPKT packet as the QSIG SETUP ACKNOWLEDGE message or the QSIG CALL PROCEEDING message, whichever is transmitted first. NOTE 1 ECMA-143 requires the Channel identification information element to be present in the QSIG SETUP message and in the QSIG SETUP ACKNOWLEDGE message or CALL PROCEEDING message, whichever is transmitted first. The contents of the Channel identification information element can be ignored on receipt. NOTE 2 If the first response to the SETUP message is neither SETUP ACKNOWLEDGE nor CALL PROCEEDING (e.g., RELEASE COMPLETE), no RCI is returned. After transmitting RCI, the calling PINX shall be prepared to receive RTP packets on the IP address and port as specified in the transmitted RCI. The called PINX shall include in the transmitted RCI the same codec type and payload period as specified in the received RCI. After transmitting the RCI, the called PINX shall begin transmitting RTP packets to the IP address and port as specified in the received RCI in accordance with the codec type and payload period as specified in the received RCI as soon as media becomes available. The called PINX shall also be prepared to receive RTP packets on the IP address and port as specified in the transmitted RCI. After having received RCI in the first response message and after having received the CONNECT message, the calling PINX shall begin transmitting RTP packets to the IP address and port in the received RCI in accordance with the codec type and payload period in the received RCI. During the establishment of the U Q -channel, if either the calling PINX or the called PINX receives unacceptable content in the RCI, that PINX shall behave as specified in ECMA-143 for the case where the content of the Channel identification information element is unacceptable.
10.2
Procedure for U Q -channel clearing Before transmitting a QSIG call clearing message (DISCONNECT, RELEASE or RELEASE COMPLETE), a PINX shall stop transmitting RTP packets and shall ignore the contents of any further received RTP packets. After transmitting or receiving a QSIG RELEASE COMPLETE message, the PINX should release the resources associated with the UQ -channel.
- 7 -
Annex A ( n o r ma tiv e )
Implementation Conformance Statement (ICS) Proforma
A.1
Introduction The supplier of a implementation which is claimed to conform to this Standard shall complete the following Implementation Conformance Statement (ICS) proforma. A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities and options of the have been implemented. The ICS can have a number of uses, including use:
A.2
-
by the implementor, as a check-list to reduce the risk of failure to conform to the standard through oversight;
-
by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the standard's ICS proforma;
-
by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible ICSs.
Instructions for completing the ICS proforma
A.2.1
General structure of the ICS proforma The ICS proforma is a fixed-format questionnaire divided into sub-clauses each containing a group of individual items. Each item is identified by an item number, the name of the item (question to be answered), and the reference(s) to the clause(s) that specifies (specify) the item in the main body of this Standard. The “Status” column indicates whether an item is applicable and if so whether support is mandatory or optional. The following terms are used: m
mandatory (the capability is required for conformance to the standard);
o
optional (the capability is not required for conformance to the , but if the capability is implemented it is required to conform to the specifications);
o.<n>
optional, but support of at least one of the group of options labelled by the same numeral <n> is required;
x
prohibited;
<c.cond>
conditional requirement, depending on support for the item or items listed in condition <cond>;
<item>:m
simple conditional requirement, the capability being mandatory if item number <item> is supported, otherwise not applicable;
<item>:o
simple conditional requirement, the capability being optional if item number <item> is supported, otherwise not applicable.
Answers to the questionnaire items are to be provided either in the “Support” column, by simply marking an answer to indicate a restricted choice (Yes or No), or in the “Not Applicable” column (N/A).
- 8 -
A.2.2
Additional information Items of additional information allow a supplier to provide further information intended to assist the interpretation of the ICS. It is not intended or expected that a large quantity will be supplied, and a ICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of additional information may be entered next to any answer in the questionnaire, and may be included in items of exception information.
A.2.3
Exception information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No preprinted answer will be found in the Support column for this. Instead, the supplier is required to write into the Support column an x.<i> reference to an item of exception information, and to provide the appropriate rationale in the exception item itself. An implementation for which an exception item is required in this way does not conform to this Standard. A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.
- 9 -
A.3
ICS proforma for ECMA-336
A.3.1
Implementation identification
Supplier Contact point for queries about the ICS Implementation name(s) and version(s) Other information necessary for full identification, e.g., name(s) and version(s) for machines and/or operating systems; system name(s)
Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. The terms name and version should be interpreted appropriately to correspond with a suppliers terminology (e.g. type, series, model).
A.3.2
Implementation summary
Implementation version
1.0
Addenda implemented (if applicable) Amendments implemented Have any exception items been required (see A.2.3)?
Date of Statement
No [ ] Yes [ ] (The answer Yes means that the implementation does not conform to this Standard)
- 10 -
A.4
A.5
A.6
A.7
General requirements Item
Question/feature
References
Status
N/A
Support
A1
Support of on-demand IPC
m
Yes [ ]
A2
Support of semi-permanent IPC
o
Yes [ ] No [ ]
U Q -channel bearer capabilities at the Q reference point Item
Question/feature
References
Status
B1
N/A
Support
Support transfer mode as “circuit mode”
7
m
Yes [ ]
B2
Support 64kbit/s information transfer rate
7
m
Yes [ ]
B3
Support “speech” for information transfer capability
7
o.1
Yes [ ] No [ ]
B4
Support “3.1kHz audio” for information transfer capability
7
o.1
Yes [ ] No [ ]
B5
Support “G.711A-law” for user information layer 1 protocol
7
o.2
Yes [ ] No [ ]
B6
Support “G.711 µ-law” for user information layer 1 protocol
7
o.2
Yes [ ] No [ ]
B7
Support other user information layer 1 protocol (specify:
7
o
Yes [ ] No [ ]
)
D Q -channel capability at the Q reference point Item
Question/feature
References
Status
C1 C2
N/A
Support
Support of “packet mode” as transfer mode
7
m
Yes [ ]
Support of “unrestricted digital information” for information transfer capability
7
m
Yes [ ]
References
Status
Capabilities at the C reference point Item
Question/feature
N/A
Support
D1
Support of QPKT packet structure
8.1
m
Yes [ ]
D2
Support of well-know TCP port (4029) for D Q -channel
8.1
m
Yes [ ]
D3
Support of dynamically assigned TCP port for D Q -channel
8.1
o
Yes [ ] No [ ]
D4
Support of dynamically assigned UDP port as signalled by RCI
8.2
m
Yes [ ]
- 11 -
A.8
A.9
Mapping functions Item
Question/feature
References
Status
E1 E2
N/A
Support
Support mapping of the D Q -channel
9.1
m
Yes [ ]
Support mapping of the U Q -channel
9.2
m
Yes [ ]
References
Status
IPC control functions Item
Question/feature
N/A
Support
F1
Support establishing / clearing of the D Q -channel for the on-demand scenario
10
m
F2
Support establishing / clearing of the D Q -channel for the semi-permanent scenario
10
A2:m
F3
Support establishing of the U Q -channel
10.1
m
Yes [ ]
F4
Support clearing of the U Q -channel
10.2
m
Yes [ ]
References
Status
Yes [ ] []
Yes [ ]
A.10 Support of resource control information A.10.1 Support of bearer capabilities information Item
Question/feature
G1
Support codec type “g711Alaw64k”
B.2.3.1
o.1
Yes [ ] No [ ]
G2
Support codec type “g711Ulaw64k”
B.2.3.1
o.1
Yes [ ] No [ ]
G3
Support codec type “g723.1”
B.2.3.1
o.1
Yes [ ] No [ ]
G4
Support codec type “g729”
B.2.3.1
o.1
Yes [ ] No [ ]
G5
Support codec type “g729AnnexA”
B.2.3.1
o.1
Yes [ ] No [ ]
G6
Support codec type “g729wAnnexB”
B.2.3.1
o.1
Yes [ ] No [ ]
G7
Support codec type “g729AnnexAwAnnexB”
B.2.3.1
o.1
Yes [ ] No [ ]
G8
Support payload period (specify:
B.2.3.1
m
Yes [ ]
References
Status
msec)
N/A
Support
A.10.2 Support of IP address type Item
Question/feature
N/A
Support
H1
Support of IP address type “IPv4”
B.2.3.2
m
Yes [ ]
H2
Support of IP address type “IPv6”
B.2.3.2
o
Yes [ ] No [ ]
- 12 -
- 13 -
Annex B ( n o r ma tiv e )
Message syntax for Resource Control Information
B.1
Introduction This annex defines the syntax for RCI, which is exchanged between peer PINXs for the purpose of establishing a pair of IPCs for providing a U Q -channel. A PINX shall be capable of transmitting and receiving RCI in accordance with this syntax.
B.2
Message syntax Octet group 1 2 3
B.2.1
7
6
5
4
3
2
1
Resource control header Protocol indicator Resource control information
Reference B.2.1 B.2.2 B.2.3
Resource control header Octet 1.1 1.2
B.2.2
8
8 0 x
7 1 x
6 1 x
5 1 x
4 1 x
3 1 x
2 1 x
1 0 x
Resource control discriminator Length of entire RCI
5 x x
4 x x
3 x x
2 x x
1 x x
Protocol identifier Version identifier
2 0
1 0
2 0
1 1
Version information
Protocol indicator Octet 2.1 2.2
8 x x
7 x x
6 x x
“Protocol identifier” is coded as follows: Bit
8 7 0 0 Others
6 0
5 0
4 0
3 0
ECMA-336 Reserved
“Version identifier” is coded as follows: Bit
B.2.3
8 0
7 0
6 0
5 0
4 0
3 0
Resource control information Octet group 3.1 3.2
8
7
6
5
4
3
2
1
Description
Reference
x x
x x
x x
x x
x x
x x
x x
x x
Bearer capabilities information UDP stream information
B.2.3.1 B.2.3.2
- 14 -
B.2.3.1 Bearer capabilities information Octet 8 7 6 5 4 3 2 3.1.1 0 0 0 0 0 1 0 3.1.2 x x x x x x x 3.1.3 x x x x x x x
1 0 x x
Bearer capabilities information discriminator Type of codec (any value from the list below) Payload period (unit: milliseconds.)
Type of codec is coded as follows: Bit
8 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Others
6 0 0 0 0 0 0 0 0
5 0 0 0 0 0 0 0 0
4 0 0 0 0 1 1 1 1
3 0 0 1 1 0 0 1 1
2 0 1 0 0 1 1 1 1
1 0 1 0 1 0 1 0 1
g711Alaw64k, g711Ulaw64k, g723.1 with silence compression, g723.1 without silence compression, g729, g729AnnexA, g729wAnnexB, g729AnnexAwAnnexB, Reserved
B.2.3.2 UDP stream information UDP stream information is coded as follows: Octet 3.2.1 3.2.2 3.2.3 to 3.2.3 +n-1 3.2.3 +n 3.2.3 +n+1
8 0
7 0
6 0
5 1
4 0
3 0
2 0
1 0
UDP stream information discriminator Type of IP address IP address (n octets) (Note 1)
UDP port number for RTP (Note 2, Note 3)
NOTE 1 Octet 3.2.3 contains the most significant octet of the IP address. NOTE 2 The RTCP port number should be one greater than the RTP port number. NOTE 3 Octet 3.2.3+n contains the most significant octet of the UDP port number. “Type of IP address” is coded as follows: Bit
8 7 0 0 0 0 Others
6 0 0
5 0 0
4 0 0
3 0 0
2 0 1
1 0 0
IPv4 address IPv6 address, optional Reserved
- 15 -
The length of field of “IP address” (n octets) depends on the type of IP address. For an IPv4 address this field occupies 4 octets. For an IPv6 address this field occupies 16 octets. For example, if an IPv4 address is used, octets 3.2.1 to 3.2.8 are coded as follows: Octet 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8
8 0 0 1 0 0 0 1 1
7 0 0 0 0 0 0 1 1
6 0 0 1 0 0 0 0 0
5 1 0 0 1 0 0 1 0
4 0 0 1 0 0 0 1 0
3 0 0 1 0 0 0 0 0
2 0 0 0 0 0 0 1 0
1 0 0 0 0 1 1 0 0
UDP stream information (RTP) Type of IP address IP address (172.16.1.1)
UDP port number for RTP (56000)
Free printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Email:
+41 22 849.60.01 [email protected]
Files of this Standard can be freely downloaded from the ECMA web site (www.ecma.ch). This site gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland See inside cover page for obtaining further soft or hard copies.