[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                       AVT  Working Group
Internet Draft                                   B. Subbiah, S. Sengodan
draft-ietf-avt-mux-rtp-00.txt              Nokia Research Center.
Aug 21, 1998
Expires: Feb 21, 1999


        User Multiplexing in RTP payload between IP Telephony Gateways


STATUS OF THIS MEMO

   This document is an Internet-Draft. Internet-Drafts are working docu-
   ments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing 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 mate-
   rial or to cite them other than as ``work in progress''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.


                                 ABSTRACT

   This draft proposes a method to multiplex a number of low bit rate
   audio streams (upto 256) into a single RTP/UDP/IP connection between
   IP telephony gateways. Audio samples from different users are assem-
   bled into an RTP payload thus reducing the overhead of RTP/UDP/IP
   headers. To identify users sharing a single RTP/UDP/IP connection,
   a 2 byte MINI-Header is proposed. A channel negotiation procedure to
   assign and release channels on a single UDP connection between
   gateways is described.


1 Introduction

   IP telephony gateways provide an interface between the existing
   circuit switched telephone networks (such as PSTN and GSM) and the
   packet switched IP data networks. In a traditional IP telephony
   application, telephone calls between PSTN/GSM users interconnected by
   a pair of IP telephony gateways are carried by separate RTP/UDP/IP
   connections. Codecs at the IP telephony gateway which compress
   incoming PSTN/GSM speech samples generate packets with sizes ranging
   from 5 to 20 bytes per speech sample. For example, G.723.1 (the most
   popular IP telephony codec and the IMTC VoIP Forum's mandatory low
   bit-rate codec), generates a 20 byte speech packet at 30 ms intervals



B. Subbiah, S. Sengodan                                      [Page 1]


Internet Draft                                            Aug 15, 1998


   [4]. Many codecs used in cellular environments generate packets of
   size less than 10 bytes per speech sample. Small size packets are
   subject to a large overhead when transferred using the Real time
   Transport Protocol (RTP). The RTP/UDP/IP overhead is 40 bytes
   (12+8+20) for a single speech packet. For example, a 10 byte packet
   transferred via RTP/UDP/IP has an overhead of 80%.

   In addition, for each call request a single UDP/IP connection (a pair
   of UDP ports) is established between the gateways. This not only
   limits the number of audio streams between the gateways to the number
   of available UDP port pairs, but also requires a large state (memory)
   to be maintained at the telephony gateways, thereby making these
   gateways less scaleable.

   Another disadvantage of the traditional RTP/UDP/IP method in a
   gateway scenario is the possibility of congestion at intermediate
   routers in the IP network. In the RTP/UDP/IP method, each individual
   speech packet is transmitted as a single IP packet, which results in
   large number of small sized IP packets between gateways. This is a
   potential situation for congestion at intermediate IP routers.
   Congestion in IP networks results in packet loss and UDP does not
   have any re-transmission mechanism to recover lost packets. Also,
   real time applications such as speech are intolerant to delay caused
   by re-transmission.

   In this draft, we propose a mechanism that enables several streams
   (upto 256) to share a single RTP/UDP/IP connection between IP
   telephony gateways thereby reducing the overhead, lowering the
   possibility for congestion at IP routers, and making such gateways
   more scaleable. This method is suitable for IP telephony gateways
   that interconnect PSTN/GSM users through IP networks. In a cellular
   environment, it can also be used in cellular trunking, links that
   interconnect Base Station (BS), Base Station controller (BSC), and
   Mobile Switching Center (MSC) of a Radio Access Network (RAN).
   Individual user packets multiplexed in an RTP payload are identified
   using a 2 byte MINI-header. The channel association between gateways
   for a single user can be carried out by one of the three mechanisms
   described later in this draft.

2 User multiplexing in RTP payload

   It has been observed that, at any given time there are multiple
   active users between IP telephony gateway pairs that interconnect
   PSTN/PBX/GSM clouds. This is also true in the case of cellular
   trunking between a Base Transmission System (BTS) and BSC/MSC. At
   present, IP telephony gateways establish and maintain a separate
   RTP/UDP/IP connection for each call request. In the above scenarios,
   a large number of connections originate and terminate between two
   gateways interconnected by an IP network. This is an ideal situation
   for multiplexing a group of users in a single RTP/UDP/IP connection.

   The mechanism for user mux in RTP that is proposed in this draft
   decreases the overhead by multiplexing two or more (up to 256) low
   bit rate connections (compressed speech) in a single RTP/UDP/IP
   connection. To enable such multiplexing, a 2 byte header called


B. Subbiah, S. Sengodan                                      [Page 2]


Internet Draft                                                      Aug 15, 1998


   MINI-Header is prepended to each mini packet before it is assembled
   with other mini packets into an RTP payload. To identify a single
   user among the number of users sharing the same RTP connection, each
   user is assigned a unique Channel Identifier (CID) which is negot-
   iated during connection setup. The CID negotiation procedure is
   carried out by a control signaling which may be based on one of the
   three methods(CNP, SIP and H.225) described in section 3.

2.1 MINI-Header

   The format of a MINI-Header is shown in Figure 1:


                 0                   1
                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 |      CID      |   LI      |T|R|
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: Format of a MINI-Header


   The length of the MINI-Header is 2 bytes, which includes a Channel
   Identifier(CID), Length Indicator (LI), Transition bit (T) and a
   Reserved bit (R). The purpose of each field is described below:

     - Channel IDentification (CID): This 8 bit field allows a maximum
       of 256 users to share a single RTP/UDP/IP connection. When the
       total number of users exceeds 256, a new RTP/UDP/IP connection is
       established.

     - Length Indicator (LI): This 6 bit field allows a maximum payload
       size of 64 bytes.

     - Transition bit (T): The transition bit is used to facilitate
       dynamic re-negotiation of mini-packet processing. Notification of
       such changes occurs by toggling the bit.

     - Reserved bit (R): The use of this bit is being explored at this
       moment.

   It has been observed that an 8 bit CID is sufficient for multiplexing
   since there are enough speech samples at any instance. Most of the
   codecs generate packets less than 40 bytes per speech sample that can
   be easily accommodated with a 6 bit LI field. While the presence of a
   Sequence Number (SN) field and a Marker (M) field in the mini-header
   could be useful at the receiving gateway, we believe that the
   presence of these fields is not critical. The SN field in the RTP
   header can guarantee the order of packet (RTP packet) arrival at the
   receiver. If the packet multiplexing order at the transmitter is
   maintained then there is no need for SN in the MINI-Header from the
   standpoint of in-sequence arrival of packets within a single
   RTP/UDP/IP connection. Moreover, a Header Error Control (HEC) field
   to protect from transmission errors has been left out because UDP
   checksum could be used for the same purpose.




B. Subbiah, S. Sengodan                                         [Page 3]


Internet Draft                                                    Aug 15, 1998



2.2 RTP Payload Format

   A speech sample (voice packet) received from a user is converted to a
   mini packet by adding the 2 byte MINI-Header. The CID selection and
   channel negotiation procedures are carried out before the packet is
   assembled. These procedures are described in section 3. The assembly
   of mini packets into a single RTP payload with RTP/UDP/IP header is
   shown in Figure 2. The mini packets follow the RTP header and each
   mini packet is delineated by the 2 byte MINI-Header. This arrangement
   of a MINI-header followed by payload allows variable sized packets
   (<= 64 bytes) to be assembled without the knowledge of the payload
   itself. Moreover, this scheme requires a very simple de-multiplexing
   algorithm at the receiver. The RTP payload received by the remote
   gateway is de-assembled to recover the individual mini packets until
   the payload becomes empty. The packets are then delivered to the
   respective users based on the channel association carried out during
   the call setup phase.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+
     |       +       +       +     +     +     +     +   +     +     |
     | IP    +  UDP  + RTP   + MH1 + VP1 + MH2 + VP2 + ~ + MHn + VPn |
     | (20)  +  (8)  + (12)  + (2) +     + (2) +     +   + (2) +     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+

        *MH - Mini Header, VP - Voice Packet

           Figure 2. RTP payload format with user multiplexing

2.3 Packet assembly timer

   While assembling mini packets into an RTP payload, there is a need to
   control the waiting time (delay) between the placement of the first
   packet in the RTP payload and the transmission of the complete IP
   packet to the remote gateway. Without a timer, packets placed at the
   beginning will be subjected to a large delay. This problem occurs
   when there is a large interval between successive packet arrivals at
   the multiplexing end. To solve this problem, we propose a timer
   called TIMER_MUX to control the maximum delay a mini packet may be
   subjected to during the RTP payload assembly. The TIMER_MUX is
   initialized when the first packet is placed in the RTP payload and
   upon the timer expiry the RTP/UDP/IP packet is transmitted. There are
   instances when the RTP/UDP/IP packet needs to be transmitted without
   the expiry of TIMER_MUX. The higher the TIMER_MUX value the better
   the bandwidth efficiency. However, a higher TIMER_MUX value means
   additional delay for voice packets.

2.4 Packet Size

   The assembly process of mini-packets into an RTP payload should not
   only consider the TIMER_MUX value but should also take into account
   the size of the resulting IP datagram. The size of the resulting IP
   datagram should not exceed the maximum transmission unit (MTU) of the



B. Subbiah, S. Sengodan                                      [Page 4]


Internet Draft                                                 Aug 15, 1998


   IP network. Hence, when the IP network is the public Internet, the
   size of the IP datagram should not exceed 1500 bytes. It has been
   determined that an IP datagram of size less than 1500 bytes usually
   goes through the Internet unfragmented.

2.5 UDP connection

   Implementation details of sharing a pair of UDP ports among different
   users and reusing the same port numbers for persistent UDP sessions
   are beyond the scope of this document.

3 Control signaling for user multiplexing

   The user plane and control plane between gateways is shown in
   Figure 3. The control plane signaling is needed because peer Mux
   controllers are required to negotiate a channel for an incoming call
   request on an existing or on a new UDP connection. The control
   signaling is transferred using a common persistent connection, which
   may be either connection oriented (TCP) or connectionless (UDP).
   The user plane association (CID allocation on a UDP connection) is
   made after a successful connection setup. In this draft, we describe
   three different approaches to establish and clear a CID association.
   The user plane data is carried over RTP/UDP/IP layers in a manner
   similar to the audio and video transport over IP networks. The
   description of the signalling and control operation is not meant to
   be comprehensive.

        +++++++++++++++++++                             +++++++++++++++++++
        + Mux Controller  +                             + Mux controller  +
        +++++++++++++++++++                             +++++++++++++++++++
                |    |                                     |            |
                |    |  U-plane                   U-plane  |            |C-plane
C-plane         |   +++++++                             +++++++         |
                |   + RTP +                             + RTP +         |
        +++++++++++++++++++                             +++++++++++++++++++
        +  TCP   |   UDP  +                             +   UDP  |  TCP   +
        +++++++++++++++++++                             +++++++++++++++++++
        +       IP        ++++>   IP NET          <++++++       IP        +
        +++++++++++++++++++                             +++++++++++++++++++

  Figure 3. Control plane and user plane in a user multiplexing scenario


B. Subbiah, S. Sengodan                                         [Page 5]


Internet Draft                                                          Aug 15, 1998


3.1 CID selection

   Irrespective of the choice of the signaling mechanism between the MUX
   controllers, the CID selection procedure at each of the MUX
   controllers MUST be done as follows:

     1) Arrival of a new call from a PSTN/GSM user triggers a CID
        assignment sequence at the MUX controller of the local gateway.
        After establishing which remote gateway can handle the call,
        the local MUX controller checks for the existence of an
        RTP/UDP/IP connection to the remote MUX controller. If there
        exists a UDP connection with free CIDs, then a CID is chosen and
        reserved for that call. If there is no UDP connection between
        the gateways or if all the existing connections are full (i.e.,
        no free CID), then a new RTP/UDP/IP connection is established.
        Once the CID selection is done, a notification message that
        consists of CID, calling user ID, called user ID, local and
        remote UDP port numbers is transmitted. Such transmission may
        occur either in the initial notification message (during call
        setup) or in the notification message for capability exchange
        that occurs after call setup.

     2) Upon receiving the message containing the CID, the MUX control-
        ler at the remote gateway checks its CID table associated with
        the UDP connection. The status of CIDs is maintained in a CID
        table, which is associated with each UDP connection between any
        two gateways. If the CID indicated in the notification message
        has not already been assigned, then the remote MUX controller
        makes an entry in its CID table assigning the CID to a call
        between the pair of UDP ports as indicated in the notification
        message. If the UDP port at the remote gateway is not already
        open, then the MUX controller opens the UDP port. Table 1 shows
        a sample CID table used at a gateway for a single UDP conne-
        ction.

                ------------------------------------------------------------
                | CID |CID status       |       Local UID       |Remote UID |
                ------------------------------------------------------------
                |   5   | Assigned      |       6172300000      |9127363736 |
                |       |               |                       |           |
                |  10   | Reserved      |       6175464636      |8263737474 |
                |       |               |                       |           |
                |  20   | Idle          |                       |           |
                |       |               |                       |           |
                | 200   | Idle          |                       |           |
                ------------------------------------------------------------

                Table 1. CID table for a single UDP connection


