[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

AVT WG                                                       J. Peterson
Internet-Draft                                                   NeuStar
Expires: January 10, 2005                                   J. Rosenberg
                                                             dynamicsoft
                                                           July 12, 2004


       A Multiplexing Mechanism for the Real-Time Protocol (RTP)
             draft-peterson-rosenberg-avt-rtp-ssrc-demux-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2005.

Copyright Notice

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

Abstract

   This document defines a mechanism for the Real-Time Protocol (RTP)
   that allows multiple RTP sessions to be demultiplexed at a single
   port.  Accordingly, it also requests that the IANA allocate assigned
   ports for the use of RTP with three applications: voice, video and
   text.  A similar mechanism is proposed for the Real-Time Control
   Protocol (RTCP).  The use of this mechanism is confined to a strict
   domain of applicability.




Peterson & Rosenberg    Expires January 10, 2005                [Page 1]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Multiple Ports vs. Single Port Multiplexing  . . . . . . . . .  4
   3.  Applicability of this Mechanism  . . . . . . . . . . . . . . .  5
   4.  RTP and SSRC Multiplexing  . . . . . . . . . . . . . . . . . .  7
   5.  Negotiating Usage in SDP . . . . . . . . . . . . . . . . . . .  8
     5.1   Specifying a Port in SDP . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     7.1   Registration for SDP Attributes  . . . . . . . . . . . . . 11
     7.2   Registration for SIP option-tag  . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 11
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14


































Peterson & Rosenberg    Expires January 10, 2005                [Page 2]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


1.  Introduction

   The Real-Time Protocol (RTP) specification (RFC 3550) [1]) Section 3
   notes that "RTP depends upon the lower-layer protocol to provide some
   mechanism such as ports to multiplex the RTP and RTCP packets of a
   session." As such, there is no standard port over which RTP traffic
   flows; ephemeral ports are generally selected for RTP connections.
   While this simplifies the implementation of RTP as a protocol, it
   also gives rise to problems for applications that use RTP.  Notably,
   it interferes with the operation of Network Address Translators
   (NATs, [8]).  It also makes it hard for firewall administrators to
   implement layer-4 policies for RTP, since the ports over which RTP
   travels cannot be anticipated.

   As such, this document proposes a mechanism for RTP that would allow
   multiple RTP sessions to be multiplexed at a single transport-layer
   port.  A given host might instruct several peers, for example, to all
   send media (using this extension) to the same transport address on
   that host.  This mechanism leverages the synchronization source
   (SSRC) parameter of the RTP header to multiplex and demultiplex
   discrete RTP sessions that are sent to the same IP address and port.

   Multiplexing RTP for this purpose would yield little benefit if the
   Real-Time Control Protocol (RTCP) did not admit of a similar
   multiplexing scheme.  Today, an RTCP session is paired with an RTP
   session (typically, though not always, RTCP runs on a port one port
   higher than RTP).  This proposal continues to manage RTP and RTCP on
   separate ports, but only one port will be required for RTCP.

   RTP today is used to carry data associated with a number of common
   media types.  These include real-time voice, video and text traffic.
   Since it desirable for firewall administrators to be able to
   implement policies that allow or disallow particular media types,
   this document requests that the IANA allocate separate standard RTP
   ports for each of the three common media types.  The 'rtp-voice' port
   would also serve as a default port for all other media types, though
   if in the future other media types for RTP become popular, they might
   also warrant new media types.

   The motivations for the existing RTP lower-layer multiplexing
   decision are analyzed in Section 2, and current RTP operation is
   compared with the use of the proposed extension.  The use of the SSRC
   to multiplex traffic is described in Section 4, and the problems with
   sending multiple RTP sessions to the same transport address described
   in Section 5.2 of RFC3550 are also examined.  The use of this
   mechanism is confined to the domain of applicability described in
   Section 3, which provides a high-layer scheme for negotiating support
   of this mechanism and reverting back to standard RTP if it is



