One document matched: draft-vandenameele-tiphon-arch-gway-decomp-01.txt

Differences from draft-vandenameele-tiphon-arch-gway-decomp-00.txt



          Requirements for a Protocol between Media Gateway
          Controller and Media Gateway (Reference Point 'N')


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 an update of ETSI-TIPHON's work
on requirements for a protocol at the reference point N (in TIPHON 
parlance) of the TIPHON reference configuration. Reference point N
designates the information flows required for control of a Media 
Gateway in a decomposed Gateway [0].

This Internet-Draft supercedes the one submitted in November 1998 
and represents consensus of working group 2 in TIPHON.

ETSI-TIPHON is working on standards to connect VoIP (Voice over IP) 
networks and phone networks.


TABLE OF CONTENTS

1  Introduction
2  References
3  Definitions and abbreviations
   3.1  Definitions
   3.2  Abbreviations
4  Reference Configuration
5  Scope of Media Gateway Control
6  Media Gateway Examples
7  Protocol Requirements
   7.1  Connection Control
   7.2  Endpoint Attributes
   7.3  Content Insertion
   7.4  Event Detection and Notification
   7.5  Other Requirements
        7.5.1  Modularity and Extensibility
        7.5.2  Resource Management
        7.5.3  MGC-MG Association Management
        7.5.4  Scripting
   7.6  Security
8  Subjects for further study
9  Acknowledgements
10  Contact Address


1  INTRODUCTION

ETSI-TIPHON [12] is working on standards to connect VoIP (Voice over 
IP) networks and phone networks. Of its now 7 working groups, working
group 2 (WG2) is on architecture and 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 to 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 is the asciified version of, in ETSI parlance,
Technical Specification DTS/TIPHON-02005 Version V0.1.1, with status
15 January 1999 [0].


2  References

[0] DTS/TIPHON-02005 V0.1.1 (1999-01): "Telecommunications and 
Internet Protocol Harmonization Over Networks (TIPHON); Requirements
for a Protocol at Reference Point N; Media Gateway Controller to
Media Gateway"; http://docbox.etsi.org/tech-org/tiphon/Document/
tiphon/07-drafts/wg2/DTS02005/V0.1.1/DTS02005%20V011.doc

[1] ITU-T Recommendation E.164 (1997): "The international public 
telecommunications numbering plan".

[2] ITU-T Recommendation H.323 (1998): "Packet-based multimedia 
communication".

[3] ITU-T Recommendation H.245 (1998): "Control protocol for 
multimedia communication".

[4] ITU-T Recommendation H.225.0 (1998): "Call signalling protocols 
and media stream packetization for packet based multimedia 
communication systems". 

[5] ITU-T Recommendation H.235 (1998): "Security and encryption for 
H. series [H.323 and other H.245-based] multimedia terminals".

[6] TR 101 306: "Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON); Requirements for service 
interoperability; Scenario 1".

[7] TS 101 324: " Naming and addressing; Scenario 1".

[8] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of 
voice frequencies".

[9] ITU-T Recommendation G.723.1: "Dual rate speech coder for 
multimedia communications transmitting at 5.3 and 6.3 kbit/s".

[10] ITU-T Recommendation Q.931: "ISDN user-network interface layer 
3 specification for basic call control".

[11] TS 101 313: "Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON); Network architecture and 
reference configurations; Phase II: Scenario 1 + Scenario 2", Version 
0.4.1, January 1999.

[12] 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.


3	Definitions and abbreviations

3.1	Definitions

- 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.

- 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.


3.2	Abbreviations

ATM	Asynchronous Transfer Mode
BRI	Basic Rate Interface
DTMF	Dual Tone Multi Frequency
GK	GateKeeper
GW	Gateway
IP	Internet Protocol
MG	Media Gateway
MGC	Media Gateway Controller
NNI	Network to Network Interface
PRI	Primary Rate Interface
PSTN	Public Switched Telephone Network
QoS	Quality of Service
RTCP	Real-time Transport Control Protocol
RTP	Real-time Transport Protocol
SCN	Switched Circuit Networks
SG	Signalling Gateway
SS7	Signalling System N 7
UNI	User to Network Interface


4.	Introduction

Figure 1 shows the reference configuration as defined in [11]. 
Reference Point N designates the information flows required for 
control of a Media Gateway in a decomposed Gateway.

     +--------+   D  +--------+   G  +--------+
     |   GK   |------|   GK   |------|Back End|
     +--------+      +--------+      +--------+
          |               |              /     
        A |             C |      ___F___/
          |        . . . . . . ./. . . . . . . .
     +--------+   .  +--------+   J  +--------+ .
     |H323 Ter|   .  |  MGC   |------|   SG   |------
     +--------+   .  +--------+      +--------+ .
           \____B_.       |                     .
                  .\    N |                     .
                  . \     |                     .
                  .  +--------+                 . 
                  .  |   MG   |-----------------.----
                  .  +--------+                 .
                   . . . . . . . . . . . . . . . 


          Figure 1: Basic call reference configuration
          (MGC = Media Gateway Controller, MG = Media Gateway,
           SG = Signalling Gateway, H323 Ter = H.323 Terminal)


5.	Scope of Media Gateway Control

This subclause is a copy of subclause 6.7 of [11]
Information flows at reference point N shall include support for the 
following 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, when connections are 
created and subsequently during the life of the connection;