3.2 CID collision

   During the CID negotiation procedures, there is a possibility that
   the same CID is selected by both ends for their own call requests.
   Both gateways transmit channel request messages with the same CID
   without the knowledge of the other gateway. After receiving the
   request, both sides are unable to allocate the CID since it has been



B. Subbiah, S. Sengodan                                         [Page 6]


Internet Draft                                                          Aug 15, 1998



   reserved for their local call request. This problem is otherwise
   known as CID glare. We propose to use a method that is fair to both
   ends in CID assignment procedures. In this method, one side is
   assigned to allocate CIDs from the top of the CID table and the
   opposite side from bottom. However, CID collision occurs when a
   single CID is available at both ends. Even in such a case, fairness
   can be achieved by an assignment based on the even and odd value of
   CID. The arbitration of which side starts from top can be resolved
   using IP address of the gateways. For example, the gateway with the
   higher IP address starts from the top and the other gateway starts
   from the bottom.

3.3 Channel Negotiation Procedures (CNP)

   CNP is a new control signaling specifically proposed for the user
   multiplexing application between IP telephony gateways that
   interconnect PSTN/GSM clouds. The function of CNP is to negotiate a
   CID for a call through a set of messages similar to standard signal-
   ing protocols. Since CNP is targeted for a specific application, we
   do not anticipate the need for complex signaling procedures similar
   to H.225/H.245 [5,6]. However, H.225/H.245 could be adapted to suit
   the requirements of the user multiplexing in RTP method. CNP consists
   of a set of messages that include assign, assign_confirm, release,
   release_confirm and reject. An additional message "messages_transfer"
   is also proposed in case there is a need to transmit control messages
   of a particular user (call control messages) during the active
   session of a call. A detailed study on the format of the CNP messages
   and their parameters will be reported later.

   The following is the sequence of events that occur in a channel
   negotiation phase:

     - Assign: Upon arrival of a new call from a PSTN/GSM user, a CID is
       assigned based on the procedure described in the previous sect-
       ion. An "assign" message is then transmitted to the remote gate-
       way containing the local UDP port number, remote UDP port number,
       CID number, calling and called user, and an UUI field to carry
       any call control signaling (PSTN and SS7).

     - Assign_confirm or reject: The remote peer recovers the informat-
       ion within the "assign" message and does local processing as
       described in the previous section. If the call can be accepted
       then the local Mux controller updates its local CID table and
       replies with an "assign_confirm" message. If the remote gateway
       experiences a problem in allocating the connection, say due to
       CID collision, then it transmits a "reject" message. Upon recei-
       ving the "assign_confirm" message, the local Mux controller
       confirms the CID assignment by updating the CID table and noti-
       fying the local user.


