One document matched: draft-vandenameele-tiphon-arch-gway-decomp-00.txt
Internet Engineering Task Force Jozef Vandenameele
INTERNET DRAFT Chair ETSI-TIPHON WG 2
draft-vandenameele-tiphon-arch-gway-decomp-00.txt
November 1998
Expires in six months
Requirements for the Reference Point ('N') between
Media Gateway Controller and Media Gateway
Status of this document
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This Internet-Draft contains those excerpts of ETSI-TIPHON's work
that focus on the reference point between Media Gateway Controller
and Media Gateway (reference point "N" in TIPHON parlance).
ETSI-TIPHON is working on standards to connect VoIP (Voice over IP)
networks and phone networks.
PLEASE NOTE THAT THIS INPUT FROM TIPHON IS WORK IN PROGRESS. IT HAS
BEEN APPROVED NEITHER ON THE TIPHON WORKING GROUP 2 LEVEL, NOR ON
THE TIPHON PROJECT LEVEL. However, as input is always welcome, we
are herewith submitting the current status of the discussion within
TIPHON to the IETF.
TABLE OF CONTENTS
1. Introduction
2. Definitions
3. Reference Configuration
3.1 Reference Configuration Overview
3.2 Reference Configuration Details
4. Functional Blocks
4.1 Media Gateway
4.2 Media Gateway Controller
5. Requirements for Reference Point (N) between
Media Gateway Controller and Media Gateway
5.1 Introduction
5.2 Scope of Media Gateway Control
5.2.1 Connection Control
5.2.2 Media Stream Transformations
5.2.3 Content Insertion
5.2.4 Event Catching
5.3 Other Requirements
5.3.1 Modularity and Extensibility
5.3.2 Resource Management
5.3.3 Control Session Management
5.3.4 Control Session Security
6. References
7. Acknowledgments
8. Contact Address
1 INTRODUCTION
ETSI-TIPHON [1a] is working on standards to connect VoIP (Voice over
IP) networks and phone networks. Of its six working groups, working
group 2 (WG2), is on architecture and reference configurations. One
of WG2's documents is, in ETSI parlance, Technical Specification
DTS/TIPHON-02002 [1b]. It defines the network architecture, system
architecture, and the reference configurations which are necessary
for the delivery of telephone calls which originate in
- an IP network and are delivered to Switched Circuit Networks (SCN),
such as Public Switched Telephone Network (PSTN), Integrated Services
Digital Networks (ISDN) and Global System for Mobile communication
(GSM) networks (so-called TIPHON Scenario 1),
- an SCN and are delivered in an IP network (TIPHON Scenario 2),
- an SCN and are delivered to an SCN via an IP transit network
(TIPHON Scenario 3).
This Internet-Draft contains those excerpts of DTS/TIPHON-02002
Version V0.3.1 (status 30 October 1998) that focus on the reference
point between Media Gateway Controller and Media Gateway (reference
point "N" in TIPHON parlance).
PLEASE NOTE THAT THIS INPUT FROM TIPHON IS WORK IN PROGRESS. IT HAS
BEEN APPROVED NEITHER ON THE TIPHON WORKING GROUP 2 LEVEL, NOR ON
THE TIPHON PROJECT LEVEL. However, as input is always welcome, we
are herewith submitting the current status of the discussion within
TIPHON to the IETF.
ETSI-TIPHON and ITU Study Group 16 are actively cooperating on the
the gateway decomposition [1c], and ETSI-TIPHON whishes for active
collaboration with the relevant IETF working group(s) as well.
2 DEFINITIONS
- Media gateway: provides the media mapping and / or transcoding
functions
- Media gateway controller: controls the Media Gateways
- Signalling gateway: provides the signalling mediation function
between the IP domain and the SCN domain
- gatekeeper : An H.323 entity on the IP network which provides
address translation and controls access to the network for terminals,
gateways, and MCUs. The gatekeeper may also provide other services to
terminals, gateways and MCUs, such as bandwidth management and
gateway location.
- gateway: A gateway is an endpoint on a network which provides for
real-time, two-way communication between terminals on an IP based
network and other terminals on switched circuit network.
- terminal: An H.323 terminal (see [2]), other than a gateway or a
multipoint control unit.
3 REFERENCE CONFIGURATION
This clause gives reference configurations that shall apply for the
interworking function (IWF) to ensure service interoperability for
TIPHON phase 2 systems.
3.1 Reference configuration overview
The reference configuration shall consist of following entities:
- terminal connected to the IP network;
- IP access (e.g. Public Switched Telephone Network (PSTN),
Integrated Services Digital Network (ISDN), x Digital Subscriber
Line (xDSL));
- IP network;
- gateway
- Media Gateway Controller
- Media Gateway
- Signalling Gateway;
- gatekeeper;
- an SCN;
- a terminal connected to an SCN network;
- back-end services;
+--------+ D +--------+ G +--------+
| GK |------| GK |------|Back End|
+--------+ +--------+ +--------+
| | /
A | C | ___F___/
| . . . . . . ./. . . . . . . .
+--------+ . +--------+ J +--------+ . E.b
|H323 Ter|------| MGC |------| SG |------
+--------+ . +--------+ +--------+ .
\____B_. | .
.\ N | .
. \ | .
. +--------+ . E.a
. | MG |-----------------.----
. +--------+ .
. . . . . . . . . . . . . . .
Figure 1: Basic call reference configuration
(MGC = Media Gateway Controller, MG = Media Gateway,
SG = Signalling Gateway)
NOTE 1: This diagram does not represent a network topology. For
example, a gatekeeper that communicates with both a terminal and a
gateway is using reference points A and C.
Whilst figure 1 contains two gatekeepers (in order to show the
reference point between two gatekeepers), a particular TIPHON system
may contain one or more gatekeepers. However, it appears to each
terminal that it communicates with as a single gatekeeper, and
similarly for the gateway. Different gatekeepers may be responsible
for different administrative domains, or for different parts of a
single administrative domain (i.e. one administrative domain may
contain multiple gatekeepers).
The architectural model of the gateway is split in three functional
components: the Signalling Gateway (SG), the Media Gateway (MG) and
the Media Gateway Controller (MGC).
3.2 Reference configuration details
The interoperability between SCN and IP networks for voice services
shall have minimal impact on those networks.
The lines in the reference configuration diagram represent network
connections between the elements. Dedicated or non-dedicated, long-
lived or on-demand connections may be used.
3.2.3 Gatekeeper
The gatekeeper is the element in the network that shall be
responsible for the Registration, Admission, and Status (RAS) of
terminals and gateways. The gatekeeper shall participate in zone
management, call processing and call signalling.
3.2.4 Gateway
A gateway shall be physically connected to one or more IP networks
and to one or more SCN networks. A gateway is composed of
- Signalling Gateway
- Media Gateway
- Media Gateway Controller
These different functions can be co-located with either a gatekeeper,
a gateway or both.
3.2.4.1. Signalling Gateway
The Signalling Gateway provides the signalling mediation function
between the IP domain and the SCN domain. It may support functional
or signalling mediation between the IP domain (e.g. H.323) and call
signalling in the SCN domain (e.g. channel associated signalling,
non - channel associated signalling, ...).
3.2.4.2. Media Gateway
The Media Gateway provides the media mapping and / or transcoding
functions. It maps (e.g. tandemfree operation) or transcodes the
media in the IP domain (e.g. media transported over RTP/UDP/IP) and
media in the SCN domain (e.g. PCM encoded voice, GSM, etc.).
3.2.4.3. Media Gateway Controller
The Media Gateway Controller sits between the Media Gateway, the
Signalling Gateway and the Gatekeeper. It provides the call
processing (call handling) function for the Gateway. It controls the
Media Gateways; it receives SCN signalling information from the
Signalling Gateway and IP signalling from the Gatekeeper.
3.2.5 Back-end services
Back End Services may be used by gateways and gatekeepers to provide
functions (e.g. authentication function, billing and rating/
tariffing, or address resolution function, etc.). These back-end
services may be provided by equipment within the SCN, within the
IP Network, or elsewhere.
4 FUNCTIONAL BLOCKS
Three main functional blocks are identified within the IP domain:
terminals, gateways, and gatekeepers. This section identifies
functions within the media gateway and the media gateway controller
only.
The gateway Functional Block ensures the interworking between the IP
domain and the SCN domain. It is composed of three separate
Functional Blocks:
- the Signalling Gateway (not discussed in this Internet-Draft)
- the Media Gateway
- the Media Gateway Controller
4.1. Media Gateway
- Media channel address resolution function - provides IP transport
addresses for media reception and transmission;
- Stream conditioning function - transfers the media streams between
the IP domain and the SCN domain, including (e.g.) transcoding and
echo cancellation;
- Codec translation function - routes the media streams between the
IP domain and the PSTN/ISDN/GSM domain
- Media channel privacy - ensures media privacy to and from the GW;
- Circuit Network Media Termination - This includes all lower-layer
circuit network hardware and protocols, including the method by which
speech is placed on the wire, e.g. PCM A-law, PCM Mu-law, etc.
- Packet Media Termination - This includes all protocols involved in
putting media over the packet network, including the codecs used.
For H.323 this includes RTP/RTCP as described in H.225.0, and also
the coders such as G.711, G.723.1. etc.
- SCN Circuit Interface: terminates the bearer channel (e.g. DS0)
from the SCN and makes it available to the Media Processing
functions.
- Packet / Circuit Media Processing Function - converts between
audio, fax or data bearer channels on the SCN side and data packets
(e.g. RTP/UDP/IP, or ATM) on the packet network side. This also
performs associated signal processing functions such as voice
compression, network echo-cancellation, silence suppression, comfort
noise generation, encryption, fax conversion, and analog modem
conversion (for passing analog modem signals "transparently" through
the packet network). In addition, this function performs the
conversion between DTMF tones on the SCN side and the appropriate
signals on the packet network side when the speech codec is not
transparent to DTMF. The SCN/Packet Media Processing function may
also collect the packet traffic and quality data experienced by each
call for use in call detail reporting and call control.
- NAS Media Processing and Control Function: provides the
functionality of an IP Remote Access Server and terminates PPP,
RADIUS, etc. stacks used for transport and management of the dial-up
data channel. This function, if present, always resides in the Media
Gateway.
- Service Circuit Function: provides services such as playing
announcements and tones towards either the SCN or packet network.
This function may also provide capabilities to collect and generate
DTMF digits, perform voice recognition, etc. The Service Circuit
function resources again are managed from within the Media Gateway
and may be requested by more than one Call Control function or other
external system (e.g., SCP). Some or all of these functions may be
provided by an external entity in which case this function may be
optional.
- Usage recording function - determines and/or records signalling
and/or media reception and transmission.
- Usage reporting function - reports to an external entity the
determined and/or recorded usage.
- OAM&P: Operations, administration, maintenance, and provisioning
information that is not directly needed for call control can be
passed through a logically separate interface to an element
management system. This operations interface is beyond the scope of
this paper.
- Management function - interfaces to the network management system
- Packet Network Interface: terminates packet network.
4.2. Media Gateway Controller
- GW H.225 function - receives and emits H.225 messages (see [4]);
- GW H.245 function - receives and emits H.245 messages (see [3]);
- Authentication function - establishes the identity of the user,
device, or network entity (see [5]);
- GW media stream admission control function - allows or disallows
media streaming;
- Non-repudiation evidence gathering - collects information to be
used to prove that a certain signalling or media was transmitted or
received;
- Packet Signaling - This includes all "call like" signaling that
might exist on the packet network and is carried out by an endpoint
on such a network. For H.323, this includes H.225.0 Q.931-like call
signaling, H.225.0 RAS, and H.245. For an H.323 receive-only
endpoint, this includesH.225.0 RAS, but not H.245.
- Packet Network Signaling Interface: terminates the packet network
signaling protocol (e.g., H.323, UNI, PNNI, etc.) It maintains only
enough call state information to manage the protocol interface.
Strictly speaking, the Packet Network Signaling Interface that exists
in the Gateway Controller has no direct interface to the Media
Gateway as all information passes from it to the Media Gateway via
the Call Control Function. In general this function will reside in
the Gateway controller.
- Gateway Control - This includes all connection control logic,
resource management, and protocol translation (e.g. SS7 to H.225.0)
that might take place.
- Remote Resource Monitoring: maintains the Gateway Controller's view
of network-level resources available for calls or NAS termination.
These include such things as Media Gateway trunk utilization and
availability, IP network bandwidth and utilisation, etc. useful for
making call routing decisions.
- Call Control Function: maintains the Gateway call state. The Call
Control function contains all connection control logic of the
Gateway. The Call Control function may interface with backend
services, which may include IN services (SCP or SSP).
Note: This function may perform call routing, authorisation,
authentication, quality of service selection, billing data and per-
call information recording and resource identification functions.
It communicates bearer trunk circuit termination (DS0 channel) and
data network addressing, security and configuration information
(voice coder, echo cancellation parameters, encryption tokens, etc.)
to the Media Gateway.
- Media Gateway Resource Management - allocates internal resources
within the media gateway.
- Signalling mediation function maps between signalling in the IP
domain (e.g. H.323) and signalling in the SCN domain, in co-operation
with the SG.
- Usage recording function - determines and/or records signalling
and/or media reception and transmission
- Usage reporting function - reports to an external entity the
determined and/or recorded usage.
- OAM&P: Operations, administration, maintenance, and provisioning
information that is not directly needed for call control can be
passed through a logically separate interface to an element
management system. This operations interface is beyond the scope of
this paper.
- Management function - interfaces to the network management system
- Packet Network Interface: terminates packet network.
5 REQUIREMENTS FOR REFERENCE POINT ("N") BETWEEN MEDIA GATEWAY
CONTROLLER AND MEDIA GATEWAY
5.1. Introduction
Reference Point N designates the information flows required for
control of a Media Gateway in a decomposed H.323 Gateway.
NOTE: There is a strong causal relationship between H.245
signalling and information flow over reference point N. The
detailed content required in Media Gateway control messages in a
decomposed H.323 Gateway derives in large part from the potential
content of the associated H.245 signalling.
5.2. Scope of Media Gateway Control
Media Gateway control consists of four functions:
1. Creation, modification, and deletion of media stream connections
across the Media Gateway.
2. Specification of the transformations to be applied to media
streams as they pass through the Media Gateway, both initially as
connections are created and subsequently during the life of the
connection.
3. Requests to the Media Gateway to insert content (tones and
announcements) into media streams, either on direct orders from
the controller or beginning and ending with the detection of
specified events within the Media Gateway itself.
4. Requests to the Media Gateway to report and possibly to take
specified actions upon detection of specified events within the
media streams.
5.2.1 Connection Control
In keeping with the capabilities of H.245, connection control shall
be able to provide at least the following types of connection:
- circuit to packet (IP)
- circuit to packet (ATM - H.323 Annex C operation)
- circuit to circuit (circuit side fallback)
The connection mode may be unicast or multicast, or a connection may
be inactive. Typically connections are specified unidirectionally,
but may be specified in both directions at once. On internet
connections, both IPv4 and IPv6 are supported.
H.245 contains parameters which must be passed on to the transport
network to select transport QoS. H.245 sets up both an RTP and an
optional RTCP connection in each direction.
On the circuit side, SS7 requires the ability to perform a loopback
for continuity testing. This requirement applies especially to
loopback through a circuit at the edge of the Media Gateway (path 1
in Figure 2), but as Figure 2 shows, four different types of loopback
are possible.
SCN Packet
+========================+
| |
---------------------------------------\
| |
path 2 <--------------------------------------/
| |
. . | . . . . . . . . . . . . . . . . . .
. | |
. . | . . . . . . . . . . . .|. . . . . > path 4
| |
path 1 -------------\ . . . . . . . . . .
| . |
<------------/ . . . . . . . . . > path 3
| |
+========================+
Figure 2 - Possible Types Of Loopback
Abstracting from this, the Media Gateway control interface shall
support the following capabilities for connection control:
1) Ability to identify the IP, ATM, and/or circuit connection end-
points involved in a connection. On the packet side, end-point
descriptions shall reflect the content provided by networkAddress
portion of the H.245 NetworkAccessParameters type. On the circuit
side, it shall be possible to designate circuits using a
hierarchical naming construct.
It must be possible to wildcard the low-order portion of the
endpoint identifier (i.e. the port number for an IP transport
address or the low-order term of a circuit identifier), with the
intent that Media Gateway shall select an idle endpoint instance
and return its full identity to the controller. Wildcarding shall
also be provided to allow a simultaneous reference to multiple
endpoints.
2) Ability to request the selection of ports for both RTP and RTCP
reception on the packet side.
3) Ability to specify unicast or multicast propagation of the media
stream on the network side.
4) Ability to specify the QOS parameters applicable on the packet
side of a media stream connection.
5) Ability to monitor QOS statistics for an established connection,
or at least the accumulated statistics for each connection as it
is taken down.
6) Ability for the Media Gateway to autonomously report if the QOS on
a given connection has fallen below a specified value.
7) Ability to support circuit-to-circuit connections (the case of
circuit-side fallback when the packet side is congested).
8) Ability to support at least the circuit-side loopbacks needed for
SS7 continuity testing.
5.2.2 Media stream transformations
This section has to do with the "steady-state" characteristics of the
media streams. Again beginning with the packet side, H.245 specifies
the RTP payload type to be used for a given media stream. The Media
Gateway control protocol shall permit the payload type to be
transmitted onward to the Media Gateway. The Media Gateway control
protocol shall also allow the controller to pass explicit designation
of the codec, packetization interval, and jitter buffer size for each
media stream.
In some cases, it will be necessary to specify the coding information
on both sides of the connection. This will be true for a packet-to-
packet connection, and could happen if the coding on the circuit side
varies on a per-call basis (e.g. because bearer capacity varies
between 56kbs and 64kbs depending on which facilities the call has
passed through along the way).
In addition to RTP payload type, H.245 can specify whether silence
suppression is to be used. Moreover, the Media Gateway may be the
point at which encryption is applied because the subscriber has
requested confidentiality service across the packet network. For GSM
codecs, H.245 signals whether comfort noise is to be generated during
silent periods. On the packet side, echo cancellation may be applied
on a per-call basis. The Media Gateway control protocol shall be
able to pass all of this information on to the Media Gateway.
Typically much of this information must be specified at the same time
that the connection is created. The Media Gateway control protocol
shall allow for this possibility. However, it shall also be possible
to change media handling instructions for an already-existing
connection, in response, for instance, to an H.245
FlowControlCommand.
A final requirement relating to media processing is that the Media
Gateway control protocol shall support requests to initiate or
terminate lawful interception of the content of a specified media
stream.
5.2.3 Content Insertion
The requirement to play out one or more tones in a specified
direction (usually toward the circuit side) occurs for almost all
media stream connections. Occasionally it may be necessary to play
out a Media-Gateway-resident announcement. These actions are
triggered by call processing rather than H.245 signalling. The Media
Gateway control protocol shall support the ability to request the
playing of a specific tone or announcement at any point during the
life of a connection.
To reduce the messaging and other processing burden on the controller
and improve response times, it is highly desirable that the Media
Gateway control protocol go beyond requests to start and stop the
playing of specified announcements or tones, to support at a minimum
the specification of the conditions under which playout should stop.
For example, a prompting tone or announcement should stop when
incoming DTMF is detected, without the need to report that event to
the controller and receive another instruction stopping the playout.
This capability is a subset of the general requirement for the
controller to be able to program the Media Gateway to detect and
react to specific events associated with specific connections.
The Media Gateway control protocol shall also support the ability to
request muting of a media stream in a specified direction.
Finally, the Media Gateway control protocol shall support the ability
for the controller to request the Media Gateway to insert and detect
tones as required for SS7 continuity testing and other forms of
testing.
5.2.4 Event Catching
Even the narrowest definition of the scope of Media Gateway control
within the context of H.323 Gateway decomposition requires the
ability to instruct the Media Gateway to detect and act upon
specified events. As a specific example, once the call has been
established, the controller must tell the Media Gateway to begin
listening for DTMF on the circuit side, report any digits detected,
and remove the DTMF from the stream as it is passed to the packet
side. This is an example where H.245 signalling (userInputIndication
messages) will occur as a consequence of Media Gateway control
messages rather than the reverse. The Media Gateway control protocol
shall support this specific operation.
The complete Media Gateway control repertoire of events to be
detected and actions to be taken as a result is for further study.
The main difficulty is to distinguish between Media Gateway control
and circuit-side signalling (Reference Point J) requirements.
5.3 Other Requirements
As a general requirement, the Media Gateway control protocol shall
allow the Media Gateway to indicate to the controller whenever some
or all of a request cannot be executed. It shall be possible for the
Media Gateway to indicate the general nature of the problem and to
provide further details, possibly including proprietary content.
5.3.1 Modularity and Extensibility
It is essential that the protocol for Media Gateway control be both
modular and extensible. Many uses are envisioned for this protocol,
going beyond its implementation of an interface across Reference
Point N. To begin with, the protocol may also be used to implement
at least part of Reference Point J circuit-side signalling transport
interface, particularly where MF or R2 is being used. Beyond that,
it will probably be extended to handle Network Access Server (NAS)
operation, where circuits must be connected to modems either
unconditionally or upon detection of a modem tone. One further
example is possible use to control a line-terminating Media Gateway.
These are just three examples of potential extensions.
However, not all implementations may wish to support all of the
possible extensions. Thus the protocol shall be modular, permitting
light-weight implementations for specialised tasks where processing
resources are constrained. The protocol shall provide the means
whereby a controller can determine the capabilities supported by a
particular Media Gateway.
5.3.2 Resource Management
The Media Gateway control protocol shall provide the means for the
controller to determine resource availability within the Media
Gateway upon startup. Optionally, this capability may allow for
queries during regular operation. The means by which remaining
capacity is quantified is for further study.
It shall be possible for the Media Gateway to indicate to the
controller that it lacks sufficient resources to carry out a given
command.
It shall be possible for the controller to audit the commitment of
resources to connections, to ensure that all commitments are valid.
It shall further be possible for the controller to order that
specific resource assignments be cleared if it finds that they are
invalid.
It shall be possible for the Media Gateway to report changes in
operational status of significant resources from in-service to out-
of-service and vice versa. This is especially required for
transmission facilities terminating on the Media Gateway.
5.3.3 Control Session Management
The Media Gateway control protocol shall provide the means to start
up and take down a control session between a specific controller and
a specific Media Gateway. The ability for two controllers to make
requests to the same Media Gateway at the same time is NOT a
requirement. However, it shall be possible for a Media Gateway to
establish a control session with an alternate controller if its
primary controller becomes unavailable. It shall also be possible
for a Media Gateway to establish an inactive control session with a
standby controller. Control switchovers should occur without loss of
connections already made within the Media Gateway. Means should be
provided for the new controller to request a reset of all connections
if it is unable to recover the existing connection states.
DEFINITION: A Control session is an application level relationship
between a Media Gateway Controller and a Media Gateway. The use of
the term session does not carry any implications for the protocol
stack below the application level.
It shall be possible for either the Media Gateway or the controller
to detect loss of contact with the other party to the control session
within a configurable time of the order of ten seconds or less. The
appropriate actions to take upon detection of loss of contact are for
further study.
5.3.4 Control Session Security
The Media Gateway control protocol shall provide the means for mutual
authentication at the start of a control session, and for
preservation of the integrity and confidentiality of control messages
once the session has started.
6. REFERENCES
[1a] http://www.etsi.org/tiphon.
All ETSI-TIPHON documents are publicly available for free through
this website.
TIPHON mailing lists are also open to everyone.
[1b] DTS/TIPHON-02002 V0.3.1: "TIPHON; Network architecture and
reference configurations; Phase II: Scenario 1 + Scenario 2";
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-
drafts/wg2/DTS02002/V0.3.1/
[1c] http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/05-9810-
Tel_Aviv/10td137r1.doc
[2] ITU-T Recommendation H.323 (1998) (version 2): "Packet based
multimedia communication"
[3] ITU-T Recommandation H.245 (1998) (version 3): "Control protocol
for multimedia communication".
[4] ITU-T Recommandation H.225.0 (1998) (version 2): "Call
signalling protocols and media stream packetization for packet based
multimedia communications systems".
[5] TR 101 306: "Telecommunications and Internet Protocol
Harmonization Over Network (TIPHON); Requirements for service
interoperability; Scenario 1".
7. Acknowledgments
This draft is the work of Working Group 2 of ETSI-TIPHON. Many thanks
to all contributors.
8. Contact Address
Jozef Vandenameele
Alcatel Bell NV
Francis Wellesplein 1
B-2018 Antwerpen, Belgium
Tel: + 32-3-240 4361
Fax: + 32-3-240 9999 or 9961
email : Jozef.Vandenameele@btmaa.bel.alcatel.be
or send mail to the mailing list of ETSI-TIPHON WG 2:
TIPHON_WG2@list.etsi.fr
(to subscribe, send "subscribe TIPHON_WG2" to listserv@list.etsi.fr)
| PAFTECH AB 2003-2026 | 2026-04-24 09:08:56 |