ETSI TR 183 046 V3.3.1 (2009-08)

Technical Report
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
SDP Interworking between Call/Session Control
Protocols (SIP/SDP, RTSP/SDP; etc.)
and the Gateway Control Protocol (H.248/SDP)

2 ETSI TR 183 046 V3.3.1 (2009-08)

Reference
RTR/TISPAN-03194-NGN-R3
Keywords
H.248, interworking, SIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 183 046 V3.3.1 (2009-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
1.1 Applicability . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 9
4 Differences between SIP/SDP and H.248/SDP Usage . 10
4.1 SIP usage of SDP . 10
4.1.1 Basic O/A Model (RFC 3264 [i.4]): Initial Offer/Answer Exchange . 11
4.1.1.1 Special-Use IP addresses . 12
4.1.1.1.1 Special-Use IPv4 addresses . 12
4.1.1.1.2 Special-Use IPv6 addresses . 12
4.1.2 Basic O/A Model (RFC 3264): Subsequent Offer/Answer Exchange(s) . 12
4.1.3 Bearer Termination . 12
4.1.4 SDP redundancy between session- and media-level sections . 13
4.1.5 H.248 IP Stream/Termination: Special-Use IP addresses . 13
4.1.5.1 Special-Use IPv4 addresses . 13
4.1.5.2 Special-Use IPv6 addresses . 14
4.1.6 Extended O/A Model: Initial Offer/Answer Exchange . 14
4.2 H.248 Usage of SDP . 14
4.2.1 Local and Remote Descriptor . 14
4.2.2 Wildcarding of SDP fields . 16
5 Summary of SDP Usage Differences and Mapping Rules . 17
5.1 ITU-T Recommendation V.152 mapping rules . 20
5.2 ITU-T Recommendation T.38 mapping rules . 21
5.3 Packetization times in SDP . 22
6 SDP Mapping Examples . 22
6.1 SIP/SDP to H.248/SDP Example . 22
6.2 H.248/SDP to SIP/SDP Example . 24
6.2.1 General Mapping . 24
6.2.2 Specific SDP Lines: Timing ("t=" Line) . 25
6.2.3 Specific SDP Lines: Media Descriptions ("m=" Line) . 25
6.2.3.1 SDP Offer with Zero Media Description . 25
6.2.3.2 SDP Offer with Media Description(s) . 25
6.2.4 Specific SDP Lines: Origin ("o=" Line) . 27
6.3 Network Examples . 28
6.3.1 Pure PES scenario . 28
6.3.2 End-to-end Offer/Answer scenario with a RFC 3264-based SIP interface . 29
6.3.2.1 Overview . 29
6.3.2.2 Two Audio Streams. 29
6.3.2.2.1 H.248 MG does not support G.711 (as Audio Codec) . 29
6.3.2.2.2 H.248 MG does support also G.711 (as Audio Codec) . 33
6.3.3 End-to-end scenario with ES 129 163 call procedures . 33
7 Mapping aspects between SDP versions . 34
7.1 Introduction . 34
7.2 High-level guidelines . 34
7.3 Behaviour in case of "not supported SDP elements" . 34
ETSI
4 ETSI TR 183 046 V3.3.1 (2009-08)
Annex A: Special-Use IP Addresses . 35
A.1 Special-Use IPv4 Addresses . 35
A.2 Special-Use IPv6 Addresses . 36
Annex B: Change history . 37
History . 38

ETSI
5 ETSI TR 183 046 V3.3.1 (2009-08)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI
6 ETSI TR 183 046 V3.3.1 (2009-08)
1 Scope
The present document specifically describes the differing SDP usage between SIP [i.2] and H.248 [i.3] together with the
implied mapping capability that is performed by the MGC/Call Server.
SDP [i.1] has been widely selected as the protocol of choice within VoIP (or multimedia; MMoIP) to describe the
media requirements of a given session/call/connection. However, the different VoIP control protocols that utilise SDP
each specify differing requirements in their use of SDP. There is therefore a need for a MGC/Call Server to arbitrate
between these variations in the use of SDP and perform the interworking between them.
SDP [i.1] has been widely selected as the protocol of choice within VoIP (or multimedia; MMoIP) to describe the
media requirements of a given session/call/connection. However, the different VoIP control protocols that utilize SDP
each specify differing requirements in their use of SDP. There is therefore a need for a MGC/Call Server to arbitrate
between these variations in the use of SDP and perform the interworking between them. Specifically for the present
document, the differing SDP usage between SIP [i.2] and H.248 [i.3] will be described together with the implied
mapping capability that is performed by the MGC/Call Server.
Any network element (e.g. a MGCF) which handles both H.248/SDP signalling and SIP/SDP signalling provides any
necessary interworking between both signalling protocols (see figure 1). Such interworking comprises in general:
• interworking between SIP and H.248 signalling on message and procedural level (out of scope of the present
document); and
• interworking between the two SDP segments (SDP-SDP interworking; the scope of the present document).
The function providing SDP-to-SDP interworking between SIP/SDP and H.248/SDP signalling is, in the present
document, termed a "SDP Mapper" (see also clause 3.1).
The SDP Mapper performs SDP-SDP interworking capability to reconcile the different uses of SDP between control
protocols H.248 and SIP. In order to perform this role, the SDP Mapper takes into account i) which parts of SDP are
required to be sent on an interface, and ii) which parts of SDP are received on an interface. For a given session/call,
which use the two different control protocols at each end, some SDP parameters may be transited whilst others may not.
The SDP Mapper ensures that the differing requirements with regard to SDP handling at each end are mutually
satisfied.
Network Element handling
both H.248/SDP and SIP/SDP Signalling
Session
Initiation
SIP
Protocol
e.g. SIP Proxy,
SDP Mapper
SIP User Agent,
etc
SIP/SDP
-I
SIP
H.248
Media Gateway
Controller
(MGC)
Gateway
Control
Scope of
Protocol H.248/SDP
this
Technical Report
(text encoding
mode)
H.248
Media Gateway
(MG or MGW)
Figure 1: Scope
ETSI
7 ETSI TR 183 046 V3.3.1 (2009-08)
1.1 Applicability
This paper is applicable to any MGC/Call Server that exhibits both a SIP and H.248 interface. The former includes
interfaces to both User Equipments (i.e. SIP User Agents) and peer SIP proxies (like Call Servers). The latter includes
interfaces to any H.248-controlled MGW (e.g. RMGW, AMGW, TMGW, BMGW, etc.).
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
Not applicable.
2.2 Informative references
[i.1] IETF RFC 4566 (2006): "SDP: Session Description Protocol".
[i.2] IETF RFC 3261 (2002): "Session Initiation Protocol".
[i.3] ITU-T Recommendation H.248.1 (2005): "Gateway control protocol: Version 3".
[i.4] IETF RFC 3264 (2002): "An Offer/Answer Model with Session Description Protocol (SDP)".
[i.5] IETF RFC 3262 (2002): "Reliability of Provisional Responses in Session Initiation Protocol
(SIP)".
[i.6] IETF RFC 4317 (2005): "Session Description Protocol (SDP) Offer/Answer Examples".
[i.7] IETF RFC 2327 (1998): "SDP: Session Description Protocol".
[i.8] ITU-T Recommendation Q.1912.5 (2004): "Interworking between Session Initiation Protocol
(SIP) and Bearer Independent Call Control protocol or ISDN User Part".
[i.9] ITU-T Recommendation Q. Supplement 45 (09/2003): Technical Report TRQ.2815:
"Requirements for interworking BICC/ISUP network with originating/destination networks based
on Session Initiation Protocol and Session Description Protocol".
[i.10] ITU-T Recommendation T.38 (2005) "Procedures for real-time Group 3 facsimile communication
over IP networks".
[i.11] ITU-T Recommendation V.152 (2005): "Procedures for supporting voice-band data over IP
networks".
ETSI
8 ETSI TR 183 046 V3.3.1 (2009-08)
[i.12] ITU-T Recommendation H.248.39 (2006): "Gateway control protocol: H.248 SDP parameter
identification and wildcarding".
[i.13] ITU-T Recommendation H.248.49 (2007): "Gateway control protocol: Session description
protocol RFC and capabilities packages".
[i.14] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies".
[i.15] IETF RFC 3951: "Internet Low Bit Rate Codec (iLBC)".
[i.16] IETF RFC 3952: "Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate
Codec (iLBC) Speech".
[i.17] ETSI ES 283 002: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); H.248 Profile for controlling Access and Residential
Gateways".
[i.18] ETSI ES 283 024: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); H.248 Profile for controlling Trunking Media Gateways;
Protocol specification".
[i.19] ETSI EN 383 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Interworking between Session Initiation Protocol (SIP) and
Bearer Independent Call Control (BICC) Protocol or ISDN User Part (ISUP) [ITU-T
Recommendation Q.1912.5, modified]".
[i.20] ETSI TR 183 014: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); PSTN/ISDN Emulation; Development and Verification of
PSTN/ISDN Emulation".
[i.21] IETF RFC 3108: "Conventions for the use of the Session Description Protocol (SDP) for ATM
Bearer Connections".
[i.22] IETF RFC 4733: "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals".
[i.23] IETF RFC 2543: "SIP: Session Initiation Protocol".
[i.24] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications".
[i.25] IETF RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control".
[i.26] ITU-T Delayed Contribution COM16-D410-E (01/2004), "Proposal to begin work on H.248.1
version 3", (Clause 2.1.1 "SDP compatibility between H.248 and other SDP-based protocols").
[i.27] IETF RFC 3330: "Special-Use IPv4 Addresses".
[i.28] IETF RFC 5156: "Special-Use IPv6 Addresses".
[i.29] IETF draft-ietf-mmusic-sdp-capability-negotiation: "SDP Capability Negotiation".
[i.30] IETF draft-ietf-mmusic-sdp-media-capabilities: "SDP Media Capability Negotiation".
[i.31] 3GPP TS 29.802: "(G)MSC-S - (G)MSC-S Nc Interface based on the SIP-I protocol".
[i.32] IETF RFC 4291: "IP Version 6 Addressing Architecture".
[i.33] IETF RFC 4293: "Management Information Base for the Internet Protocol (IP)".
[i.34] IETF RFC 3849: "IPv6 Address Prefix Reserved for Documentation".
[i.35] IETF RFC 3056: "Connection of IPv6 Domains via IPv4 Clouds".
[i.36] IETF RFC 4380: "Teredo: Tunneling IPv6 over UDP through Network Address
Translations (NATs)".
[i.37] IETF RFC 1897: "IPv6 Testing Address Allocation".
ETSI
9 ETSI TR 183 046 V3.3.1 (2009-08)
[i.38] IETF RFC 3701: "6bone (IPv6 Testing Address Allocation) Phaseout".
[i.39] IETF RFC 4843: "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)".
[i.40] IETF RFC 4773: "Administration of the IANA Special Purpose IPv6 Address Block".
[i.41] IETF RFC 3232: "Assigned Numbers: RFC 1700 is Replaced by an On-line Database".
[i.42] IETF RFC 1918: "Address Allocation for Private Internets".
[i.43] IETF RFC 1797: "Class A Subnet Experiment".
[i.44] IETF RFC 3068: "An Anycast Prefix for 6to4 Relay Routers".
[i.45] IETF RFC 3171: "IANA Guidelines for IPv4 Multicast Address Assignments".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
SDP Mapper: function for SDP-to-SDP interworking between two different, SDP-using signalling protocols
NOTE: One of these signalling protocols is the Gateway Control Protocol according H.248 in text-encoding
mode. The other signalling protocol is SIP in the scope of the present document.
SIP-I: use of SIP with a message body that encapsulates ISUP information
NOTE: Definition according to ITU-T Recommendation Q.1912.5 [i.8] and clause 4.8 in ITU-T Supplement 45
to Q-series Recommendations (TRQ.2815) [i.9].
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ALN Analog Line
AMGW Access Media GateWay
B2BIH Back-to-Back IP Host (mode)
BCF Bearer Control Function
BGF Border Gateway Function
BMGW Border Media GateWay
DNS Domain Name System
GCP Gateway Control Protocol
GW GateWay
IP Internet Protocol
IPR IP router (mode)
ISDN Integrated Services Digital Network
ISUP ISDN User Part
LCD Local Control Descriptor
LD Local Descriptor (H.248)
MG, MGW Media GateWay
MGC Media Gateway Controller
MGCF MGC Function
MIME Multipurpose Internet Mail Extensions
MMoIP MultiMedia-over-IP
PCMA Pulse Code Modulation A-law
PSTN Public Switched Telephone Network
RD Remote Descriptor (H.248)
ETSI
10 ETSI TR 183 046 V3.3.1 (2009-08)
RFC Request For Comments (IETF)
RMGW Residential Media GateWay
RTCP RTP Control Protocol
RTP Real-time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SIP-I SIP with the MIME encoding of ISUP
TCP Transmission Control Protocol
TDM Time Division Multiplexing
TGW Trunking GateWay
TMGW Trunking Media GateWay
TMR Transmission Medium Requiremenrt
UA User Agent
UDP User Datagram Protocol
USI User Service Information
VoIP Voice-over-IP
4 Differences between SIP/SDP and H.248/SDP
Usage
Clause 4.1 describes the SDP usage in SIP. Clause 4.2 describes the SDP usage in H.248. Clause 4.3 summarizes the
differences between them.
4.1 SIP usage of SDP
SIP uses SDP for describing multimedia sessions RFC 3261 [i.2].
In terms of bearer control and usage of SDP, SIP has defined a basic Offer/Answer model that is documented in
RFC 3264 [i.4] and illustrated in RFC 4317 [i.6]. The Offer will contain zero or more media streams. The basic
Offer/Answer model is extended by an enhanced Offer/Answer model according IETF drafts [i.29] and [i.30].
The "offer-answer" mechanism mandates that when a block SDP is sent in one direction ("the Offer"), a corresponding
block of SDP should be returned to the originator ("the Answer"). It is not possible to make a new "Offer" until an
"Answer" is received. However, within a given session, there is no limit to the number of Offer/Answer exchanges that
may occur (i.e. mid-session bearer change).
SIP does not permit the SDP block to contain more than one session description, although multiple media streams may
be contained in each session description (with the implication that all streams are required simultaneously), and multiple
codecs may be contained within each media stream (with the implication that one of the codecs is selected for use).
When SDP is sent in SIP, the following SDP lines are mandatory:
• Protocol Version line:
Always set to "v=0".
NOTE: This value is recommended by RFCs on SDP, i.e. the "v=" line is not used for discrimination between the
"SDP versions" as defined by RFC 4566 [i.1] and its predecessor RFC 2327 [i.7]. Both RFCs defining
version 0 of the SDP.
• Session Name line:
This can be defaulted to "s=" or else hold a string as defined in RFC 4566 [i.1].
• Timing line:
This can be defaulted to "t=0 0".
• Origin line:
This will be set to "o= IN IP4 (or IP6) (or
)".
The session number can be zero and the session version initialized to zero. The IP4 (or IP6) address can be the
ETSI
11 ETSI TR 183 046 V3.3.1 (2009-08)
same as that appearing on the Connection Line.
The can default to "-".
• Connection Data line:
Holds the network type, address type and connection address. Set to "c=IN IP4 " or "c=IN IP6
".
• If there is at least one media stream, the following line is also mandatory:
• Media Description line:
Holds the media type, port number and the "codec types" (defined by transport protocol "proto" and media
format "fmt" fields).
4.1.1 Basic O/A Model (RFC 3264 [i.4]): Initial Offer/Answer Exchange
SIP permits the initial Offer/Answer exchange within a SIP session to be realized via a number of SIP message
combinations, dependent on when the necessary SDP information becomes available to be passed across the SIP
interface. This is illustrated in table 1.
Table 1: Offer/Answer scenarios in SIP
SDP OFFER in: SDP ANSWER in: Comments / Additional Information
INVITE 180/183 and 200 OK The ANSWER is repeated in the 200 OK if 100rel
not being used.
INVITE 200 OK Late terminating SDP.
180 / 183 PRACK This is late originating SDP.
RFC 3262 [i.5] mandates that the ANSWER to a
18X OFFER will be included in the PRACK.
200 OK ACK Late SDP at both originating and terminating
ends.
RFC 3264 [i.4] mandates that the same SDP Timing (t=) line will appear in both SDP blocks (i.e. the Offer and
corresponding Answer) and that there will be identical numbers of Media Description (m=) lines in both SDP blocks
(the Offer and corresponding Answer). The implication of the latter is there will be a mechanism by which a given
media line can be rejected/disabled. This is achieved by one or more of the following techniques:
• via the use of the Media Attribute line "a=inactive" to indicate that the related SDP is not sending/receiving;
• via the use of a null IP address of 0.0.0.0 (see notes 1 and 2; see also Annex A concerning a different semantic
in SIP/SIP-I) in the Connection Data (c=) line;
NOTE 1: The initial specification for SIP version SIP/2.0 defined that placing media on hold was accomplished by
setting the connection address to 0.0.0.0 (see RFC 2543 [i.23], paragraph B.5). Its usage for putting a call
or media on hold is no longer recommended for SIP/2.0 (see RFC 3261 [i.2]), since it does not allow for
RTCP to be used with held streams, does not work with IPv6, and breaks with connection-oriented media
(see RFC 3264 [i.4], paragraph 8.4).
But there is one applicability statement in the context of Offer/Answer procedures (see RFC 3264 [i.4]).
However, it can be useful in an initial Offer when the offerer knows it wants to use a particular set of
media streams and formats, but does not know the addresses and ports at the time of the Offer.
Of course, when used, the port number is NOT zero, which would specify that the stream has been
disabled (see note 3). An SIP user agent will be capable of receiving SDP with a connection address of
0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer.
NOTE 2: IPv6 is different. There is no specification for the correspondent usage of the IPv6 connection address
value 0:0:0:0:0:0:0:0 (or the abbreviated form).
• via the use of a null (zero) port number the Media Description (m=) line (see note 3).
ETSI
12 ETSI TR 183 046 V3.3.1 (2009-08)
NOTE 3: The usage of a null port number within SDP was not yet standardized in the past (before RFC 3264 [i.4]).
There does not exist any normative or informative text, neither from ETSI nor IETF. It is recognized that
this mechanism has been already implemented, but the usage of the null port is not recommended for
future implementations, although they still have to accept the null port from legacy implementations.
It has also to be noted that the "null port" relates to the well-known port category in case of UDP and
TCP, which is still reserved by IANA (http://www.iana.org/assignments/port-numbers), i.e. not allowed
to be used for these transport protocols.
4.1.1.1 Special-Use IP addresses
4.1.1.1.1 Special-Use IPv4 addresses
RFC 3330 [i.27] defines special-use IPv4 addresses. Special-use IPv4 addresses may be used in SIP, but the
applicability is limited (see clause A.1).
4.1.1.1.2 Special-Use IPv6 addresses
RFC 5156 [i.28] defines special-use IPv6 addresses. Special-use IPv6 addresses may be used in SIP, but the
applicability is limited (see clause A.2).
4.1.2 Basic O/A Model (RFC 3264): Subsequent Offer/Answer
Exchange(s)
It is possible to perform mid-session bearer modifications via subsequent Offer/Answer exchanges.
The new SDP Offer is conveyed either in an UPDATE message or else via a re-INVITE. A re-INVITE may only be
used in the post Answer (200 OK to INVITE) phase of the session. An UPDATE may be used once a dialogue has been
established. The resulting SDP Answer is returned in the 200 OK (either to UPDATE or re-INVITE).
RFC 3264 [i.4] applies a number of rules regarding the subsequent Offer/Answer exchange:
• the same Timing (t=) line will be used as previously;
• the same Session Name (s=) line will be used as previously;
• the Origin (o=) line is unchanged apart from the session version being incremented.
Note that the session version is incremented any time that the sent SDP (be it an Offer or Answer) has been
altered (or to put it another way, if the version has not changed, then the SDP will be identical to that
previously sent);
• the number of Media Description (m=) lines will not be reduced from that sent previously
NOTE 1: The initial Offer could e.g. contain zero media streams.
A media flow (which could related to an H.248 Stream or Termination) may be disabled via the "a=inactive"
mechanism and/or null IP/port addresses.
NOTE 2: See also handling of special-use IPv4 addresses by SDP mapper, clause 4.1.5.1.
A new media flow (e.g. bearer redirection) may be enabled via exchanging a new address and port in the Connection
Data (c=) and Media Description (m=) lines respectively or via the Media Attribute (a=active) line. The contents of
Media Description lines, Connection lines and Media Attribute lines can be altered as desired (e.g. to change
address / port / media format / codec list etc.).
4.1.3 Bearer Termination
At SIP session termination, there is no explicit tear down of the bearer, i.e. the SIP BYE terminates the SIP session and
the underlying bearer (e.g. RTP session) is also destroyed, e.g.:
• Bearer endpoint located in a SIP user equipment: the bearer is implicitly destroyed as a result of the SIP BYE.
ETSI
13 ETSI TR 183 046 V3.3.1 (2009-08)
• Bearer endpoint located in an H.248 MG: the SIP BYE will lead to an H.248 Subtract request command from
MGC to MG, which then releases the underlying bearer in the MG.
4.1.4 SDP redundancy between session- and media-level sections
SDP allows redundancy between session-level and media-level sections concerning specific SDP line types. Following
lines may be redundant in SIP/SDP: "c=", "i=","b=","k=" and "a=" lines, see RFC 4566 [i.1]:
…An SDP session description consists of a session-level sectionfollowed by zero or more media-level
sections. The session-level
part starts with a "v=" line and continues to the first media-level
section. Each media-level section starts with an "m=" line and
continues to the next media-level section or end of the whole session
description. In general, session-level values are the default for
all media unless overridden by an equivalent media-level value.
Some lines in each description are REQUIRED and some are OPTIONAL,
but all MUST appear in exactly the order given here (the fixed order
greatly enhances error detection and allows for a simple parser).
OPTIONAL items are marked with a "*".

Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions

Time description
t= (time the session is active)
r=* (zero or more repeat times)

Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)
Such duplicated SDP lines are not necessarily redundant in SIP/SDP in case of separate served user instances for
session-level and media-level descriptions in a SIP entity, but could provide redundant information if applied on
H.248/SDP (because the controlled H.248 media gateway is centric to the media-level description of SDP; see
clause 4.2).
4.1.5 H.248 IP Stream/Termination: Special-Use IP addresses
The H.248 IP-based Stream or Termination belongs either to an "IP host" or "IP router" entity, dependent of the H.248
Context type (B2BIH versus IPR). However, both IP entities are associated to an H.248 Context, thus under control of
an MGC. However the applicability of special-use IP addresses is limited.
4.1.5.1 Special-Use IPv4 addresses
RFC 3330 [i.27] defines special-use IPv4 addresses. Special-use IPv4 addresses may be used for H.248 IP bearers, but
the applicability is limited (see clause A.1).
ETSI
14 ETSI TR 183 046 V3.3.1 (2009-08)
4.1.5.2 Special-Use IPv6 addresses
RFC 5156 [i.28] defines special-use IPv6 addresses. Special-use IPv6 addresses may be used for H.248 IP bearers, but
the applicability is limited (see clause A.2).
4.1.6 Extended O/A Model: Initial Offer/Answer Exchange
The extended Offer/Answer model (according IETF drafts [i.29] and [i.30]) defines an SDP capability negotiation
model with additional support to exchange "potential configurations".
The IETF drafts are technically stable, but not yet published at the time of approval of the present document. It is
expected that the extended O/A model will not change the existing H.248 "capability negotiation" model. This area is
for further study and may be subject of an update of the present document.
The extended Offer/Answer model requires six additional SDP elements (SDP attributes "a=csup", "a=creq",
"a=acap", "a=tcap", "a=pcfg" and "a=acfg").
4.2 H.248 Usage of SDP
Figure 2 provides an overview of the structure of the H.248 Media Descriptor. SDP is used within the H.248 Stream
Descriptor in the Local Descriptor (LD) and Remote Descriptor (RD). There are thus separate SDP specifications for
ingress traffic (provided by the H.248 LD) and egress traffic (provided by the H.248 RD). The (SDP) media description
within that SDP block is reflected in the LD and RD and determines the H.248 media gateway behaviour.
Conceptual difference, but same objective!
H.248 Media Descriptor (in H.248 Commands)
H.248 “Media Descriptor” vs SDP “Media Description”
Part 1: TerminationState Descriptor
Part 2: Stream Descriptor
Part 2.1: LocalControl Descriptor
SSDDPP S Sppeeccififiiccationation
Part 2.2: Local Descriptor (“LD”)
PaPart 1rt 1:: SeSessissionon DeDescriptiscriptioon n ((rredueducceed ind in H. H.248!248!))
v= v= …… [us[useedd aass ‘s ‘sepaeparraatotor elr eleemmentent’’]]
SDPSDP S Sppeeccififiiccaattionion forfor InInggrr esesss TTrraffiafficc
o= o= …… [[--> H> H.248 248 PPrrooffililee,, seseee cl clauausese 5. 5.16]16]
……
s= s= …… [[--> H> H.248 248 PPrrooffililee,, seseee cl clauausese 5. 5.16]16]
PaPart 2rt 2:: TiTimmee DeDescscrriippttionion (r(reedduucceedd i inn H H.248!248!))
t= t= …… [[-->> HH.248 248 PPrrofofileile,, se seee c cllaauusese 5. 5.16]16]
Part 2.3: Remote Descriptor (“RD”)
PaPart 3rt 3:: MedMediiaa DeDescriscriptiptioonn
SDPSDP S Sppeeccififiiccaattionion forfor EgrEgr ee ss ss TTrraffiafficc
c= c= ……
that’s the crucial part
……
m= m= ……
for H.248 Streams
b= b= ……
k=*k=* … … [-> H.248 Profile, see clause 5.15]
a= a= ……
Part 2.4: Statistics Descriptor