B. Subbiah, S. Sengodan                                      [Page 7]


Internet Draft                                                 Aug 15, 1998




                +++++++                                 +++++++
                +     +         Assign                  +     +
                +     +     ---------------->           +     +
                + GW1 +      Assign_confirm             + GW2 +
                +     +    <------------------          +     +
                +     +                                 +     +
                +++++++                                 +++++++

                         Figure 4: CNP Confirm sequence


                +++++++                                 +++++++
                +     +         Assign                  +     +
                +     +     ---------------->           +     +
                + GW1 +         Reject                  + GW2 +
                +     +    <------------------          +     +
                +     +                                 +     +
                +++++++                                 +++++++

                         Figure 5: CNP Reject sequence


3.4 Use of H.225/H.245 for channel negotiation


                        +++++++++                   +++++++++++
        +++++++++       +       +------ H.225 ------+         +     ++++++++
        +       +       +       +------ H.245 ------+         +     +      +
        + PSTN  +++++   +       +                   +         +++++++ PSTN +
        +++++++++       + IP GW +---  IP NETWORK ---+ IP GW   +     ++++++++
                        +       +                   +         +
                        +       +-- UDP channel 1 --+         +
        +++++++++       +       +-- UDP channel n --+         +     +++++++++
        +       + ++++  +++++++++                    ++++++++++++++++       +
        + GSM   +                                                   + GSM   +
        +++++++++                                                   +++++++++

                Figure 6: H.225/H.245 in an IP telephony gateway


   ITU-T has standardized H.225[5] and H.245[6] as the call signaling
   protocol and call control protocol respectively to be used within
   the ITU-T standard H.323[7]. H.225 and H.245 may be used for
   signaling and control purposes between the gateways. When this is the
   case, persistent H.225 and H.245 connections exist between a pair of
   gateways. All voice connections between the two gateways should use
   the same H.225 and H.245 connection for call signaling and call
   control purposes.



