SIST-TS TS 102 108 V4.1.1:2004

• Abstract:

  Implementation of TIPHON Meta-Protocol using Extended MEGACO Package

• Status: Published
• Publication Date: 31-Mar-2004
• ICS: 33.020 - Telecommunications in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Apr-2004
• Due Date: 01-Apr-2004
• Completion Date: 01-Apr-2004
• Ref Project: ETSI TS 102 108 V4.1.1 (2002-06) - Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; H.248/MEGACO Profile for TIPHON reference point I3; InterConnect Function (ICF) control over reference point I3

SIST-TS TS 102 108 V4.1.1:2004 is the Slovenian adoption of ETSI TS 102 108 V4.1.1 for Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4. It specifies how the TIPHON meta-protocol for reference point I3 is mapped to ITU-T Recommendation H.248/IETF MEGACO so that a controller can manage InterConnect Function (ICF) devices in an IP transport domain. In practice, it is used for edge devices such as firewalls, address translators and other middleboxes when setting up basic bearer and QoS bearer flows.

What does SIST-TS TS 102 108 V4.1.1:2004 specify?

SIST-TS TS 102 108 V4.1.1:2004 specifies an interoperable H.248/MEGACO profile for TIPHON reference point I3. The profile focuses on conveying flow properties to edge devices in the transport plane, rather than using the full H.248 feature set.

The document says the profile can be used to control equipment within an IP network such as firewalls, address translators, middleboxes and other network edge devices. It also states that security issues are outside the scope of the document, and that the profile is a subset of H.248 that mandates some optional parts and leaves other H.248 options outside scope.

The document is organised into:

• clauses for scope, references, definitions, profile scope, interface setup, flow establishment and management operations
• normative annexes for meta-protocol mapping and meta-protocol to SDP mapping
• informative annexes with template usage scenarios, an option on the basic scenarios, and a bibliography

Annex	What it covers
Annex A	Normative mapping with the meta-protocol, including primitive mappings, binary and text encoding, and error reasons
Annex B	Normative mapping from the meta-protocol to SDP, including mappable fields, QoS mechanism values and unmappable fields
Annex C	Informative TIPHON template usage scenarios, including address translation, source filtering, explicit RTCP addresses and H323 RAS pin-hole examples
Annex D	Informative options on the basic scenarios, including transport activation
Annex E	Informative bibliography

What are the key requirements of SIST-TS TS 102 108 V4.1.1:2004?

SIST-TS TS 102 108 V4.1.1:2004 defines which H.248 functions, packages and message elements are used for TIPHON I3 control, and how transport flows and QoS-related information are handled. For an implementer, this means the controller and Middlebox must agree on a restricted, profile-specific way to create, modify and release transport flows.

The H.248 profile is deliberately narrow

Clause 4 says the profile uses H.248 to convey only flow properties to edge devices in the transport plane. That means implementers should support the H.248 subset defined here, not the whole protocol set.

Clause 4.1 states that the profile is used to control Middlebox devices in the transport plane, and the note identifies a Middlebox as a physical implementation of an ICF. In practice, this is the control relationship between a controller and a firewall, NAT or similar device.

The profile supports basic bearer and QoS bearer setup

Clause 4.3 says the supported TIPHON Release 4 service capabilities are basic bearer and QoS bearer set-up. For readers, that means the profile is aimed at getting media or signalling flows established with or without QoS handling.

Clause 6.6 adds the QoS parameters that matter in practice: maximum packet size, packet rate, delay budget, packet delay variation and packet loss. These are the values the controller must provide when a flow needs QoS treatment.

Error handling is profile-specific

Clause 4.5 defines how a receiver handles unsupported or malformed H.248 information elements. The practical rule is simple: ignore unsupported optional items, reject or fail when a mandatory item cannot be accepted, and use the listed H.248 error reasons for unknown commands, descriptors, properties or parameters.

This matters because the profile is intended to interoperate across implementations with different feature sets. A compliant Middlebox should fail cleanly rather than misinterpret a request.

Only selected H.248 packages and messages are used

Clause 6.2 requires support for the Generic package, Base Root package, Network package and EMP package, with the RTP package only if RTP statistics are supported. Clause 6.3 then limits the required messages to Add, Modify and Subtract requests and replies, plus the related ContextId, LocalDescriptor, RemoteDescriptor and TerminationID parameters.

For implementers, this means the profile is built around reservation, establishment and release of transport resources, not the whole H.248 command set.

The transport procedure follows reservation, establishment and release

Clause 6.4 describes the default transport setup procedure as a sequence of reservation, confirmation, establishment, confirmation, release request and release confirmation. In practice, the controller first asks what can be supported, then commits to a choice, then confirms the live transport path.

Annex A maps those TIPHON primitives to H.248 message types. That mapping is the basis for interoperability between the TIPHON meta-protocol and H.248/MEGACO.

QoS and marking use specific mappings

