INTERNET-DRAFT
Internet Engineering Task Force Sunil Mahajan
INTERNET DRAFT Hughes Software Systems
March 17, 1999
Expires September 17, 1999
<draft-mahajan-packet-ss7-arch-00.txt>
Packet-SS7
SS7 to Packet SS7 Network
<draft-mahajan-packet-ss7-arch-00.txt>
Sunil Mahajan
Version 0.1 draft
Status of this Memo
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the author does not provide the
IETF with any rights other than to publish as 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 drafts 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Drafts Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
ABSTRACT
The transition from circuit based voice telephony network to pure
packet based voice telephony network requires huge investment. It
also requires setting of a parallel packet voice telephony network
components with definition of packet network signalling protocols
and packet network bearer transport protocols and in addition,
support for intelligent services on packet network.
This paper defines a Packet-SS7 network.
This paper tries to explore the idea of modifying existing SS7
network protocol and network architecture to support packet voice
services on it. It can also provide an easy transition path from
circuit voice network to pure packet voice network.
Mahajan [Page 1 ]
INTERNET-DRAFT Packet-SS7 September 1999
VOICE OVER PACKET NETWORK
Today's voice (and other media's as well) communication is moving
away from circuit switch connection to packet connections for cost
benefit, at the expense of voice quality on these networks.
Typical network architecture of voice over packet network requires
interworking function support at the edge of these two networks.
These interworking functions for signalling and media interworking
are supported by Voice over Packet Gateways. One of the popular
Gateways (or technologies) among many is VoIP (voice over IP
Network). During the transition phase, since the local
connectivity to network will remain on PSTN ingress switches, the
network architecture of a typical gateway cloud on PDN network
will look as shown in following picture.
------
| |
| SCP |=============== ===
| | || / \
------ || ---
|| . SUB-B
-------- .
-------- { } .
=== | SS7 SW |======={ SS7 NW } --------
/ \ .......| 1 | { }======| SS7 SW |
--- -------- iiiiiiii { }iiiiiii| 3 |
SUB-A i || ------- -------
i || i ||
i || i ||
i || i ||
i || -------- i ||
i || { } i ||
------ { PDN and GW } --------
| VoIP | { CLOUD } | VoIP GW|
| GW-1 |%%%%%%%%%%%%{ }%%%%%%%| 3 |
------ ------- -------
%
%
%
%
------
| VoIP |
| GW-2 |
------
======= Signalling Trunks
iiiiiii Bearer Trunks
%%%%%% PDN Network Connectivity
Figure 1 Voice over Packet network Architecture
Mahajan [Page 2 ]
INTERNET-DRAFT Packet-SS7 September 1999
TYPICAL CALL ROUTING WITH GW NETWORK
A typical call with above network requires offload of voice call
from Ingress switch-1 to the gateway-1 and then the call gets
routed to gateway-3 using packet signalling(e.g. H.323) and packet
bearer protocols(e.g. RTP/RTCP) through PDN. Getway-3 routes the
call back to Egress switch-3 and finally to subscriber.
ISSUES WITH GW NETWORK
There are few issues with above call senario
- Routing at GW-1 for call to SUB-B
- Address Translation at GW-1.
- Control of supplementary and intelligent services.
For all of the above issues there are solutions defined with these
networks,
1. Routing and address translation decision is taken either
at gateway-1, if it maintains the network routing database and
address translation tables.
2. Routing and address translation decision is taken by an
entity called Gatekeeper (GK), which holds the routing
database and translation database.
3. Routing and address translation is done through GW-1 or
through GK cloud by making a query to AIN network (over SS7
network) entity, called SCP (service control point).
4. Control of supplementary services and intelligent services
is through GK or through SCP (over SS7 network).
5. Signalling may be through PDN is directly between GW-1 and
GW-2.
6. Signalling may be controlled by GK cloud.
Above solution requires following entities in the Gateway network
- Gatekeeper Network
- Connectivity to AIN network over SS7 or a parallel AIN network
support
Moreover this kind of network requires building parallel telephony
components.
For example
- AIN components on PDN.
- signalling paths or routes on PDN
- signalling protocols on packet network
- subscriber database for packet subscribers etc.
Mahajan [Page 3 ]
INTERNET-DRAFT Packet-SS7 September 1999
However this can be avoided, if we use the existing SS7 network
or PSTN network on SS7, for both packet signalling and packet
bearer communication. We will be discussing the architecture of
such network after we discuss in brief network architecture SS7
network.
TODAY'S SS7 CIRCUIT SWITCHED VOICE NETWORK
The SS7 voice network is depicted in following picture
------
| |
| SCP |========================= ===
| | || / \
------ || SUB-B ---
|| .
-------- .
-------- -------- { } .
=== | SS7 SW |====| SS7 SW |====={ SS7 NW } --------
/ \ ....| 1 | | 2 | { }===| SS7 SW |
--- -------- iiii ------- iiiiii { }iiii| 3 |
SUB-A || || ------- -------
|| || ||
|| || ||
|| || ||
|| || ||
|| || ||
------ || ||
|STP / |====== ||
| / | ||
|/ |=========================
------
======= Signalling Trunks
iiiiiii Bearer Trunks
Figure 2 SS7 Circuit Switched Voice Network
A typical call establishment from SUB-A to SUB-B on SS7 network,
requires following steps
- Switch-1 detects the call attempt by SUB-A
- Switch-1 decides the call route to reach Switch-3 for SUB-B.
- Route to Switch-3 may be decided locally by call control or by
remote database query to SCP over SS7 network.
- Deciding route involves selecting next switch on the route and
selecting a circuit (CIC) based on the bearer channel
requirement.
Mahajan [Page 4 ]
INTERNET-DRAFT Packet-SS7 September 1999
- Switch-1 selects a voice trunk (or voice circuit) to Switch-2.
- Switch-1 sends ISUP signalling information to Switch-2.
- Switch-1 switches the voice path to Switch-2.
- On receiving ISUP signalling information the routing,
signalling and switching procedure is repeated and this way
call reaches finally to Switch-3.
- Switch-3 does local (access side) call signalling to SUB-B and
switches the path to subscriber if it is free.
- Switch-3 sends signalling information back to Switch-1 through
Switch-2.
- Switch-1 connects the subscriber to voice trunk.
- Call is established.
In this call establishment following are the points to be noted
* Routing database is distributed through out the network.
* Each node decides the next node in the path.
* Infrastructure is in place for circuit establishment and
signalling path.
* Path and protocols to intelligent network entities (SCP etc.)
are established.
USING SS7 NETWORK FOR PACKET COMMUNICATION
There are three alternatives for packet communication using SS7
network infra-structure
1. Use existing SS7 infrastrucure(SS7 switches and other nodes)
for routing, supplementary services, intelligent network
functions. Use SS7 signalling trunks for signalling and use
SS7 bearer trunks for packet communication. Call this PSA-1
(Packet SS7 Architecture-1).
2. Use existing SS7 infrastrucure(SS7 switches and other nodes)
for routing, supplementary services, intelligent network
functions. Use SS7 signalling trunks for signalling. Provide
PDN network connectivity to SS7 nodes for bearer communication
. Call this PSA-2 (Packet SS7 Architecture-2).
3. Mix of above two architectures, with SS7 nodes supporting both
kind of connectivities. Call this PSA-3 (Packet SS7
Architecture-3).
We will discuss each of these architectures in details in
subsequent sections.
Mahajan [Page 5 ]
INTERNET-DRAFT Packet-SS7 September 1999
PSA-1
This architecture supports the services, signalling and packet
voice or bearer communication on the existing SS7 infrastructure.
The modifications required for this support is in following
modules
- Call Control Function
- Enhancement of ISUP protocol
- Support for packet protocol on circuit connection.
- Firmware to support media transcoding.
The architecture first will be discussed in view of interaction
between two adjacent SS7 switches and then will be further
extended to the network.
===
/ \
---
.
.
.
-------- ISUP ---------
=== | SS7 SW |===========================| SS7 SW |
/ \ .......| 1 | | 2 |
--- -------- iiiiiiiiiiiiiiiiiiiiiiiiiii| |
|| N-Voice Circuits ---------
|| ||
|| ||
|| ||
|| -------- ||
|| { }===========
|| { SS7 PSTN } --------
============= { CLOUD } | SCP |
{ }=======| |
------- -------
======= Signalling Trunks
iiiiiii Bearer Trunks
Figure 3 SS7 Voice Network
The above configuration contains two switches connected by
signalling trunks directly connecting these two switches and also
through an alternate-signalling path. N-voice circuits connect
these two switches, which directly maps to N-cics between these
two switches. However these N-circuits may have few digital
circuits on E1/T1s, few on satellite or may be few on low speed
Mahajan [Page 6 ]
INTERNET-DRAFT Packet-SS7 September 1999
links etc. So a typical call establishment between these two
switches requires selection of a CIC based on the bearer channel
requirement. Now consider another configuration
===
/ \
---
.
.
.
-------- ISUP ---------
=== | SS7 SW |===========================| SS7 SW |
/ \ .......| 1 |iiiiiiiiiiiiiiiiiiiiiiiiiii| 2 |
--- -------- N-X Voice Circuits | |
|| % % ---------
|| %%%%%%%%%%%%%%%%%%%%%%%%%%% ||
|| X Packet Circuits ||
------- ||
| STP | ||
| | ==================================
-------
||
|| --------
|| { }
|| { SS7 PSTN } --------
============= { CLOUD } | SCP |
{ }=======| |
------- -------
======= Signalling Trunks
iiiiiii Bearer Trunks
%%%%%%% Packet circuits
Figure 4 Packet SS7 Network Architecture-1
This configuration has divided N-voice circuits to two groups,
first group contains N-X voice circuits and the other group
contains X packet circiuts.
Packet Circuit: Packet circuits are the same digital voice
circuits between two switches but supports packet
communication. To support packet communication on
these digital circuits, the two switches
connecting these circuits run HDLC protocol on
these circuits. The HDLC protocol however is not
run on individual circuit but on a group of
circuit bundled together to make a packet-circuit
group. This grouping depends on the physical
grouping of these circuits, for example all
circuits on an E1 trunk makes one packet group.
Mahajan [Page 7 ]
INTERNET-DRAFT Packet-SS7 September 1999
CONFIGURATION OF PACKET CIRCUITS
The two switches connecting these packet circuits needs to assign
cics for them. The number of CICs assigned can be more than the
number of circuits in these packet groups. A typical configuration
may assign cics in the range of 8-10 times the number of physical
circuits. This assignment is based on the assumption that packet
circuits can support more calls than their physical number, for
following reasons
- Compressed voice on these circuits
- Silence suppression results in less bandwidth requirements.
- Replaying last received compensates lost voice packets.
VOICE TRANSPORT ON PACKET CIRCUITS
Transport of voice on these packet circuit uses the mechanism
recommended for H.323 networks. The transport uses Real-Time
Transport Protocol (RTP) and Real-Time Transport Control Protocol
(RTCP). As the requirement from these protocol requires an
un-reliable lower layer transport channel, which in most of the
network is provided by UDP/IP protocol in the network. The
confguration suggested above does not require any routing of
packets at lower layer, since the connectivity is point to point
and the identification of call in RTP session will be done by
small ss7-packet header. So a typical RTP packet will look like
---------------------------------------------------------
| HDLC HDR | SS7-PAC HDR | RTP HDR | RTP PAY- | HDLC TRL |
| | | | LOAD | |
---------------------------------------------------------
HDLC and RTP HDR are the standard headers, but SS7 header will
look like as shown in following picture (it is like a routing
label in SS7 message with CIC added).
-------------------------------
| OPC | DPC | CIC |
| | | |
-------------------------------
Mahajan [Page 8 ]
INTERNET-DRAFT Packet-SS7 September 1999
CALL ESTABLISHMENT ON PACKET CIRCUIT
When two exchanges comes up they block all the packet circuits
till HDLC communication is established on them. After HDLC channel
is established, the circuits are unblocked and are available to
call control for allocation. At any time if the HDLC communication
goes away or channel is diconnected the affected CICs are blocked
by both the exchanges.
SUPPORT FOR H.245 SIGNALLING
Before RTP channel communication a typical packet network
signalling requires capabilities exchange between two nodes to
establish the characterstics of the voice communication supported,
for example the type of voice coding used, jitter buffer
parameters etc. This can be achieved by either assuming a static
configuration of these capabilities at both the switches during
the CICs initialisation or exchange of this information during
call establishment, i.e. the forward direction capabilities
parameters are send with IAM message by introducing another
parameter in IAM message
-------------------------------------------
| PARAMETER NAME = ISUP_FORW_CAPABILITY_SET |
| |
-------------------------------------------
| PARAMETER_LEN = X BYTES |
| |
-------------------------------------------
| PARAMETER CONTENTS as specified in H.245 |
| (ASN encoded ) |
-------------------------------------------
Moreover to indicate that capability exchange is required before
call establishment, Nature_Of_Connection_Indicator parameter in
IAM is modified as
---------------------------------------
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
---------------------------------------
| H | G | F | E | D | C | B | A |
---------------------------------------
Bit F : Capability Exchange Required
0 Capability Exchange Not Required
1 Capability Exchange Required
Mahajan [Page 9 ]
INTERNET-DRAFT Packet-SS7 September 1999
If capability exchange is required the originating exchange will
wait for backward message which is defined as
Message Type: Backward Capability Exchange (BCE)
Parameters : Mandatory Variable Length: ISUP_BACW_CAPABILITY_SET
Length: X Bytes
Contents: ASN formatted capability set
A TYPICAL CALL ESTABLISHMENT
A typical call establishment between two exchange will require
following steps
1)Exch-1 based on the subscriber profile and bearer channel
requirements from the access side will decide whether to use
packet circuits or voice circuits.
2)If there is no packet circuit available then Exch-1 can select
a voice circuit for the call.
3)Assume Exch-1 selects packet circuit.
4)Exch-1 selects a packet CIC.
5)Exch-1 based on the cic configuration decides to exchange the
capability set for the call.
6)Exch-1 generates an IAM with following parameter parameters
TMR (Transmission Medium Requirements): Voice Packet Circuit
NOCI (Nature of Connection Indicator): Capability Exchange
Required
ISUP_FORW_CAP: Forward capability set
Exch-1 Exch-2
IAM(with NOCI=Exch required, TMR= Packet voice,
Forw Capability)
| --------------------------------------------->
|
|Timer Started
| BCE
v <---------------------------------------------
7)Exch-2 on deciding capability set generated message BCE back to
Exch-1
8)Both the exchanges set the RTP and RTCP protocol for this cic.
9)After these message exchange, the call establishment is like a
normal ISUP call establishment.
10)After the complete call path is established RTP packets are
exchanged between these two exchanges for voice or bearer
communication.
11)RTCP is used to control the RTP sessions. It can also be used
to control the quality of service for RTP sessions. If RTCP
reports more packet loss, congestion and delays, then either
exchange can block few of the CICs to reduce further traffic
between them.
Mahajan [Page 10]
INTERNET-DRAFT Packet-SS7 September 1999
Extending PSA-1 to networK
PSA-1 architecture discussed above involves only two exchanges.
The following configuration is assumed in the network for packet
communication across network.
===
/ \
---
.
.
.
-------- --------- --------
=== | SS7 SW |=============| SS7 SW |========| SS7 SW |
/ \ ....| 1 |iiiiiiiiiiiii| 2 |iiiiiiii| 3 |
--- -------- Voice Cir | | | |
|| % % --------- --------
|| %%%%%%%%%%%% % % ||
|| Packet Cir %%%%%%%%% ||
|| ||
|| ||
------- ||
| STP |======================================
| |
-------
|| *********
|| { }
|| { SS7 PSTN } --------
============= { CLOUD } | SCP |
{ }=======| |
******* -------
======= Signalling Trunks
iiiiiii Bearer Trunks
%%%%%%% Packet Circuits
Figure 5 Extension to PSA-1
The difference between this configuration and previous
configuration is that, a call establishment in this case requires
signalling information exchange between Exch-1, Exch-2 and Exch-3.
Further there will be two RTP sessions involved, one between
Exch-1 and Exch-2 and other between Exch-2 and Exch-3. In addition
to all the functions as required for previous configuration, this
configuration requires RTP relay function at Exch-2.
Mahajan [Page 11]
INTERNET-DRAFT Packet-SS7 September 1999
RTP-RELAY FUNCTION
RTP relay function requires terminating RTP protocol at one end
and relaying or switching RTP packets to other side. As discussed
earlier RTP exchange between two Exchanges carries an SS7-PAC-HDR
which contains routing label information. So at the time of RTP
session establishment on both sides RTP relay function needs to
maintain the routing label mapping for both sides and during data
transfer phase can use this map table to switch RTP packets. RTP
relaying requires changing SS7-PAC-HDR and optionally requires
changing RTP header.
Most of the media processing (echo cancellation etc.) related
functions can be done at the originating exhange or at terminating
exchange, but they may optionally be done at realy nodes as well.
However few of these functions may be done at all nodes, for
example jitter management, packet loss compensation.
PSA-2
This network architecture uses existing SS7 infrastrucure(SS7
switches and other nodes) for routing, supplementary services,
intelligent network functions. It uses SS7 signalling trunks for
signalling. However it uses PDN network connectivity to SS7 nodes
for bearer packet communication.
Mahajan [Page 12]
INTERNET-DRAFT Packet-SS7 September 1999
===
/ \
---
.
.
.
-------- --------- --------
=== | SS7 SW |=============| SS7 SW |========| SS7 SW |
/ \ ....| 1 |iiiiiiiiiiiii| 2 |iiiiiiii| 3 |
--- -------- Voice Cir | | | |
# || --------- --------
# || # # ||
# || # # ||
# || # ############## # ||
# || # # ||
# || # # ------- ||
# || # # | STP |=============
# =========#==#====| |
# # # -------
# # # ||
# # # ||
# # # ---------
# # # # { }
----- ##### { SS7 PSTN } --------
{ }### { CLOUD } | SCP |
{ PDN } { }=======| |
{ } ------- -------
------
======= Signalling Trunks
iiiiiii Bearer Trunks
####### Packet Circuits
Figure 6 Packet SS7 Architecture-2
In first of these configuration each of the switch is connected
PDN network for packet voice connectivity, which carries the
complete RTP/RTCP session on UDP/IP network. The CIC configuration
for this connectivity may use a different OPC/DPC combination,
other than OPC/DPC pairs for voice circuits or it may use the same
OPC/DPC pair. The number of CICs configured may depend on the kind
of network connectivity and bandwidth available.
This configuration supports a packet structure similar to the one
described earlier.
Mahajan [Page 13]
INTERNET-DRAFT Packet-SS7 September 1999
------------------------------------------------------
| IP | UDP | SS7-PAC-HDR | RTP HDR | RTP Payload |
| | | | | |
------------------------------------------------------
This RTP communication however does not require establishment of
HDLC channel between two exchanges. RTCP in this configuration can
still be used for congestion control to block circuits in case of
high packet loss and congestion in the network. This configuration
still requires all the support as described in PSA-1 for ISUP
(TMR modification, NOCI modification, BEC message support, Forward
and Backward capability parameters).
A TYPICAL CALL ESTABLISHMENT
A typical call establishment between two exchange will require
following steps
1) Exch-1 based on the subscriber profile and bearer channel
requirements from the access side will decide whether to use
packet circuits or voice circuits.
2) If there is no packet circuit available then Exch-1 can select
a voice circuit for the call.
3) Assume Exch-1 selects packet circuit.
4) Exch-1 selects a packet CIC.
5) Exch-1 based on the cic configuration decides to exchange the
capability set for the call.
6) Exch-1 generates an IAM with following parameter parameters
TMR (Transmission Medium Requirements): Voice Packet Circuit
NOCI (Nature of Connection Indicator): Capability Exchange
Required
ISUP_FORW_CAP: Forward capability set
Exch-1 Exch-2
IAM(with NOCI=Exch required, TMR= Packet voice,
Forw Capability)
| --------------------------------------------->
|
|Timer Started
| BCE
v <---------------------------------------------
7) Exch-2 on deciding capability set generated message BCE back to
Exch-1. Capability exchange between two exchange equires
exchange of UDP ports for RTP/RTCP sessions.
Mahajan [Page 14]
INTERNET-DRAFT Packet-SS7 September 1999
8) Both the exchanges set the RTP and RTCP protocol for this cic.
9) After these message exchange, the call establishment is like a
normal ISUP call establishment.
10) After the complete call path is established RTP packets are
exchanged between these two exchanges for voice or bearer
communication.
11) RTCP is used to control the RTP sessions. It can also be used
to control the quality of service for RTP sessions. If RTCP
reports more packet loss, congestion and delays, then either
Exch-2 can block few of the CICs to reduce further traffic
between them.
MODIFICATION TO ABOVE CONFIGURATION
Above configuration can be modified to support long PDN
connectivity as shown in following picture.
===
/ \
---
.
.
.
-------- --------- --------
=== | SS7 SW |=============| SS7 SW |========| SS7 SW |
/ \ ....| 1 |iiiiiiiiiiiii| 2 |iiiiiiii| 3 |
--- -------- Voice Cir | | | |
# || --------- --------
# || # ||
# || # ||
# || ################ # ||
# || # ||
# || # ------- ||
# || # | STP |=============
# =========#=======| |
# # -------
# # ||
# # ||
# # ---------
# # { }
----- # { SS7 PSTN } --------
{ }### { CLOUD } | SCP |
{ PDN } { }=======| |
{ } ------- --------
------
======= Signalling Trunks
iiiiiii Bearer Trunks
####### Packet Circuits
Figure 7 Modified PSA-2
Mahajan [Page 15]
INTERNET-DRAFT Packet-SS7 September 1999
In this configuration Switch-1 and Switch-3 are adjancent switches
for packet CICs and can have direct signalling and packet bearer
establishment. Rest of the procedures for call establishment and
bearer communication are similar to as defined with previous
configuration.
PSA-3
Architecture PSA-3 is combination of above two architecture with
signalling and packet bearer communication supported as required
for each of them.
===
/ \
---
.
.
.
-------- --------- --------
=== | SS7 SW |=============| SS7 SW |========| SS7 SW |
/ \ ....| 1 |iiiiiiiiiiiii| 2 |iiiiiiii| 3 |
--- -------- Voice Cir | | | |
# || % % ---------% %--------
# || %%%%%%%%%%%% # %%%%%%% # ||
# || # # ||
# || # ################## ||
# || # # ||
# || # # ------- ||
# || # # | STP |=============
# =========#==#====| |
# # # -------
# # # ||
# # # ||
# # # ---------
# # # # { }
----- ##### { SS7 PSTN } --------
{ }### { CLOUD } | SCP |
{ PDN } { }=======| |
{ } ------- -------
------
======= Signalling Trunks
iiiiiii Bearer Trunks
####### Packet Circuits
Figure 8 Packet SS7 Architecture-3
Mahajan [Page 16]
INTERNET-DRAFT Packet-SS7 September 1999
This configuration supports packet circuit connections between two
switches directly and also through PDN.
CONCLUSION
Packet-SS7 architecture may provide a transition solution from
circuit network telephony to pure packet network telephony. With
the number of circuits X (packet voice circuits) increasing with
each telephony switch to finally N (total voice circuits), ciruit
switches can be converted to packet switches. Moreover the
architecture PSA-3 or PSA-2 may provide a smooth transition from
circuit telephony to packet telephony transition with voice
switches replaced by packet switches supporting packet signalling
protocols and packet bearer protocols.
REFERENCES
ITU-T Q Series Recommendation Q.121x, Intelligent Networks
Interface Recommendation for Intelligent Network CS-1
ITU-T Q Series Recommendation Q.122x, Intelligent Networks
Interface Recommendation for Intelligent Network CS-2
ITU-T Q Series Recommendation Q.76x, SS7
ISDN User Part of Signalling System No. 7
ITU-T H Series Recommendation H.323,
Visual Telephone Systems and Equipment for Local Area Networks
which provides a Non-Guaranteed Quality of Service
ITU-T H Series Recommendation H.225,
Call Signalling Protocols and Media Stream Packetization for
Packet Based Multimedia Communications Systems
ITU-T H Series Recommendation H.245,
Line Transmission of Non-Telephone Signals
Schulzrinne H., Casner S., Frederick R. and Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889,
January 1996
Schulzrinne H., "RTP Profile for Audio and Video Conferences with
Minimal Control", RFC 1890, January 1996
ACKNOWLEDGEMENTS
The author would like to acknowledge all of those who contributed
for helpful review, suggestions and comments.
Mahajan [Page 17]
INTERNET-DRAFT Packet-SS7 September 1999
CONTACT INFORMATION
Sunil Mahajan
smahajan@hss.hns.com
Protocol Development Lab
Hughes Software Systems
Plot# 31, Sector-18
Electronic City, Gurgaon
Harayana - 122015
INDIA
Tel# +91-124-346666
Fax# +91-124-342415
Mahajan [Page 18]