Peterson & Rosenberg    Expires January 10, 2005                [Page 3]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


   unsupported.

2.  Multiple Ports vs. Single Port Multiplexing

   RTP runs over an existing transport protocol, such as UDP or DCCP
   [7].  All transport protocols by definition carry a port number -
   port numbers differentiate services or applications that are using a
   single Internet address on a device.  Therefore, during the design of
   RTP, a decision was made that providing an indicator for handling
   multiplexing within RTP would be undesirable because the transport
   protocol under RTP already necessarily supports multiplexing through
   multiple ports - adding capability for multiplexing within RTP would
   be redundant.

   Accordingly, selection of a port for RTP is deferred to the
   application layer.  Applications typically bind to a random available
   port to listen for RTP, and then inform their peers (through an
   out-of-band protocol like the Session Description Protocol (SDP [6])
   the port to which media should be sent.  However, carriage of RTP
   over multiple ports has created a number of obstacles to the
   widespread deployment of RTP.  The most infamous of these is the
   interaction with firewalls and Network Address Translators (NATs).

   Typically, firewall administrators are reluctant to allow traffic on
   arbitrary ports to enter (and in some cases exit) their network.
   However, in order to allow the random ports selected by RTP, firewall
   administrators have little recourse.  If RTP (and RTCP) ran over
   well-known assigned ports, firewall administrators could make a
   trivial decision to allow traffic over such ports into their network.

   NAT traversal presents an even more troublesome obstacle, since its
   impacts on RTP traffic are not necessarily side-effects of policy
   enforcement, but are innate in the deployment of many enterprises and
   residential networks.  Since NATs are fielded in order to conserve
   IPv4 address resources by allowing multiple hosts to share a single
   IP address, many users that would like to connect an IP telephone to
   their existing residential network discover only inadvertently that
   their NAT blocks RTP traffic.

   In the absence of a single RTP port, a whole cottage industry of
   standard and proprietary protocols and devices have emerged that
   facilitate RTP's traversal through firewalls and NATs.  The MIDCOM
   and NSIS protocols, ICE [4] and its components (STUN [5] and TURN
   [9]) are IETF standards that have been developed for this purpose.
   Specifying a standard-port variant of RTP will not obviate the need
   for mechanisms like ICE, but it does significantly simplify
   authorized firewall traversal (essentially eliminating the need for
   special-purpose ALGs or firewall controllers designed to permit VoIP



Peterson & Rosenberg    Expires January 10, 2005                [Page 4]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


   while maintaining network security), and it helps with some limited
   NAT cases.

   Given this problem space, there seems to be ample motivation for a
   way of consolidating all RTP traffic for a single IP address down to
   a single port that can easily be managed by middlebox administrators.

   Section 5.2 of RFC3550 anticipates that applications designers might
   want to multiplex several RTP streams over the same port, and
   normatively recommends against this practice.  Five major points are
   raised against multiplexing in that section.  The first three of
   these points, as RFC3550 notes, do not effect mechanisms that use the
   synchronization source (SSRC) for multiplexing.  Of the remaining
   two, point 4 notes that an RTP mixer would not be able to combine
   streams of incompatible media into a single stream; however, since
   the mechanism presented in this document still uses different ports
   for different media types, this is not immediately applicable here.
   Similarly, point 5 establishes more problems with sending different
   varieties of media over the same port, and also notes that
   establishing different network paths or resource allocations for
   different sessions is rendered impossible.  This last point is valid
   in networks where certain quality of service (QoS) mechanisms are
   used.  In order for these mechanisms to work with a standard-port
   variant of RTP, resource allocation for RTP would need to evolve into
   a form similar to that used for TCP, where a 5-tuple is used to
   identify network resources rather than just the pairs of network
   addresses and ports.  While this presents hurdles for the deployment
   of such QoS mechanisms with standard-port RTP, they are not
   insurmountable hurdles.  On balance, the trade-off seems to favor the
   specification of standard-port RTP.

3.  Applicability of this Mechanism

   If the mechanism proposed in this document is employed, but
   understood by only one of the parties in an RTP session, the
   consequences for the protocol could be very negative (i.e.  in all
   likelihood, RTP would not function properly).  In order to prevent
   this eventuality, implementations MUST NOT use this mechanism without
   a higher-layer negotiation mechanism that allows implementations to
   back off to traditional (unmodified) RTP.

   Specifically, implementations of this session MUST negotiate the use
   of the extension via SDP.  Furthermore, implementations that use the
   Session Initiation Protocol (SIP [2]) to carry such SDP MUST supply a
   Require header field value with the 'sp-rtp' option-tag defined in
   Section 5.

   This mechanism is of primary value for traversing firewalls, in



Peterson & Rosenberg    Expires January 10, 2005                [Page 5]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


   keeping with the policies of firewall administrators, in the absence
   of Network Address Translators.  When NATs are used, the
   applicability of this mechanism is more limited.  The following
   scenarios are appropriate for use with standard-port RTP:
      If a single RTP implementation is behind a NAT, then the
      administrator of the NAT can use a simple packet-forwarding rule
      to forward all packets directed to standard RTP ports to the IP
      address of the RTP implementation.  This could be useful in some
      residential deployments, for example.
      If multiple RTP implementations are behind a NAT, then there must
      be a single host which acts as a media relay for that network,
      effectively demultiplexing and reflecting traffic to the RTP
      implementations as appropriate.  TURN servers could readily be
      adapted to this purpose, and furthermore, many enterprises
      effectively have such relays already, in the form of IP PBXs and
      various sorts of devices that manage call centers.

   However, even in these instances, this mechanism does not interact
   well with the usage of STUN as a means for obtaining an IP address
   and port to signal as the media destination.  The problem is that the
   NAT will modify the source port of the outbound STUN request, and the
   source port it selected depends on the algorithms it implements,
   along with the state of the NAT itself.  As a result, a client is
   likely to get back an IP address and a random port.  This random port
   will not match any of the default ports for RTP traffic.  This will
   make it impossible for the client to receive RTP traffic on the
   default ports.

   This problem is mitigated somewhat by NATs that provide a port
   preservation property.  Port preservation is defined as a property
   whereby a NAT tries to preserve the source port in the outgoing
   packet.  However, even in NATs that provide port preservation, there
   is a possibility that the port is already in use for another binding.
   In such a case, the NAT is forced to allocate a different port to the
   client.  Thus, if a client sends its STUN messages from the default
   RTP port, port preservation makes it possible that the STUN results
   will indicate the same port, but there is no guarantee.

   Eventually, as NAT's become less transparent and more controllable,
   using techniques like MIDCOM and NSIS, a client could explicitly ask
   for a binding to the necessary RTP port.

   Fortunately, the mechanism described here is very compatible with
   ICE.  ICE is based on the idea that a client might be able to receive
   RTP traffic at a multiplicity of IP addresses and ports.  The default
   RTP port just becomes one other possibility, and ICE's peer-to-peer
   connectivity checks would be used to verify that RTP traffic could
   flow to the default RTP port.



Peterson & Rosenberg    Expires January 10, 2005                [Page 6]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


   Indeed, ICE provides a good transition mechanism to aid in the
   gradual adoption of the approach described here.  ICE can be
   configured to prefer RTP traffic that connects to the default port,
   but would allow it to work to other ports when the default doesn't
   work (as in the STUN case above).  As the STUN cases reduce in
   frequency (with the advent of more controllable devices and/or the
   usage of TURN servers when multiple clients behind a NAT require RTP
   services), ICE will discover, more and more frequently, that the
   default RTP port works.

   As this work progresses, it is expected that further work will be
   done on the interaction between standard-port RTP, STUN, TURN and
   ICE.

   An additional limitation of this mechanism is that the usage of RTP
   by multiple applications on a single host can be problematic, given
   common RTP implementations today.  Any application that binds to an
   assigned port for RTP becomes the only application that can receive
   such RTP packets on a host.  However, the authors believe that there
   are enough devices (like Internet telephones) that would only host a
   single RTP application that this extension would still have
   significant applicability without changes to existing RTP
   implementations.  In environments where multiple applications would
   like to use RTP on a single host, RTP implementations would need to
   provide system-wide services.

   The applicability of this mechanism to multicast scenarios is a
   subject for further study.  The intended use of this mechanism is in
   unicast scenarios, most likely those RTP sessions associated with the
   Session Initiation Protocol (SIP).

4.  RTP and SSRC Multiplexing

   SSRC multiplexing does not require any extension to RTP.  It reuses
   the 32-bit synchronization source (SSRC) header, which already exists
   in RFC3550, to differentiate discrete streams originating from a
   single source.

   The most obvious change to RTP behavior prescribed by this draft is
   that RTP server applications would no longer bind to ephemeral ports,
   but rather to one or more standard ports for various media types,
   depending on the capabilities and needs of the application.  RTP
   implementations would also be required the multiplex and demultiplex
   traffic according to the SSRC, and render the results appropriately
   to higher level applications.  This requires changes to existing RTP
   APIs.

   RFC3550 states that the SSRC is created randomly and unilaterally,



Peterson & Rosenberg    Expires January 10, 2005                [Page 7]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


   and that it must be globally unique within a particular RTP session
   (which is especially meaningful in ad-hoc conferences, or when
   multiple source devices are used to provide media for a single
   participant).  In order to use the mechanism described in this
   document, the SSRC is negotiated collaboratively with other
   participants in a session using a higher-layer protocol like the
   Session Description Protocol (SDP).  More information about
   negotiating the SSRC in SDP and SIP is given in Section 5.  Without
   this higher-layer negotiation, this mechanism MUST NOT be used.
   Additionally, the SSRC negotiated by an RTP application MUST be
   unique across all RTP sessions on the host (or more specifically,
   associated with the same network address), rather than merely unique
   across participants in a particular RTP session.

   RTCP also uses the SSRC parameter.  Like RTP, RTCP server
   applications would bind to standard ports rather than ephemeral
   ports, and similar multiplexing/demultiplexing operations are
   required to associate RTCP traffic with the proper multiplexed
   session.

5.  Negotiating Usage in SDP

   The use of this mechanism with the Session Description Protocol (SDP)
   requires the addition of new attributes to SDP that communicate the
   values of the SSRC when using the offer/answer model (described in
   RFC3263).  It also eliminates the need for RTP port selection in SDP.

   Thus, this mechanism defines two new attributes (a= lines) that can
   appear in SDP: 'ssrc-upper' and 'ssrc-lower'.  Each of these
   attributes offers 16 bits of the SSRC that will be received by each
   participant in a RTP session.  When an SDP offer is made, the offerer
   specifies the upper 16 bits of the SSRC in RTP that they will receive
   in the 'ssrc-upper' parameter, and specifies the lower 16 bits of the
   SSRC that the answerer will receive in the 'ssrc-lower' parameter.
   When the SDP answer is formulated, the answerer again specifies the
   upper 16 bits of the SSRC that they will receive in the 'ssrc-upper'
   parameter, and specifies the lower bits of the SSRC that the offerer
   will receive in the 'ssrc-lower' parameter.  In both cases the
   generation of these bits MUST be random (following the guidance given
   in RFC3550 Appendix A) and MUST be unique across all RTP sessions
   supported by the host.

   So, for example, in an offer:


   a:ssrc-upper=0x6f12
   a:ssrc-lower=0xaa9f




Peterson & Rosenberg    Expires January 10, 2005                [Page 8]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


   and in the answer:


   a:ssrc-upper=0x8b3b
   a:ssrc-lower=0x110c

   In this example, the RTP from the offerer to the answerer would have
   SSRC 0x8b3baa9f, and the SSRC from the answerer to offerer would be
   0x6f12110c.

   The primary motivation for this collaborative agreement on SSRCs is
   to allow this mechanism to work with cases where SIP forking has
   occurred.  Without this collaboration on SSRC, it would be difficult
   to distinguish media coming from different SIP user agents that were
   reached by an offer.

   Note that this mechanism does not eliminate the potential for
   collisions in SSRC selection described in RFC3550 Section 8.1.  In
   fact, since each party to an offer/answer in a SIP forking case
   specifies only 16 bits of their SSRC, the potential for collisions
   may be higher.  However, given a reasonable amount of randomness, the
   odds of a collision remain very low, and SDP could conceivably be
   used to renegotiate the SSRC in case of a collision.

5.1  Specifying a Port in SDP

   The presence of the 'ssrc-upper' and 'ssrc-lower' attributes in an
   SDP offer signals that this use of this mechanism is desired.  SDP
   answerers MUST NOT supply 'ssrc-upper' and 'ssrc-lower' attributes in
   an SDP answer if they were not present in the offer; if the answerer
   requires the use of this extension, they SHOULD refuse the initial
   offer and formulate an appropriate counteroffer.

   SDP attributes that are not understood are ignored.  Consequently, if
   an SDP offer containing 'ssrc-upper' and 'ssrc-lower' is answered
   with an SDP that does not contain these attributes, the offerer can
   determine that this extension is unsupported.  However, this would
   not prevent the answerer from sending RTP media based on its
   understanding of the offer, which could have undesirable
   consequences, especially in SIP cases where the SDP offer is forked
   to multiple endpoints.

   When SIP INVITEs are used to carry SDP that contains the 'ssrc-upper'
   and 'ssrc-lower' attributes, those messages MUST have a SIP Require
   header field value containing the option-tag 'sp-rtp'.  If this
   option is unsupported by recipients of such SIP request, a suitable
   SIP error code will be sent in the backwards direction, and the
   parties may subsequently attempt to renegotiate a session without



Peterson & Rosenberg    Expires January 10, 2005                [Page 9]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


   supporting this mechanism.

   SDP offers and answers use a field of the m= line to specify the port
   to which media should be sent.  In the context of this mechanism,
   since standard port numbers are used, there is no need to signal a
   media port in the m= line.  Moreover, it is undesirable, when this
   extension is used, to allow a port number to be specified (since this
   would allow applications potentially to use the voice port for video
   media, and the like).  Therefore, the 'port' value of the m= line of
   SDP using this mechanism MUST be set to 99999.  This is an invalid
   UDP port, and thus implementations which do not support this
   mechanism will be unable to send or receive media at this port.
   Implementations that support this mechanism MUST ignore the value
   99999 in the port field of the m= line, and instead use the media
   value of the m= line to determine the port to which they will send
   media.

   In particular, if the media value of the m= line is 'audio', the port
   to which media will be sent MUST be the standard 'rtp-audio' port;
   similarly, 'video' MUST use the 'rtp-video' port, and 'text' MUST use
   the 'rtp-text' port.  All other media values default to the
   'rtp-audio' port, unless otherwise specified in a standards-track RFC
   that extends this specification.  The IANA will assign port numbers
   for these ports as per the instructions in Section 7.

6.  Security Considerations

   If the mechanism described in this document is used by RTP
   applications, firewall administrators will gain the ability to create
   firewall policies to control admission of RTP to their networks with
   a simple transport-layer filter.  Like any other port-based policy,
   however, it is not a perfect instrument of security.  Mischievous
   users have been known to send traffic over well-known ports (such as
   port 80) that is not appropriate for the IANA-registered application
   of that port.  So while this document specifies, for example,
   separate RTP ports for voice and video, there is nothing that
   prevents a misbehaving application from accidentally or intentionally
   sending RTP video over the RTP voice port, and so on.  For more
   information on the limitations of port-based security policies, see
   [10].

   That much said, this approach does increase the firewall-friendliness
   of RTP significantly.  In order to support an RTP implementation
   based entirely on ephemeral ports, firewall administrator today would
   have to open vast ranges of ephemeral ports to any applicable UDP
   traffic.  If the mechanism described in this draft were widely
   deployed, firewall administrators would need to open only a handful
   of ports in order to allow RTP traffic.  Since in many environments,



Peterson & Rosenberg    Expires January 10, 2005               [Page 10]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


   network administrators might have to remove firewalls in order to
   allow VoIP services on ephemeral ports, this mechanism improves the
   security of deployments.

   The best known practice for securing RTP is sRTP.  Implementers
   should strongly consider the use of sRTP to authenticate the source
   of a media stream.  The behavior suggested in this draft for
   constructing SSRCs is not a substitute for cryptographic
   authentication of a media source.  The effects of this mechanism on
   sRTP are a subject for further study.

7.  IANA Considerations

   This document requests that the IANA allocate three standard ports
   associated with RTP media types: one port for 'rtp-audio', one or
   'rtp-video', and one for 'rtp-text.' This document also requests that
   the IANA allocate three standard ports for RTCP, one associated with
   each of the RTP ports described above: 'rtcp-audio, 'rtcp-video' and
   'rtcp-text'.  Further, this document requests that the assignment
   ports be ascending, and in the following order: rtp-audio,
   rtcp-audio, rtp-video, rtcp-video, rtp-text, rtcp-text.  The first
   assigned port number must be an even number.

   Future standards-track specifications may request the assignment of
   additional ports that will be used by this mechanism.  Such
   specifications MUST identify ports corresponding to the top-level
   media values that appear in the m= line of SDP.

7.1  Registration for SDP Attributes

   This document requests that the IANA allocate two new media-level
   attributes for SDP: 'ssrc-upper' and 'ssrc-lower'.

   [Ed Note: The formal registrations TBD]

7.2  Registration for SIP option-tag

   This document requests that the IANA allocate a new option-tag for
   SIP: 'sp-rtp'.

   [Ed Note: The formal registrations TBD]

8.  References

8.1  Normative References

   [1]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", RFC



Peterson & Rosenberg    Expires January 10, 2005               [Page 11]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


        3261, May 2002.

   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3550, July 2003.

   [3]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", RFC 2119, March 1997.

   [4]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
        Methodology for Network Address Translator (NAT) Traversal for
        Multimedia Session Establishment Protocols",
        draft-ietf-mmusic-ice-01 (work in progress), February 2004.

   [5]  Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
        Simple Traversal of User Datagram Protocol (UDP) Through Network
        Address Translators (NATs)", RFC 3489, March 2003.

   [6]  Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
        Description Protocol", draft-ietf-mmusic-sdp-new-18 (work in
        progress), June 2004.

   [7]  Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion
        Control Protocol (DCCP)", draft-ietf-dccp-spec-06 (work in
        progress), February 2004.

8.2  Informative References

   [8]   Senie, D., "Network Address Translator (NAT)-Friendly
         Application Design Guidelines", RFC 3235, January 2002.

   [9]   Rosenberg, J., Huitema, C. and R. Mahy, "Traversal Using Relay
         NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress),
         February 2004.

   [10]  St. Johns, M. and G. Huston, "Considerations on the use of a
         Service Identifier in Packet Headers", RFC 3639, October 2003.

   [11]  Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.











Peterson & Rosenberg    Expires January 10, 2005               [Page 12]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


Authors' Addresses

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520
   US

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz/


   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ  07054-2711
   US

   Phone: +1 973/952-5050
   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.dynamicsoft.com/




























Peterson & Rosenberg    Expires January 10, 2005               [Page 13]


Internet-Draft           RTP SSRC Multiplexing                 July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Peterson & Rosenberg    Expires January 10, 2005               [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/