B. Subbiah, S. Sengodan                                         [Page 8]


Internet Draft                                                    Aug 15, 1998


   When a new call arrives at a gateway from the circuit switched side
   (PSTN/GSM), a SETUP message is transmitted from the initiating
   gateway to the terminating gateway on the persistent TCP call-signa-
   ling channel (H.225 channel). The User-User-Information-Element
   (UUIE) of the SETUP message includes the parameters that are needed
   for connection setup as indicated in the H.225 document [9].

   For the purpose of user multiplexing between gateways, the setting of
   the UUIE fields in the SETUP message MUST be as follows:

     - h245Address: This field is set to the TSAP address of the call
       control TCP channel (H.245 channel) at the initiating gateway
       that will be used for call control purposes of this voice stream.
       Initiating gateways should use the same call control channel for
       all voice streams. However, the initiating gateway may wish to
       open a new call control channel when the number of voice streams
       using the same control channel exceeds a certain threshold value.
       When the initiating gateway wishes to use a new call control
       channel, the TSAP address of the new H.245 channel is included
       in this field.

   If the remote gateway responds with a CONNECT message upon receiving
   the SETUP message, the UUIE fields within the CONNECT message MUST
   be set as follows:

     - h245Address: This field is set to the TSAP address of the call
       control TCP channel (H.245 channel) at the responding gateway
       that will be used for call control purposes of this voice stream.
       Remote gateways should use the same call control channel for all
       voice streams when an initiating gateway has used the same
       existing call control channel. If a remote gateway wishes to use
       a new call control channel when the initiating gateway has
       indicated the use of an existing call control channel in the
       SETUP message, then the remote gateway must send a FACILITY and
       a RELEASE message. However, if an initiating gateway has indic-
       ated the use of a new call control channel, then the remote
       gateway must use a new call control channel. The TSAP address of
       the new call control TCP channel at the remote gateway is
       included in this field.

   Upon receiving the CONNECT message from the remote gateway, the call
   control phase (H.245) begins. The capability exchange messages
   determine the choice of codecs and the security parameters if any to
   be used between the gateways. In addition, the capability exchange
   also indicates the capability for performing multiplexing. In the
   openLogicalChannel (and openLogicalChannelAck) message, in addition
   to indicating the TSAP address, the CID is also indicated.