Clause 6.6.1 says incoming flows use the QoS values carried in LocalDescriptors, and that packetRate maps to the EMP tokenrate value. Clause 6.6.2 says outgoing flow QoS can be handled through ToS tagging or RSVP, depending on what the Middlebox supports.

Clause 6.7 covers ToS filtering on incoming flows. For operators, this means the controller can request packet marking or filtering behavior through the same profile when the device supports it.

SDP mapping is part of the profile

Annex B maps the meta-protocol into SDP fields and attributes. It shows how the protocol version, origin, session, connection, bandwidth and transport fields are populated, and how attributes such as rtpmap, ptime, fmtp and X-ToS are used.

This is important when the profile is represented in SDP-based signalling or when transport sessions must be described in text form for signalling interworking.

What terms does SIST-TS TS 102 108 V4.1.1:2004 define?

• InterConnect Function (ICF) - The controlled function in a transport domain that carries out edge-device behavior such as firewalling, address translation or QoS-related actions.
• Middlebox (MB) - A firewall or NAT device coupled to a MIDCOM server, offering those services to clients.
• Transport Resource Manager (TRM) - The controller role that sends instructions to the ICF.
• Quality of Service (QoS) - The treatment of a flow using parameters such as packet size, rate, delay and loss.
• Resource ReSerVation Set-up Protocol (RSVP) - The reservation protocol used for QoS flow specification in this profile.
• RealTime Conferencing Protocol (RTCP) - The control protocol associated with RTP media flows in the examples and mappings.
• flow - A single data stream identified by source and destination addresses, ports and protocol number.
• TIPHON compliant - An entity that meets the mandatory TIPHON requirements and the relevant TIPHON specification parts.

Who uses SIST-TS TS 102 108 V4.1.1:2004?

SIST-TS TS 102 108 V4.1.1:2004 is used by people who design, implement or operate TIPHON-based transport control. That includes network operators and administrators who control transport-domain edge devices, and vendors who build the controller or Middlebox side of the H.248 relationship.

It is also relevant to engineers working on firewalls, address translators, VoIP edge devices, gateways and signalling pin-holes. The examples include media flows, explicit RTCP handling and H323 Registration Admission and Status (RAS) control flows, so it is useful where signalling and media control meet.

Which standards are used with SIST-TS TS 102 108 V4.1.1:2004?

• ITU-T Recommendation H.248 - Provides the base gateway control protocol and the control semantics used by this profile.
• ETSI TS 101 882 - Defines the TIPHON meta-protocol and the I3 reference point that this document maps to H.248.
• ETSI TS 101 314 - Defines the TIPHON abstract architecture and reference points.
• IETF RFC 2327 - Supplies SDP, which this profile uses for transport-session description mapping.
• ETSI TS 101 332 - Defines the TIPHON Extended H.248/MEGACO Package (EMP) used by the profile.
• IETF RFC 2205 - Supplies RSVP, which is used for QoS flowspec mapping.
• ETSI TS 101 329-3 - Provides TIPHON QoS signalling and control rules referenced by the profile.

What does the SIST-TS TS 102 108 V4.1.1:2004 document contain?

SIST-TS TS 102 108 V4.1.1:2004 contains the codepoint mappings between TIPHON primitives and H.248 messages, plus the associated data-element mappings and error reasons in Annex A. It also contains the SDP field mapping rules in Annex B, including the fields used for transport, bandwidth and QoS-related attributes.

The informative annexes give practical examples rather than abstract rules. Annex C shows template usage scenarios for address translation, source filtering, explicit RTCP addresses and an H323 RAS control pin-hole, while Annex D shows the transport activation option that keeps the forward path muted until the call is established.

For someone implementing or checking interoperability, the most useful parts are the message sequences, descriptor examples, transport setup procedure and error handling notes. Those parts show how to move from the TIPHON meta-protocol into concrete H.248 control exchanges.

SLOVENSKI STANDARD
01-april-2004
+DUPRQL]DFLMDWHOHNRPXQLNDFLMLQLQWHUQHWQHJDSURWRNRODSUHNRPUHåLM7,3+21
L]GDMD3URILO+0(*$&2]DUHIHUHQþQRWRþNR,SUL7,3+21.UPLOMHQMH
IXQNFLMHPHGVHERMQHJDSRYH]RYDQMD,&)SUHNUHIHUHQþQHWRþNH,
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON)
Release 4; H.248/MEGACO Profile for TIPHON reference point I3; InterConnect
Function (ICF) control over reference point I3
Ta slovenski standard je istoveten z: TS 102 108 Version 4.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Specification
Telecommunications and Internet Protocol Harmonization
Over Networks (TIPHON) Release 4;
H.248/MEGACO Profile for TIPHON reference point I3;
InterConnect Function (ICF) control over reference point I3

2 ETSI TS 102 108 V4.1.1 (2002-06)