Figure 2: Overview Structure of H.248 Media Descriptor
(H.248 "Media Descriptor" vs SDP "Media Description")
NOTE: H.248.1 may provide in future that general information on H.248 "Media Descriptor" vs SDP "Media
Description". The information of this clause may be then replaced by a reference to H.248.1.
4.2.1 Local and Remote Descriptor
The H.248 protocol [i.3] mandates the use of SDP in the H.248 LocalDescriptor (LD) and RemoteDescriptor (RD),
when text encoding the H.248 protocol messages.
ETSI
... ...
...
15 ETSI TR 183 046 V3.3.1 (2009-08)
For the LD sent from the MGC to the MGW, a number of exceptions from RFC 4566 [i.1] are permitted:
• the "s=", "t=" and "o=" lines are optional;
• the use of the CHOOSE wildcard is allowed in place of a single parameter value;
• the use of alternatives is allowed in place of a single parameter value.
The LD returned from the MGW contains the "s=", "t=" and "o=" lines. Furthermore, if the RD is returned from the
MGW, the RD contains the "s=", "t=" and "o=" lines as well.
In H.248, separate LD/RD are provided per media stream (i.e. within a H.248 StreamDescriptor) within a termination.
Therefore, for multimedia (e.g. audio and video), separate StreamDescriptors will be used (see figure 3). H.248 does not
permit multiple Media Description ("m=") lines to be present in a single session (= single H.248 Stream) description.
Within a single Media Description line, multiple codecs may be specified and they are interpreted as a request to select
one or more of the list options, with the list being in descending order of preference (see clause 7.1.8/H.248.1 [i.3]).
However, H.248 does allow multiple session descriptions to be included as alternatives within a single LD/RD and each
of these session descriptions containing a single Media Description line.
To enable interpretation of multiple session descriptions and/or multiple codecs within a Media Description line, H.248
has defined two additional flags, namely ReserveGroup and ReserveValue. The former indicates whether resource
reservation is required to support all or one of the (multiple) session descriptions whilst the latter indicates whether
resource reservation is required for all or one of the cited codecs in the Media Description line. If there is only one
session description present, then ReserveGroup is redundant.
Media Descriptor
Stream Descriptor „1“
Local/Remote Descriptor
„Session list“
controlled through
Session description 1
ReserveGroup
Media description: Codec List
„SDP block“
Session description N
Media description: Codec List
„Codec list“
controlled through
ReserveValue
Stream Descriptor „M“
Local/Remote Descriptor
Session description 1
Media description: Codec List
„SDP block“
Session description N
M
Media description: Codec List
Figure 3: "SDP Blocks" embedded in H.248 Media Descriptor
(here: M H.248 Streams per Termination)
The use of multiple session descriptions as opposed to multiple codecs on a Media Description line is somewhat
"confusing" in H.248. Multiple session descriptions do enable separate Media Attribute lines to be specified for the
audio codec(s) in a given session description, e.g. consider the following two examples of a H.248 LD.
ETSI
16 ETSI TR 183 046 V3.3.1 (2009-08)
NOTE 1: The reason is of historical nature: "codec negotiation" procedures for H.248 were defined before the SDP
Offer/Answer model was published. See ITU-T T01-SG16-040120-D-0410 [i.26]: "H.248's use of SDP
limits the session descriptions to a single m-line per v-line. This was done to solve the problem of
determining which m-lines were to be concurrent sessions as opposed to alternative sessions. Several
years later, the SDP community introduced the offer/answer model described in RFC 3264 [i.4] which
requires all m-lines to exist in a single session (v-line). The two solutions are mutually exclusive: Entities
that use RFC 3264 [i.4] will reject H.248 compliant SDP as invalid, and H.248 entities will reject
RFC 3264 [i.4] constructs as invalid."
NOTE 2: Only the Local Descriptor is shown, other information elements of the H.248 Message are omitted.
Example 1: Local Descriptor (H.248/SDP)
…
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4 8
a=ptime:30
} …
Example 2: Local Descriptor (H.248/SDP)
…
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4
a=ptime:30
v=0
c=IN IP4 $
m=audio $ RTP/AVP 8
a=ptime:20
} …
The first block contains a single session description with multiple codecs and a Media Attribute line (ptime) that is
compatible with both codecs (i.e. G.723.1 and G.711 A-law (PCMA)). In the latter block, different packetization times
have been specified (and G.723.1 requires 30 ms as a default packetization time and cannot use 20 ms due to the
inherent codec frame size of 30 ms). The use of multiple session descriptions is confusing and could be avoided by
regarding the ptime as a preference rather than a mandate and letting the MG override the preference where there is a
mismatch with the codec requirements (NOTE. the MG is not allowed to overwrite preferences according the latest
ITU-T Recommendation H.248.1 [i.3]). Alternately, the ptime may be omitted and the MG can apply a default ptime
appropriate to the codec(s), i.e.:
Example 3: Local Descriptor (H.248/SDP)
…
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4 8
} …
4.2.2 Wildcarding of SDP fields
The H.248 protocol supports the two wildcard type CHOOSE and ALL, which may be applied also on SDP information
elements carried with H.248. ITU-T Recommendation H.248.39 [i.12] describes all the principles used to identify a
single SDP sub-field and how to apply wildcarding to that sub-field.
ETSI
17 ETSI TR 183 046 V3.3.1 (2009-08)
5 Summary of SDP Usage Differences and Mapping
Rules
The differences of SDP usage between SIP and H.248 are listed in table 2.
Table 2: SDP usage differences between H.248/SDP and SIP/SDP
No. Issue Differences
1 Number of Session H.248 permits multiple Session Descriptions per SDP
Descriptions block whilst SIP permits only one.
2 Number of Media Descriptions H.248 permits only one Media Description ("m=") line per
lines Session Description whilst SIP permits multiple Media
Description lines.
In practice, SIP uses a Media Description line per media
type (e.g. audio, video) but in theory could also specify
multiple Media Description lines of a given media type in
...