B. Subbiah, S. Sengodan                                      [Page 9]


Internet Draft                                                 Aug 15, 1998



                +++++++                                 +++++++
                +     +         SETUP                   +     +
                +     +     ---------------->           +     +
                + GW1 +         CONNECT                 + GW2 +
                +     +    <------------------          +     +
                +     +           CapabilitySet         +     +
                +     +    ------------------>          +     +
                +     +  CapabilitySetAck               +     +
                +     +    <------------------          +     +
                +     +         OLC                     +     +
                +     +    ------------------>          +     +
                +     +         OLCAck                  +     +
                +     +    <------------------          +     +
                +++++++                                 +++++++

                         Figure 7: H.225/H.245 exchange sequence



                +++++++                                 +++++++
                +     +         SETUP                   +     +
                +     +     ---------------->           +     +
                + GW1 +         FACILITY                + GW2 +
                +     +     <------------------         +     +
                +     +                 RELEASE         +     +
                +     +      <------------------        +     +
                +++++++                                 +++++++

                         Figure 8: H.225 Facility/Reject sequence




B. Subbiah, S. Sengodan                                      [Page 10]


Internet Draft                                                      Aug 15, 1998




3.5 Use of SIP for channel negotiation


        +++++++++++                                     +++++++++++++++++
        +           + --- persistent SIP channel --     +               +
        +           +                                   +               +
        +           +                                   +               +
        + IP GW1    +                                   +  IP GW2       +
        +           +                                   +               +
        +           +  --- audio UDP channel 1 ---      +               +
        +           +  --- audio UDP channel n ---      +               +
        +++++++++++                                     +++++++++++++++++

                Figure 9. SIP in IP telephony gateways





   Session Initiation Protocol (SIP) can be used as the control
   signaling protocol between the two gateways [11]. In this case,
   the gateway that receives a call from the circuit switched side
   is the SIP client, while the remote gateway is the SIP server.
   The series of messages that are exchanged are described below.
   These messages are exchanged on the persistent signaling connection
   existing between the two gateways. Such a persistent connection
   may either be TCP or UDP.

   As with the case of H.225, the description here is not meant to be
   exhaustive but is merely for illustration. Issues such as locating
   the remote gateway by the use of proxy or redirect servers, among
   other things, are not discussed here.

   When a new call comes into the initiating gateway from the circuit
   switched side, an INVITE message is sent from the calling gateway
   (SIP client) to the called gateway (SIP server). The fields of the
   INVITE message are set as follows:

     - Request-URI: This field contains sip:phonenumber@remotegateway.
       For instance, if the number being called is +1-781-359-5112 and
       the remote gateway that can handle this call is
       gw1-boston.research.nokia.com, then the Request-URI has a value
       sip:+1-781-359-5112@gw1-boston.research.nokia.com.

     - Session Description: The session description includes the
       capability of the initiating gateway with regard to supported
       codecs, supported security parameters etc. Also included in the
       session description is the Channel Identifier (CID), the source
       UDP port and the destination UDP port.

   Upon receiving the INVITE message, the remote gateway returns the
   following messages in the sequence indicated:

     - TRYING: This message indicates to the calling gateway that the
       remote gateway has received the INVITE message successfully and
       that the remote gateway is trying to establish contact with the
       user. This is also an indication to the initiating gateway not
       to retransmit the INVITE message.

     - RINGING: This message indicates that the user has been contacted
       and that his phone is ringing.

     - SUCCESS: This message indicates that the user has answered his
       phone.

   The SUCCESS message is sent by the remote gateway only if the CID
   value indicated in the INVITE message is acceptable to the remote
   gateway. Upon receiving the SUCCESS message, the initiating gateway
   returns an ACK message back to the remote gateway. This is illust-
   rated in Figure 10.

   If the CID indicated in the INVITE message is not a valid one, the
   remote gateway returns an ERROR/FAILURE message back to the initia-
   ting gateway as indicated in Figure 11.