Reference
DTS/TIPHON-03028R4
Keywords
architecture, configuration, H.248, internet, IP,
megaco, network, protocol, telephony, VoIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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, send your comment to:
[e-mail]
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 2002.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI 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.
ETSI
3 ETSI TS 102 108 V4.1.1 (2002-06)
Contents
Intellectual Property Rights.5
Foreword.5
Introduction .5
1 Scope.6
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.8
4 Scope of the H.248 ICF profile .8
4.1 Use of the H.248 ICF profile.9
4.2 Functionality supported by the Profile .9
4.3 Service capabilities supported.9
4.4 General note on compliance .9
4.5 Error handling.9
4.6 Security.10
5 Setting up of the controller-middlebox control interface .10
6 Use of the profile for the establishment of transport flows .10
6.1 Process used.10
6.2 Packages supported.11
6.3 Required H.248/MEGACO messages and parameters .11
6.3.1 Messages.11
6.3.2 Parameters.11
6.3.3 Error values.11
6.3.4 General notes on option use in H.248.12
6.4 Default transport setup procedure.12
6.5 Example flows for the use of this profile .13
6.6 QoS flows.13
6.6.1 QoS on flows through the middlebox .13
6.6.1.1 QoS policing of incoming flows .13
6.6.2 QoS on outgoing flows .13
6.6.2.1 ToS tagging of outgoing flows.13
6.6.2.2 RSVP.13
6.7 ToS filtering on incoming flows.14
7 Management operations.14
Annex A (normative): Mapping with meta-protocol .15
A.1 Code point mapping .15
A.1.1 Primitive mappings.15
A.1.2 Binary encoding.16
A.1.2.1 For an IP-based transport flow.16
A.1.3 Text encoding.16
A.1.3.1 For an IP-based transport flow.16
A.2 Error reasons.17
Annex B (normative): Meta-protocol to SDP mapping .18
B.1 Mappable fields.18
B.2 Specifying the OriginatorMpoA.19
B.3 Specifying QoS mechanism specific values.19
B.3.1 DiffServ Type of Service (ToS) value.19
ETSI
4 ETSI TS 102 108 V4.1.1 (2002-06)
B.3.2 RSVP.19
B.4 Unmappable fields.20
Annex C (informative): TIPHON template usage scenarios .21
C.1 Basic flow without address translation without source filtering .21
C.2 Basic scenario with address translation (the legacy mode) .24
C.3 Flow with address translation without source filtering .28
C.4 Flow without address translation with source filtering .33
C.5 Flow with address translation with source filtering .37
C.6 Explicit RTCP addresses with source filtering and address translation .42
C.7 Signalling: example flow for a H323 RAS control pin-hole.49
Annex D (informative): Options on the basic scenarios.52
D.1 Transport activation option .52
Annex E (informative): Bibliography.55
History .56

ETSI
5 ETSI TS 102 108 V4.1.1 (2002-06)
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 Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
Introduction
The present document defines technology mappings of the meta-protocol to reference points in the transport plane. It
specifies the technology mappings to reference point I3 as defined in TS 101 882 [2].
ETSI
SCN Plane
6 ETSI TS 102 108 V4.1.1 (2002-06)
1 Scope
The present document describes a mapping of the meta-protocol for reference point I3, as described in annex D of
TS 101 882 [2], to the ITU-T Recommendation H.248 [1]/IETF MEGACO protocol, to produce an interoperable profile
(subset) of H.248/MEGACO augmented by the TPC Extension package defined in TS 101 332 [5].
It may be used for the control of equipment within an IP network such as Firewalls, Address Translators, Middleboxes
and also other network edge devices.
Originating/
Originating/Terminating Network FG Terminating/
Intermediate
Terminating
Originating
Network FG
Terminal FG
Serving Home
Gateway FG
Network FG Network FG
User
Service
CR QoSPE CR
QoSPE CR QoSPE
QoSPE profile
Profile
S3 S4 S3 S4 S3 S4
S4
S1 S2
S1
SC2’ SC2’ SC2’
SC SC
SC
SC SC
R1 R2
TREG SREG HREG
SC2
SC1 SC2 SC2
SC2
C1 C2 C2 C3
C1
CC CC CC CC CC
C2
C1 C3
C1 C2
BC BC BC
BC
BC
N2
N1 N2 N2 N3
M3
M1 M2 M2 M2
MC MC MC MC MC
T2 T2
T2
T1 T1
TU TPE TU TPE TU TPE
I6 I4 I6 I4
I6 I4
I1
I1
I2
I2
TRM TRM TRM TRM TRM
I3 I3
I5 I3 I5 I3
I3
I3 I5
ICF TF ICF TF ICF
ICF ICF TF ICF
Terminating/
Originating/
Originating
Core transport
Terminating
Ingress/Egress Egress/Ingress
Gateway FG
domain
Terminal FG
transport domain transport domain