3) requesting the insertion of tones and announcements into media 
streams, either by explicit request of the Media Gateway Controller 
or by indicating that insertion should begin and end with the 
detection of specified events within the Media Gateway itself;

4) requesting the reporting of, and possibly specifying the actions 
to take upon detection of specified events within the media streams.


6.	Media Gateway Examples

Media Gateway examples include but are not limited to the following 
applications:

- Trunk gateways that interface between SCN networks and Voice over 
IP network.  Such gateways typically interface to SS7 or other NNI 
signalling on the SCN and manage a large number of digital circuits.

- Voice over ATM gateways which operate much the same way as voice 
over IP trunk gateways, except that they interface to an ATM network.

- Access gateways that interface UNI interfaces like ISDN (PRI and 
BRI) and traditional analogue voice terminal interfaces to a Voice 
over IP network.

- Residential gateways are access gateways for a small number of 
voice terminals that can be co-located with a cable modem or set top 
box. 

- Network Access Servers, which convert modem signals from an SCN 
network and provide data access to the packet network.

- Multipoint Processing Units that provide multipoint connectivity 
between terminals on SCN and packet networks.

- Interactive Voice Response systems that provide automatic voice 
response and switching services in response to DTMF signals from the 
SCN.

- IP Gateways that are used to interface either between 
administrative domains which apply different policies (e.g. proxies), 
or to transform media streams formats (e.g. transcoding).

- Fax Gateways


7. 	Protocol Requirements

7.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);
- packet to packet
- circuit to circuit (e.g. 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,  IPv4 is mandatory and IPv6 may be supported. 
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 (e.g. fault isolation)


            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 local end-points, 
and local connections within the Media Gateway between two or more of 
its endpoints. Endpoints shall be designated using a hierarchical 
naming construct. 

2) 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 a suitable endpoint instance and return 
its full identity to the Media Gateway Controller.

3) Wildcarding shall be provided to allow a simultaneous reference to 
multiple endpoints.

4) Ability to request the selection of ports for both RTP and RTCP 
reception on the packet side. The numerical values of RTP and RTCP 
ports may be non-subsequent numbers. [2]

5) Ability to convey the requested QoS parameters applicable on the 
packet side of a media stream connection.

6) Ability to convey the requested bearer capabilities applicable on 
the SCN side of a media stream connection.

7) Ability to convey QoS statistics for an established connection at 
any time during the call and at teardown.

8) Ability for the Media Gateway to autonomously report if the QoS on 
a given connection has fallen below a specified value.


7.2	Endpoint Attributes

The protocol shall be able to convey the following endpoint 
attributes:

1) Media protocol used (RTP, fax-protocol, ...) 

2) Payload type (e.g. codec), 

3) Codec-related attributes like packetisation interval, jitter 
buffer size and silence suppression where appropriate

4) Generation of comfort noise during silent periods.

5) Application of encryption/decryption and identification of the 
encryption schemes.

6) Echo cancellation

7) Lawful interception of the content of a specified media stream.

8) It should be possible to support additional endpoint attributes as 
they are defined without modifying the existing semantics.


The protocol shall allow 

- the specification of the endpoint attributes when the connection is 
created;

- modification of endpoint attribute values for an already-existing 
connection (e.g. in response to a H.245 FlowControlCommand or 
ReplacementFor OLC (OpenLogicalChannel) ).


7.3	Content Insertion

The protocol shall support

- the ability to request the sending of a specified tone or 
announcement, at any time, in a specified direction

- the specification of the conditions under which the sending should 
stop

- the ability to request muting of a media stream.

- 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.


7.4	Event Detection and Notification

The protocol shall support the ability to instruct the Media Gateway 
to detect, notify and possibly act upon specified events. 
Examples of events are:

- DTMF tones,

- off-hook, on-hook


7.5	Other Requirements

As a general requirement, the 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 vendor-specific content.


7.5.1	Modularity and Extensibility

It is essential that the protocol be both modular and extensible. Not 
all implementations may wish to support all of the possible 
extensions. This will permit light-weight implementations for 
specialized 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.
The protocol shall support backwards compatibility as new versions 
are released.

The protocol shall allow the possibility of vendor-specific 
extensions.


7.5.2	Resource Management

The protocol shall provide the means for the Media Gateway Controller 
to determine resource availability within the associated Media 
Gateway. The protocol shall allow for unsolicited messages between 
the Media Gateway and Media Gateway Controller. 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 Media Gateway 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 Controller to audit the 
connection state of  connections in Media Gateways with which it is 
associated.

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.


7.5.3	MGC-MG Association Management

- The protocol shall provide the means to establish and remove an 
MGC-MG association between a specific controller and a specific Media 
Gateway.

- It shall be possible for a Media Gateway to establish an MGC-MG 
association with an alternate Media Gateway Controller if its 
currently associated controller becomes unavailable. 

- It shall be possible for either the Media Gateway or the Media 
Gateway Controller to detect loss of the control association.


7.5.4	Scripting

The protocol shall provide the means to download scripts to be 
executed autonomously by the Media Gateway.


7.6	Security

The protocol shall allow for mutual authentication at the start of an 
MGC-MG association , and for preservation of the integrity and 
confidentiality of control messages once the association has been 
established.


8.	Subjects for further study

- Support for H.323 fast start


9.  Acknowledgments

This draft is the work of Working Group 2 of ETSI-TIPHON. Many thanks
to all contributors.


10. 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-20262026-04-24 03:41:42