B. Subbiah, S. Sengodan                                      [Page 11]


Internet Draft                                                  Aug 15, 1998




                +++++++                                 +++++++
                +     +         INVITE                  +     +
                +     +     ---------------->           +     +
                + GW1 +         TRYING                  + GW2 +
                +     +    <------------------          +     +
                +     +             RINGING             +     +
                +     +    <------------------          +     +
                +     +     SUCCESS                     +     +
                +     +    <------------------          +     +
                +     +         ACK                     +     +
                +     +       ---------------->         +     +
                +++++++                                 +++++++


                         Figure 10: SIP Confirm sequence



                +++++++                                 +++++++
                +     +         INVITE                  +     +
                +     +     ---------------->           +     +
                + GW1 +      ERROR/FAILURE              + GW2 +
                +     +    <------------------          +     +
                +++++++                                 +++++++

                         Figure 11: SIP Reject sequence


4 Transmission errors and packet loss

   Protocols such as ATM, IP and AAL2 specify a Header Error Correction
   (HEC) to detect errors in the headers, whereas UDP offers both header
   and payload protection. The UDP checksum field in the UDP header is
   calculated for the entire UDP packet including the header and payload
   bytes. The MINI-header used for user multiplexing is 2 byte long and
   does not have any HEC field. The reason is that the mini packets are
   encapsulated within a UDP payload thus protected by the UDP checksum.
   The presence of the RTP sequence number in the RTP header facilitates
   to identify packet losses at the RTP level. Since each RTP packet
   contains a number of mini packets, packet loss at individual level
   becomes difficult. However, it is our understanding that the SN for
   individual mini packet is not necessary.

5 Application scenarios

   Some of the most obvious scenarios, in which the proposed method is
   beneficial, are shown in Figure 12. Traditional telephony system such
   as PSTN interconnected by IP telephony gateways is an ideal scenario
   where user mux method improves the bandwidth efficiency in the IP




B. Subbiah, S. Sengodan                                      [Page 12]


Internet Draft                                                  Aug 15, 1998


   network. This method can also be used in the Radio Access Network
   (RAN) of a cellular network. In cellular trunking, mux controller
   is a part of the BS and BSC/MSC connected by IP networks. User
   aggregation can be applied between BTS and BSC as well as between
   BSC and MSC.


        ++++++++++                                                  ++++++++
        +        +                                                  +      +
        + PSTN   +                                                  + PSTN +
        ++++++++++                                               +  ++++++++
                    +                                           +
                        +++++++++++                   +++++++++
                        +         +                   +       +
                        +         +                   +       +
                        + IP GW ++++++  IP NETWORK ++++ IP GW +
                        +         +                   +       +
                    +   +         +                   +       +
        +++++++++++     +         +                   +       +     +++++++
        +         +     +++++++++++                   +++++++++ +++++     +
        + GSM     +                                                 + GSM +
        +++++++++++                                                 +++++++


                Figure 12. Application scenario of User mux in RTP