Figure 1a: TIPHON architecture with reference point I3 highlighted
ETSI
r c
Se vi e
Bearer
Media
Transport Transport Transport
s Servi
flow Control ce
Call
control
Service
control
7 ETSI TS 102 108 V4.1.1 (2002-06)
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• 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.
• For a non-specific reference, the latest version applies.
[1] ITU-T Recommendation H.248 (2000): "Gateway control protocol".
[2] ETSI TS 101 882: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Protocol Framework Definition; General (meta-protocol)".
[3] ETSI TS 101 314: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Abstract Architecture and Reference Points Definition; Network
Architecture and Reference Points".
[4] IETF RFC 2327 (April 1998): "SDP Session Description Protocol".
[5] ETSI TS 101 332: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 4; Interface Protocol Requirements Definition; TIPHON Extended
H.248/MEGACO Package (EMP) Specification; ICF Control over Reference Point".
[6] IETF RFC 2205: "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification".
[7] ETSI TS 101 329-3: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; End-to-end Quality of Service in TIPHON systems; Part 3: Signalling and
control of end-to-end Quality of Service (QoS)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
charging: process of determining the amount of money a user shall pay for usage of a certain service
flow: single data stream, identified by a set of characteristic values (source address, source port, destination address,
destination port, protocol number)
functional entity: entity in a system that performs a specific set of functions
functional group: collection of functional entities within a domain
NOTE: In TIPHON systems functional groups are used to structure the necessary functionality to offer IP
telephony services across domains.
IP endpoint: device that originates or terminates the IP based part of a call
NOTE: Endpoints include H.323 clients, and IP telephony gateways.
IP network: packet transport network comprising one or more transport domains each employing the IP protocol
middlebox: firewall or NAT device which is coupled to a MIDCOM server, which offers the firewall/NAT services to
clients
network: telecommunications network that provides telecommunications services
ETSI
8 ETSI TS 102 108 V4.1.1 (2002-06)
protocol: set of semantics, syntax and procedures which govern the exchange of information across an interface
Switched Circuit Network (SCN): telecommunications network, e.g. Public Switched Telephone Network (PSTN),
Integrated Services Digital Network (ISDN), and General System for Mobile communications (GSM), that uses
circuit-switched technologies for the support of voice calls
NOTE: The SCN may be a public network or a private network.
TIPHON compliant: entity that complies with the mandatory requirements identified in the TIPHON requirements
documents together with compliance to the parts of the TIPHON specifications in which these requirements are
embodied
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
EMP Extended Megaco Package
GK GateKeeper
ICF InterConnect Function
IP Internet Protocol
MC Media Control
MB MiddleBox
QoS Quality of Service
RAS Registration Admission and Status
RSVP Resource reseVation Set-up Protocol
RTCP RealTime Conferencing Protocol
RTP RealTime transfer Protocol
SCN Switched Circuit Networks
SDL Specification and Description Language
TOS Type Of Service
TRM Transport Resource Manager
4 Scope of the H.248 ICF profile
The present document describes a profile of H.248 that mandates certain optional parts of the protocol and does not
mandate certain other options. Here the H.248 protocol is used to convey only flow properties to edge devices (ICFs) in
the transport plane. Used solely for this purpose, H.248/MEGACO, reduces to a small sub-set of the full protocol.
ETSI
9 ETSI TS 102 108 V4.1.1 (2002-06)
4.1 Use of the H.248 ICF profile

Controller
TRM
Reference Point I3
Middlebox
ICF
NOTE: This profile of H.248/MEGACO is used to control Middlebox devices in the transport plane. For the
purposes of the present document a Middlebox is defined as a physical implementation of an InterConnect
Function (ICF) TS 101 314 [3] and TS 101 329-3 [7]. A controller is defined as an implementation of
control functionality. The control relationship between a Middlebox and its controller is shown in figure 1b.

Figure 1b: Entities involved in Control over the I3 Reference point
4.2 Functionality supported by the Profile
The I3 reference point controls the ICF functions in a transport domain and will be under the control of the operator or
administrator of that domain. Instructions from the TRM (here the controller) to the ICF will relate to admission control
in the case of firewalls, network addresses in the case of Address Translators or control signals for QoS mechanisms
such as RSVP or DiffSDerv.
4.3 Service capabilities supported
TIPHON Release 4 service capabilities supported by the profile are basic bearer and QoS bearer set-up.
4.4 General note on compliance
Any options in the H.248 protocol not mentioned in the present document MAY be supported by the Middlebox or
controller, however are outside the scope of the present document.
4.5 Error handling
General use of the error codes can be found in clause A.2.
If an H.248 information element is received (descriptor or parameter), which is not specified in this profile, the receiver
shall ignore the information element and act as if the information element were not received.
If an unknown H.248 command or an information element not specified in this profile is received, the receiver shall
ignore the command and send an appropriate error (443 - unsupported or unknown command or 444 - unsupported or
unknown descriptor, 445 - unsupported or unknown property, 446 - unsupported or unknown parameter).
If an H.248 command with a mandatory information element missing is received, the receiver shall act as if the
information element was received carrying the default values, or reject with the appropriate error message if there is no
default value specified in the H.248 standard.
ETSI
10 ETSI TS 102 108 V4.1.1 (2002-06)
If an H.248 information element is received with syntactically invalid contents the receiver shall:
• if the information element is optional, ignore the information element; or
• if the information element is mandatory, act as if the information element was received correctly coded carrying
the default values and reject/fail if there is no default value specified in the standard.
If an H.248 information element is received with a value not allowed within the context of the present document, the
receiver shall:
• if the information element is optional, pass on, but otherwise ignore the information element; or
• if the information element is mandatory reject/fail.
NOTE: The security policy of an operator's network or the security policy implemented in a network element may
override the error handling as described above.
4.6 Security
Security issues associated with the use of this profile are outside the scope of the present document. It is intended that
they will be included in future releases of the present document.
5 Setting up of the controller-middlebox control
interface
Clause 11 of ITU-T Recommendation H.248 [1] shall apply without restrictions. This may change in future releases of
the present document.
6 Use of the profile for the establishment of transport
flows
The basic messages of H.248 used in this profile are here defined as well as certain H.248 packages. This clause
describes the messages used in the profile.
6.1 Process used
This clause provides the mapping of the flows in TS 101 882 [2] annex D, to H248 message flows. The parameter and
error reason definitions in TS 101 882 [2] annex D are aligned to ensure interoperability of these values across the
mappings of these reference points. In general each of the primitives defined on the T/I reference points in
TS 101 882 [2] each map to one or more commands in H.248. General note on source filtering used in the scenarios
SDP (see RFC 2327 [4]) specifies in clause B.2.1 a means for specifying unicast sessions. This provides the means to
encode the originator MpoA. In clause B.2 it is shown how the recvonly and send only attribute are used for specifying
the sender side behaviour of media flows.
ETSI
11 ETSI TS 102 108 V4.1.1 (2002-06)
6.2 Packages supported
The following packages shall be supported in this profile:
• Generic package (ITU-T Recommendation H.248 [1], clause E.1)
• Base Root package (ITU-T Recommendation H.248 [1], clause E.2)
• Network package (ITU-T Recommendation H.248 [1], clause E.11)
• EMP package TS 101 332 [5]
• If RTP statistics are to be supported, the RTP package (ITU-T Recommendation H.248 [1], clause E.12)
6.3 Required H.248/MEGACO messages and parameters
Annex A describes the codepoint mapping between H.248/MEGACO and the TIPHON meta-protocol TS 101 882 [2].
From this mapping follows that the following elements from H.248/MEGACO are to be supported.
6.3.1 Messages
• TransactionRequest.Add
• TransactionReply.Add
• TransactionRequest.Modify
• TransactionReply.Modify
• TransactionRequest.Subtract
• TransactionReply.Subtract
6.3.2 Parameters
• ContextId
• LocalDescriptor
• RemoteDescriptor
• TerminationID
6.3.3 Error values
• 411 – The transaction refers to an unknown ContextId
• 412 – No ContextIDs available
• 430 – Unknown TerminationID
• 432 – Out of TerminationIDs or No TerminationID available
• 432 – Put of terminationIDs or no terminationID available
• 433 – Termination ID is already in a contect
• 444 – Unsupported or unknown descriptor
• 510 – Insufficient resources
• 526 – Insufficient bandwidth
ETSI
12 ETSI TS 102 108 V4.1.1 (2002-06)
6.3.4 General notes on option use in H.248
The TIPHON semantics require that when multiple alternatives are returned by the Middlebox to the controller for a
termination the Middlebox shall support whichever one the controller chooses. Failure to support parameters for a
termination offered earlier is considered a fault.
H.248 does not have semantics as strict as those prescribed by TIPHON. To align the semantics, ReserveGroup needs
to be set for all alternative transport flow descriptions that are requested from the Middlebox and that ReserveValue
needs to be set for all request where the Middlebox is given the choice to provide flow descriptions.
The optional ModemDescriptor, MuxDescriptor. EventsDescriptor, DigitMapDescriptor, AuditDescriptor are not used
in this profile.
A transaction level timer shall be provided.
The flows in TS 101 882 [2] use a InvokingControllerReference, is mapped to StreamID in H.248.
The contextID is a value that is local to the Middlebox-controller relationship and is not mapped to the meta protocol.
The TIPHON type trReservedTransportReference and trEstablishedTransportReference shall be mapped to the
H.248 TerminationID.
Code point mapping for the Local and Remote Descriptors is provided in the annexes.
6.4 Default transport setup procedure
The transport plane allows reservation and allocation of resources for transport of a packet stream (e.g. to reserve
processing capability in routers and on links between them). See TS 101 882 [2] for a full definition of the primitives
involved .
NOTE: The following text is derived from the SDL in TS 101 882 [2]. Should there be discrepancies between
TS 101 882 [2] and the present document, the text in TS 101 882 [2] shall take precedent.
The transport element shall establish the transport resources required to support the transport flows required. If so
required, the transport elements shall establish a QoS controlled transport capability in accordance with the QoS
parameters identified.
Step TS 101 882 [2] Primitive meaning
MC layer decides it needs transport