6 Security Considerations

   There are no security considerations beyond those addressed in RTP
   itself. The multiplexing protocol can make use of whatever encryption
   and authentication schemes are present in RTP, SIP, H.323 or other
   relevant protocols. For instance, the multiplexed media stream could
   be secured by securing the UDP ports using IPSEC. The signaling and
   control channels could be secured either by the use of IPSEC or TLS.
   Application level security as specified in SIP and H.235 may also be
   incorporated.

7 Comparison of User mux in RTP and traditional RTP/UDP/IP

   The important reason for multiplexing small size packets into a
   single RTP payload is that the RTP/UDP/IP overhead for each packet
   can be reduced. For example, the RTP/UDP/IP overhead is 66.7% in case
   of 20 byte G.723.1 packet and 80% for a 10 byte G.729 packet.
   Considering that IP telephony gateways transfer 100s of user at any
   given time, the total bandwidth requirement including the overhead
   is very high. The bandwidth requirement for a traditional scheme
   (RTP/UDP/IP) is compared to user mux in RTP and the results are shown
   in Table 2. The results indicate that the bandwidth requirement to
   transport same number of users through user mux is very low compared
   to the traditional IP telephony (RTP/UDP/IP) method.






B. Subbiah, S. Sengodan                                      [Page 13]


Internet Draft                                                  Aug 15, 1998


---------------------------------------------------------------------
# users      No Mux           User Mux        No Mux        UserMux
            (G.723.1)        (G.723.1)        (G.729)       (G.729)
---------------------------------------------------------------------
10              159             68.9            400             128
30              477             185.5           1200            320
50              795             302.1           2000            512
70              1113            418.7           2800            704
90              1431            535.3           3600            896
110             1749            651.9           4400            1088
130             2067            768.5           5200            1280
150             2385            885.1           6000            1472
170             2703            1001.7          6800            1664
190             3021            1118.3          7600            1856
210             3339            1234.9          8400            2048
230             3657            1351.5          9200            2240
250             3975            1468.1          10000           2432
----------------------------------------------------------------------

Table 2. Bandwidth requirements in Kbps for user mux and IP methods


   A comparison of percentage overhead for two different speech codecs
   is shown in Table 3. The overhead due to RTP/UDP/IP is constant for
   both codecs. User mux in RTP method is able to multiplex small
   packets into a single RTP/UDP/IP payload thus reducing the overhead
   to minimum. The overhead comparison on both codecs proves that user
   mux in RTP is very efficient in reducing the overhead.


-------------------------------------------------------------------
#Users  Mux(G.729)      IP (G.729)      Mux(G.723.1)    IP (G.723.1)
-------------------------------------------------------------------
10      37.5            80              23.07692308     66.7
30      25              80              14.28571429     66.7
50      21.875          80              12.28070175     66.7
70      20.45454545     80              11.39240506     66.7
90      19.64285714     80              10.89108911     66.7
110     19.11764706     80              10.56910569     66.7
130     18.75           80              10.34482759     66.7
150     18.47826087     80              10.17964072     66.7
170     18.26923077     80              10.05291005     66.7
190     18.10344828     80              9.952606635     66.7
210     17.96875        80              9.871244635     66.7
230     17.85714286     80              9.803921569     66.7
250     17.76315789     80              9.747292419     66.7
------------------------------------------------------------------

   Table 3. Comparison of % overhead due to IP and user mux in RTP


8 Advantages of user multiplexing in RTP

   The first advantage of using the proposed method between IP telephony



B. Subbiah, S. Sengodan                                      [Page 14]


Internet Draft                                                  Aug 15, 1998

   gateways is the bandwidth efficiency. The second advantage of sharing
   a single RTP/UDP/IP is that the number of UDP connections is reduced
   between gateways. For example, in the proposed user multiplexing
   method a single UDP connection can be shared by a maximum of 256
   users. The third advantage is that the less chances for traffic
   congestion at intermediate IP routers, because the proposed method
   reduces the number of IP packets by multiplexing mini packets in a
   single RTP payload. Despite the multiplexing effect, user multiplex-
   ing in RTP does not cause any problems in the IP network since RTP
   payload (mini packets) is transparent to the intermediate IP routers.
   The user mux method requires minimal effort on standardization and
   could be implemented as an add-on module to the existing telephony
   gateways.