TransportReservationRequest
1 asks the ICF/TRM to support it with a QoS-enabled transport stream and
wants to know what parameters it can support there.
2 TransportReservationConfirm the ICF/TRM acknowledges to the MC, providing the possible bearer
characteristics for the MC to decide upon. The MC-entity hereby commits
to provide the flows as identified in this message.
The MC answers to BC….
3 TransportEstablishementRequest the MC informs the ICF/TRM of the choice.
4 TransportEstablishmentConfirm the ICF/TRM acknowledges the establishment of the transport flows.
5 TransportReleaseRequest The ICF/TRM is requested to release the transport flows.
6 TransportReleaseConfirm The ICF/TRM confirms the release of the transport flows.

ETSI
13 ETSI TS 102 108 V4.1.1 (2002-06)
6.5 Example flows for the use of this profile
Annexes C and D provide examples of the use of this profile for firewall control. The Middlebox can operate in several
scenarios, these scenarios describe how the generic service offered over the T2 and I3 reference points can be used to
achieve certain specific goals.
Annex C describes the following examples:
• C.1 Basic scenario;
• C.2 Basic scenario with address translation (the legacy mode);
• C.3 With address translation and with source delivery;
• C.4 Without address translation and with source filtering;
• C.5 With address translation and source filtering (the preferred TIPHON media mode);
• C.6 Explicit RTCP addressing;
• C.7 Signalling: Example flow for a H323 RAS control pin-hole.
Clause D.1 explains the option to mute the forward transport path until the call has been established.
6.6 QoS flows
The TIPHON semantics demand that a Middlebox provides QoS when the QoS parameters (maximum packet size,
packet rate, delay budget, packet delay variation, packet loss) are set. The H.248 binary encoding supports the QoS
parameters to be conveyed. Clause B.4 addresses the text encoding for this.
6.6.1 QoS on flows through the middlebox
If the QoS parameters (maximum packet size, packet rate, delay budget, packet delay variation, packet loss) are
specified on the LocalDescriptors the middlebox is required to treat the incoming flow in accordance with the QoS
parameters given.
6.6.1.1 QoS policing of incoming flows
If the MiddleBox (MB) is to police the rate of incoming packet flows. The Extended Megaco Package (EMP) value
tokenrate shall be set to the meta-protocol value packetRate. If this value is set the middlebox shall exhibit the
behaviour as specified by TS 101 332 [5], clause 4.1.2.
6.6.2 QoS on outgoing flows
Establishment of QoS on outgoing flows is (unfortunately) technology dependent.
6.6.2.1 ToS tagging of outgoing flows
If the middlebox supports this option, the controller shall set the ToS value as per clause B.3.1 on the RemoteDescriptor
of the flow. The middlebox shall set this value on each of the outgoing packets of the flow.
6.6.2.2 RSVP
The RSVP flowspec values shall be derived from the QoS parameters (maximum packet size, packet rate, delay budget,
packet delay variation, packet loss) when these values are specified on the RemoteDescriptors. The mapping between
the TIPHON QoS values and the RSVP flowsspec shall be done in accordance with the RSVP specification
(see RFC 2205 [6]).
ETSI
14 ETSI TS 102 108 V4.1.1 (2002-06)
6.7 ToS filtering on incoming flows
If the middlebox supports this option, the controller shall set the ToS value as per clause B.3.1 on the LocalDescriptor
of the flow. The middlebox shall match the packets against this value.
7 Management operations
TIPHON release 3 does not prescribe any management operations on Middlebox. Behaviour regarding ServiceChange
and Restart shall therefore be as specified by ITU-T Recommendation H.248 [1].
ETSI
15 ETSI TS 102 108 V4.1.1 (2002-06)
Annex A (normative):
Mapping with meta-protocol
A.1 Code point mapping
This clause describes a generic mapping that is generally used for all primitives and parameters.
A.1.1 Primitive mappings
TIPHON primitives H.248 message types
TransportReservationRequest TransactionRequest.Add
TransportReservationConfirm TransactionReply.Add
TransportEstablishmentRequest TransactionRequest.Modify
TransportEstablishmentConfirm TransactionReply.Modify
TransportReleaseRequest TransactionRequest.Subtract
TransportReleaseConfirm TransactionReply.Subtract
TIPHON primitives with data elements H.248 data elements
TransportReservationRequest TransactionRequest.Add
TransportHandleType (requested handle) ContextId (see note 3)
SET OF TransportDescriptorType (rx) LocalDescriptor
SET OF TransportDescriptorType (tx) RemoteDescriptor
TransportReservationConfirm TransactionReply.Add
TransportHandleType (requested handle) ContextId (see note 3)
See table of error messages
TransportStatusType
SET OF TransportDescriptorWithHandle LocalDescriptor, RemoteDescriptor
TransportEstablishmentRequest TransactionRequest.Modify
TransportHandleType (reserved handle) ContextId (see note 3)
TransportEstablishmentConfirm TransactionReply.Modify
TransportHandleType (reserved handle) ContextId (see note 3)
TransportStatusType See table of error messages
TransportHandleType (established handle) TerminationID
TransportReleaseRequest TransactionRequest.Subtract
TransportHandleType (established handle) TerminationID
TransportReleaseConfirm TransactionReply.Subtract
TransportHandleType (established handle) TerminationID
TransportStatusType See table of error messages