9 Comparison of three different proposals

   We have found two other proposals [9,10] submitted as IETF drafts to
   the AVT group. We have compared our proposal with others in terms of
   known performance metrics. Table 4 summarizes the results of the
   comparison.


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                    +    Nokia         +     Lucent   +    Hitachi+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                    +                  +              +           +
+Reducing overhead   +  Very good       +   Very good  +     ok    +
+                    +                  +              +           +
+Bandwidth efficiency+  Very good       +   Very good  +     ok    +
+                    +                  +              +           +
+Additional header   +    yes           +    yes       +  Not known+
+                    + (2 bytes/pkt)    + (2 bytes/pkt)+           +
+                    +                  +              +           +
+Assembly and        +   Simple         +    Hard      +   Simple  +
+de-assembly         +                  +              +           +
+                    +                  +              +           +
+Max # of users      +                  +              +           +
+for multiplexing    +     256          +    256       +  Not known+
+                    +                  +              +           +
+Mini packet size    + Variable         +  Variable    +  Variable +
+                    + (0 ~64)          +(req. known   +           +
+                    +                  +   profiles)  +           +
+                    +                  +              +           +
+Channel association + Required         +  Required    +   Required+
+(signaling)         +                  +              +           +
+                    +                  +              +           +
+Padding mux         + Not required     +    Required  + Not req   +
+header              +                  +              +           +
+                    +                  +              +           +
+Multiplex timer     + Proposed         + Not proposed + Not prop  +
+                    +                  +              +           +
+Dynamic capability  + Possible         + Not possible + Not poss  +
+  exchange          +                  +              +           +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

   Table 4. Comparison of different approaches on user multiplexing
            in RTP payload


B. Subbiah, S. Sengodan                                      [Page 15]


Internet Draft                                            Aug 15, 1998


10 Conclusion

   A new method to multiplex speech samples from a number of users in
   a RTP payload is proposed. It is shown that this method reduces the
   overhead for small packets, improves the bandwidth efficiency, lowers
   the chances for congestion at intermediate IP routers and enhances
   the scalability of the gateways. A new control signaling procedure to
   negotiate a channel between peer gateways is also proposed. The
   advantages of this method justify the need for such a mechanism
   between gateways that interconnect PSTN and GSM users.

11 Full Copyright Statement

   Copyright (C) The Internet Society (1998). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.

   However, this document itself may not be modified in any way, such as
   by removing the copyright notice or references to the Internet Soci-
   ety or other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be fol-
   lowed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

12 Authors' Addresses

   Barani Subbiah, Senthil Sengodan
   Nokia Research Center
   3 Burlington Woods Dr., Ste. 260
   Burlington, MA - 01803, USA

   baranitharan.subbiah@research.nokia.com
   senthil.sengodan@research.nokia.com


B. Subbiah, S. Sengodan                                      [Page 16]


Internet Draft                                                  Aug 15, 1998



13 Bibliography

   [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a
       transport protocol for real-time applications, Request for
       Comments(Proposed Standard) 1889, Internet Engineering Task
       Force, Jan. 1996.

   [2] International Telecommunication Union, Coding of speech at 8
       kbit/s using conjugate-structure algebraic-code-excited linear-
       prediction, Recommendation G.729, Telecommunication Standardi-
       zation Sector of ITU, Geneva, Switzerland, Mar. 1996.

   [3] H. Schulzrinne, RTP profile for audio and video conferences with
       minimal control, Request for Comments (Proposed Standard) 1890,
       Internet Engineering Task Force, Jan. 1996.

   [4] ITU-T Recommendation  G.723.1 (1995) "Dual  Rate  Speech  Coder
       For Multimedia Communications Transmitting  At  5.3  And  6.3
       kbit/s"

   [5] ITU-T Recommendation H.225.0 (1998): " Media Stream Packetization
       and Synchronization for Visual Telephone Systems on Non-Guarant-
       eed Quality of Service LANs ".

   [6] ITU-T Recommendation H.245 (1998): "Control of communications
       between Visual Telephone Systems and Terminal Equipment". ITU-T
       Recommendation H.246 (1998) "Interworking of H.series multimedia
       terminals"

   [7] ITU-T Recommendation H.323 (May, 1996): Visual Telephone Systems
       and Equipment for Local Area Networks Which Provide a Non-Guara-
       nteed Quality of Service.

   [8] ITU-T Recommendation H.323 (January, 1998): Packet Based Multi-
       media Communications Systems

   [9] J. Rosenberg and H. Schulzrinne: An RTP payload format for user
       multiplexing, IETF draft, work in progress, May 1998.

   [10] K. Tanigawa, T. Hoshi and K. Tsukada: A RTP simple multiplexing
        transfer method for Internet telephony gateway, IETF draft,
        work in progress, June 1988

   [11] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg: SIP:
        Session Initiation Protocol, IETF draft, work in progress,
        July 1998.








B. Subbiah, S. Sengodan                                  [Page 17]