ETSI
16 ETSI TS 102 108 V4.1.1 (2002-06)
A.1.2 Binary encoding
A.1.2.1 For an IP-based transport flow
TIPHON data elements H.248 data elements
TransportDescriptorWithHandle
TransportHandleType ContextId (see note 3)
TransportDescriptorType (rx) LocalDescriptor
TransportDescriptorType (tx) RemoteDescriptor
TransportStatusType See table of error messages
TransportHandleType TerminationID
TransportDescriptorType
GenericQoSDescriptorType
SpecificQoSDescriptorType
MpoAType (originator)
MpoAType (destination)
GenericQoSDescriptorType
delay budget PropDelay
Packet rate Bitrate (shall be computed as follows:
packetRate*MaximumPacketSize/100)
MaximumPacketSize
Packet delay variation (jitter in milliseconds) Jitterbuffer
packet loss the Middlebox shall support an adequately low
number
IPv4Type
Address IPv6
Protocol PortType (value =1 (UDP), RTP is implied)
Port Port
IPv6Type
Address IPv4
Protocol PortType (value = 1 (UDP), RTP is implied)
Port Port
MpoAType
iPv4 Clause C.6, tag value 6001
IPv6 Clause C.6, tag value 6002
MpoAProtocolType
ENUMERATED (list from STD02) See above

A.1.3 Text encoding
A.1.3.1 For an IP-based transport flow
TIPHON data elements H.248 data elements
TransportDescriptorWithHandle
TransportHandleType ContextId (see note 3)
TransportDescriptorType (rx) LocalDescriptor (for the contents see annex D)
TransportDescriptorType (tx) RemoteDescriptor (for the contents see annex D)
See table of error messages
TransportStatusType
TransportHandleType TerminationID

ETSI
17 ETSI TS 102 108 V4.1.1 (2002-06)
A.2 Error reasons
The following table provides a list of H.248 error reasons that a Middlebox shall use and their corresponding TIPHON
meanings.
TIPHON reason TIPHON diagnostic H.248 error reason
RequestedHandle invalid 444 – Unsupported or unknown descriptor

RequestedHandle unavailable CODEC unavailable 510 – Insufficient resources
QoS not available 526 – Insufficient bandwidth
RequestedHandle does not exist 411 – The transaction refers to an unknown
ContextId
Insufficient resources no more bearers 412 – No ContextIDs available
no more transport flows 432 – Out of TerminationIDs or No TerminationID
available
TransportHandle does not exist 430 – Unknown TerminationID
TransportHandle invalid 433 – Termination ID is already in a contect
TransportHandle unavailable
432 – Put of terminationIDs or no terminationID
available
Please note that TIPHON reference point T and I reject primitives usually pertain to a TransportReference within a
InvokingControllerReference. H.248 error codes are uses as normal commands and hence apply to a particular stream
or termination and hence carry the context ID and termination ID to which the error message pertains.
ETSI
18 ETSI TS 102 108 V4.1.1 (2002-06)
Annex B (normative):
Meta-protocol to SDP mapping
SDP (see RFC 2327 [4]) is a description language for transport sessions. This mapping therefore has no states just the
codepoints.
NOTE: Not all of these code points are used in this profile, e.g. all CODEC related parameters. These have been
retained here however for completeness.
B.1 Mappable fields
The Protocol Version field (v = line) shall contain 0 as per page 8 of RFC 2327 [4].
The Origin field (o = line) shall be filled according to page 8 of RFC 2327 [4].
The Session Field (s = line) shall be filled according to page 9 of RFC 2327 [4].
The connection Field (c = line) shall contain the address value of the destinationMpoA in TS 101 882 [2].
• In the case of IPv4 and IPv6 addresses this shall take the form as prescribed on page 33 of RFC 2327 [4].
• Other cases are undefined in RFC 2327 [4] and may be extended in future versions of either RFC 2327 [4] or the
present document.
The Bandwidth field (b = line) shall contain the value of maxPacketSize times packetRate divided by 8 AS
shall be used as the bandwidth modifier.
The time filed (t = line) shall be filled according to page 14 of RFC 2327 [4]
The Transport field (m = line) shall be filled as follows:
• shall contain the type of transport flow. For Release 3 this shall be audio for audio flows and
control for signalling flows.
• shall contain port value of the destinationMpoA in TS 101 882 [2].
• shall contain the text RTP/AVP if RTCP flows are to be created by the middlebox and UDP for
media without RTCP.
• shall be ignored by the middlebox.
Following attributes shall be used:
• a=rtpmap:
is identical to the value in
shall be ignored by the middlebox
equals the meta protocol values packetRate * framesPerPacket for this transport
flow
is filled per page 21 of RFC 2327
• a=ptime: shall contain the meta protocol value of framesPerPacket
• a=fmtp:
is identical to the value in
ETSI
19 ETSI TS 102 108 V4.1.1 (2002-06)
shall contain the value of the meta protocol field
codecSpecificParameters
B.2 Specifying the OriginatorMpoA
SDP specifies in page 23 of RFC 2327 [4] a means for specifying unicast sessions. This provides the means to encode
the
Originator MpoA. The recvonly and send only attribute are specifying the sender side behaviour of this message.
• The receive-only stream specifies the IP address and port where RTP should be sent to. Implicitly (port + 1) is
the port where the RTCP should be sent to.
• The send-only stream specifies the IP address and port where RTP will be sent from. Implicitly (port + 1) is the
port where the RTCP will be sent from.
EXAMPLE:
m=audio 1110 RTP/AVP 0
c=IN IP4 1.1.1.1
a=recvonly
m=audio 2220 RTP/AVP 0
c=IN IP4 2.2.2.2
a=sendonly
The sender of this SDP specifies that it wants to receive RTP packets on 1.1.1.1:1110 and send RTCP packets from
1.1.1.1:1111. It will send RTP packets from 2.2.2.2:2220 and receive RTCP packets on 2.2.2.2:2221.
NOTE: These semantics are compatible with current use of SDP. In the example above this leads to a scenario
where a multihomed host receives RTP on 1.1.1.1 and sends the RTCP feedback on the stream from
2.2.2.2. The feedback on RTP that is sent from 2.2.2.2 will be received on 1.1.1.1. A more logical
semantics would be that the RTCP is sent from (port in recvonly + 1) and received on
(port in sendonly + 1). This way the RTP and related RTCP stream are neatly tied together.
B.3 Specifying QoS mechanism specific values
B.3.1 DiffServ Type of Service (ToS) value
When DiffServ is used its ToS value is provided in the meta-protocol value specificQoSDescriptor. It shall be encoded
in SDP as follows:
a=X-ToS:
NOTE: ToS is only valid for the vertical interfaces. This shall not be forgotten when this text is re-used for the
upcoming general SDP profile deliverable.
B.3.2 RSVP
The RSVP flowspec values shall be derived from the SDP transport parameters in accordance with the RSVP
specification (see RFC 2205 [6]).
ETSI
20 ETSI TS 102 108 V4.1.1 (2002-06)
B.4 Unmappable fields
At this time SDP has no provisions for the following meta-protocol values:
• DelayBudget,
• packetDelayVariation,
• packetLoss.
TIPHON intends to address all SDP related QoS issues and will register a coherent set of code points in SDP with
IANA for these values.
ETSI
21 ETSI TS 102 108 V4.1.1 (2002-06)
Annex C (informative):
TIPHON template usage scenarios
This clause provides template TIPHON messages for the profile on reference point I3.
The Middlebox can operate in several scenarios, these scenarios describe how the generic service offered over the T2
and I3 reference points can be used to achieve certain specific goals. The present document describes the following
examples:
• C.1 Basic scenario.
• C.2 Basic scenario with address translation (the legacy mode).
• C.3 With address translation and with source delivery.
• C.4 Without address translation and with source filtering.
• C.5 With address translation and source filtering (the preferred TIPHON media mode).
• C.6 Explicit RTCP addressing.
• C.7 Signalling: Example flow for a H323 RAS control pin-hole.
C.1 Basic flow without address translation without source
filtering
A
B
*
4.4.4.4:3300
4.4.4.4:3300 *
1.1.1.1:1124
*
* 1.1.1.1:1124
H248Context
Figure C.1: Example H.248 context
Each termination sinks/sources one bi-directional stream with each a LocalDescriptor, RemoteDescriptor and a
LocalControlDescriptor. The StreamIds are used to link the streams that are connected.
The following table provides the addresses and ports used in this figure:
Stream StreamId Address in LocalDescr Entering the Addresses in RemoteDescr Leaving the
middlebox middlebox.
Source =* Source = *
A to B 1
Sink = 4.4.4.4:3300 Sink = 4.4.4.4:3300
Source = * Source = *
B to A 1
Sink = 1.1.1.1:1124 Sink = 1.1.1.1:1124

The exchange above maps to the following H.248-EMP message flow.
ETSI
22 ETSI TS 102 108 V4.1.1 (2002-06)
Middlebox
Controller
TransactionRequest (add)
TransactionReply (add)
1) ControllerMiddlebox:
The controller must provide the Middlebox with enough information to a create sending and a receiving transport flow.
MEGACO/1 [Controller IP Address]:55555
Transaction = 1{
Context = ${
Add = ${
TerminationState{
EMP/iface=0 -– the A-side
}
Media{Stream = 1{
Remote{
v=0
m= audio 1124 RTP/AVP 0
c=IN IP4 1.1.1.1
}
} /*of Stream*/
} /*of Media*/
} /*of ADD*/
Add = ${
TerminationState{
EMP/iface=1 -– the B-side
}
Media{Stream = 1{
Local{
v=0
m=audio 1124 RTP/AVP 0
c=IN IP4 1.1.1.1
}
} /*of Strea
...