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

Versions: 00 01 02 03 04 05 06

rtcweb                                                         D. Worley
Internet-Draft                                                   Ariadne
Intended status: Standards Track                        February 8, 2013
Expires: August 12, 2013


                  A Generic Bundling Mechanism for SDP
                       draft-worley-sdp-bundle-00

Abstract

   This is an introduction to m= line-based multiplexing based on a
   series of examples.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 12, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Worley                   Expires August 12, 2013                [Page 1]

Internet-Draft                SDP Bundling                 February 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Desiderata . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Introduction in Pictures . . . . . . . . . . . . . . . . . . .  9
     5.1.  Example:  audio and video  . . . . . . . . . . . . . . . .  9
     5.2.  Example:  two audio and two video  . . . . . . . . . . . . 13
     5.3.  Example:  virtual classroom:  one audio, two videos,
           and a group of videos  . . . . . . . . . . . . . . . . . . 15
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  Revision History . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  draft-worley-sdp-bundle-00 . . . . . . . . . . . . . . . . 20
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     10.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22































Worley                   Expires August 12, 2013                [Page 2]

Internet-Draft                SDP Bundling                 February 2013


1.  Introduction

   TBD
















































Worley                   Expires August 12, 2013                [Page 3]

Internet-Draft                SDP Bundling                 February 2013


2.  Terminology

   [Insert RFC 2119 boilerplate here.]

   The important RFCs in this area use inconsistent terminology.  Here,
   we use:

   - "transport association" and "5-tuple"

   A 5-tuple is the description of a particular transport association,
   such as a TCP connection.  The components of the 5-tuple are the
   identity of the protocol being used and the addresses and transport
   ports of the two endpoints.

   - "media"

   We use this term for (1) media content, considered in an abstract
   way, that is, without consideration of its particular encoding or the
   framing information around it, and (2) the particular bits and bytes
   used to encode and transmit the abstract media content.

   - "multimedia session"

   We use this term for the totality of the media that is transmitted/
   received as described by a particular session description (i.e., SDP
   instance).  This is taken from RFC 4566 section 2.

   - "RTP session"

   We use this term for the totality of the media that is transmitted/
   received as described by a particular media description (i.e., m=
   line) in a particular session description.  Since each media
   description specifies one 5-tuple, RTP sessions correspond to
   transport associations.  This is taken from RFC 3550 section 2.2.
   (In SIP usage (RFC 3264), this is called a "media stream", which term
   is used in RTP usage to refer to the RTP with a single SSRC.)

   It is understood that the RTP session can be dissected into "media
   streams" that have separate SSRCs, but that is not relevant in this
   analysis.  E.g., in SIP telephony, various activities of the far
   endpoint can cause the ultimate source of the audio (and hence the
   SSRC) to change dynamically, but each new source stands in for the
   previous one seamlessly in the user interface.

   (However, there is a way (RFC 4566 section 5.14) for an m= line to
   specify a set of ports and thus a set of related RTP sessions.  We do
   not address that.)




Worley                   Expires August 12, 2013                [Page 4]

Internet-Draft                SDP Bundling                 February 2013


   In general, further agreed terminology is needed to describe the
   aggregate of media possessing a particular SSRC, etc., but that is
   not needed for this discussion.
















































Worley                   Expires August 12, 2013                [Page 5]

Internet-Draft                SDP Bundling                 February 2013


3.  Overview

   The central idea of bundling is to multiplex the media that would be
   several RTP sessions into one RTP session, with particular emphasis
   on allowing one transport association to carry media that are
   presented to the higher, application layer, as multiple RTP sessions.

   At the interface between the SDP-configured layer and the lower,
   transport layer, we want the media organized into a single RTP
   session.  The transport-related properties of the RTP session (e.g.,
   transport 5-tuple, encryption, ICE) will be described by the
   transport-related attributes of a single media description.

   At the interface between the SDP-configured layer and the higher,
   application layer, we want to have the media organized into several
   RTP sessions.  The application-related properties of the RTP session
   (e.g., media type and label) will be described by the application-
   related attributes of separate media descriptions.

   (There are some attributes (e.g., bandwidth limitation) that can
   apply separately to both the bundled RTP session and the constituent
   RTP sessions.)

   However, we do not include the payload type numbers as information
   available to the application; only the codec identity and its
   parameters are accessible to the application.  This gives the
   bundling mechanism freedom to place constraints on the use of payload
   types.

   The application may distinguish between the media of each constituent
   RTP session in ways that are not determinable from the properties of
   the media themselves.  (E.g., in telepresence systems or in systems
   where multiple video feeds are to be assembled into one large image,
   multiple video streams have non-trivial relationships that are
   specified by additional application-level SDP attributes.  Or there
   may be several RTP sessions whose media types are the same but whose
   logical roles in the multimedia session are not interchangeable.)

   The application considers all media within a particular RTP session
   to be a single logical media stream, regardless of changes in codec
   (payload type) and SSRC (which often happen because the ultimate
   source of the media changes).  E.g., a SIP telephone sends/receives
   SDP with one audio media description, and all RTP sent/received
   within that RTP session is connected to/from the telephone's user
   interface, despite that far-end call transfer events or audio
   conference processing may cause the payload type and SSRC of received
   RTP to change without warning.




Worley                   Expires August 12, 2013                [Page 6]

Internet-Draft                SDP Bundling                 February 2013


4.  Desiderata

   Desiderata for a "bundling" mechanism in SDP.

   * Desiderata for a bundling mechanism

   (I use the term "desiderata" -- "things that are desired" -- rather
   than "requirements", because we may discover that we can't optimally
   satisfy all of these criteria.)

   DES 1: For each bundle, there is a group of media descriptions which
   describe the application-level RTP sessions.

   DES 2: For each bundle, there is a media description that describes
   the transport-level RTP session.

   These requirements do not specify whether the transport-level media
   description may or may not also be one of the application-level media
   descriptions.

   DES 3: Bundles may contain other bundles as constituents.

   Of course, no bundle may directly or indirectly contain itself.

   I don't expect any current implementation to implement bundles within
   bundles, but we should design the mechanism to allow this, as some
   day we will likely need it.

   DES 4: A bundle may contain zero constituents.

   A bundle with no constituents serves no purpose for the transport of
   media, but we are likely to someday need to describe such a bundle.
   (Compare that an SDP m= line is syntactically constrained to specify
   at least one payload type.  When SDP was used only to specify
   multicast sessions, this constraint was common sense.  But once SDP
   offer/answer was invented, when a media description was rejected, the
   natural construction would be an m= line with a zero port and no
   payload types.  But a payload type was syntactically required, so we
   now have to provide at least one useless payload type for rejected m=
   lines.)

   DES 5: If an answerer that does not understand the bundle mechanism
   processes an offer that contains a bundle, it must interpret it as
   the collection of application-level media descriptions, and the
   offerer must be able to properly interpret the answer that it
   produces.

   DES 6: If an answerer that does understand the bundle mechanism



Worley                   Expires August 12, 2013                [Page 7]

Internet-Draft                SDP Bundling                 February 2013


   processes an offer that contains a bundle, it must be able to (1)
   accept the bundle and selectively accept/reject each constituent RTP
   session within it, (2) reject the bundle as a whole, or (3) reject
   the bundling and selectively accept/reject each constituent RTP
   session as separate RTP sessions.

   Presumably answer (3) is like that which would be produced by an
   answerer that does not understand the bundling mechanism.

   DES 7: There must be a reliable way to demultiplex incoming RTP into
   the separate application-level RTP sessions.  Similarly, there must
   be a reliable way to demultiplex the associated RTCP information.

   I know little about RTCP, but I believe that the RTCP information is
   tagged with the SSRC about which it reports, and the SSRC is used to
   correlate the RTCP reports with the RTP sessions containing media
   with the same SSRC.  If so, RTCP demultiplexing requires no
   additional specification, as RTCP is understood in the same way as in
   non-bundled RTP.

   DES 8: The specification must specify any needed additional
   procedures for handling SSRC collisions between media sources within
   different application-level RTP sessions, as those can now collide.




























Worley                   Expires August 12, 2013                [Page 8]

Internet-Draft                SDP Bundling                 February 2013


5.  Introduction in Pictures

   This is an introduction to m= line-based multiplexing based on a
   series of examples.  Some mandatory SDP lines have been omitted from
   the examples for brevity.

5.1.  Example:  audio and video

   Here is a typical, non-bundled SDP example with both audio and video:

          o=- 2890844526 2890844526 IN IP4 host.example.com
          c=IN IP4 host.example.com
  This SDP media description ("MD") provides the transport information
  about the audio and also identifies the role of the audio from the
  application's point of view (in this case, the fact that it is the
  first audio m= line suffices to tell the application how to
  treat it).
          m=audio 10000 RTP/AVP 0 8 97
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
  This MD provides the transport information about the video and also
  describes the role of the video from the application's point of view.
          m=video 10002 RTP/AVP 31 32
          a=rtpmap:31 H261/90000
          a=rtpmap:32 MPV/90000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091

   We call the RTP that is described by each media description (MD) a
   media describee (MDee), so we have an unambiguous name for it.  The
   audio and video are carried in separate MDees.

   In m= line multiplexing, we add a special m= line to describe a
   single MDee to carry both the audio and video information:












Worley                   Expires August 12, 2013                [Page 9]

Internet-Draft                SDP Bundling                 February 2013


          o=- 2890844526 2890844526 IN IP4 host.example.com
          c=IN IP4 host.example.com
  Declare which MDs are included in the multiplexed MD:  mid:c0 is the
  multiplexed MDee, and it contains the RTP that would be sent in
  MDees c1 and c2.
          a=group:BUNDLE c0 c1 c2
  This MD provides the transport information for the multiplexed MDee,
  including any attributes which apply to the transport.  The MD also
  must provide the allowed payload types, which is the list of the
  distinct payload types specified for c1 and c2.
          m=multipart 10000 RTP/AVP 0 8 97 31 32
          a=mid:c0
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091
  This MD provides the application-level description of the audio MDee
  -- it is still the first audio m= line.  It includes any attriutes
  which apply to the audio media specifically.
          m=audio 10002 RTP/AVP 0 8 97
          a=mid:c1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
  This MD has transport information (including the port number in the m=
  line and the a=candidate attributes) to provide fallback support.
  More about that later.
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091
  This MD provides the application-level description of the video MDee
  -- it is still the first video m= line.  It includes any attriutes
  which apply to the video media specifically.
          m=video 10004 RTP/AVP 31 32
          a=mid:c2
          a=rtpmap:31 H261/90000
          a=rtpmap:32 MPV/90000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091

   RTP that is received on port 10000 is demultiplexed by the payload
   type -- PTs 0, 8, and 97 are identified as belonging to the audio
   MDee, and PTs 31 and 32 are identified as belonging to the video
   MDee.

   The answerer understands that the second and third MDs are
   incorporated into the first MD, and ignores their transport
   information.  It provides no a=candidate attributes for them in the



Worley                   Expires August 12, 2013               [Page 10]

Internet-Draft                SDP Bundling                 February 2013


   answer, and gives the dummy non-zero value "9" (the discard port) as
   the port number to show that it accepted those constituent MDs.

          o=- 2890844526 2890844526 IN IP4 answer.example.com
          c=IN IP4 answer.example.com
          a=group:BUNDLE c0 c1 c2
          m=multipart 20000 RTP/AVP 0 8 97 31 32
          a=mid:c0
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091
          m=audio 9 RTP/AVP 0 8 97
          a=mid:c1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
          m=video 9 RTP/AVP 31 32
          a=mid:c2
          a=rtpmap:31 H261/90000
          a=rtpmap:32 MPV/90000

   m= line multiplexing allows for upward compatibility in case the
   answerer does not understand multiplexing.  In that case, the
   answerer ignores the a=group line, and effectively sees the offer as
   this:


























Worley                   Expires August 12, 2013               [Page 11]

Internet-Draft                SDP Bundling                 February 2013


          o=- 2890844526 2890844526 IN IP4 host.example.com
          c=IN IP4 host.example.com
          a=group:BUNDLE c0 c1 c2
  This MD has an unknown media type, and the answerer will reject it:
          m=multipart 10000 RTP/AVP 0 8 97 31 32
          a=mid:c0
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091
  This MD is an ordinary audio MD:
          m=audio 10002 RTP/AVP 0 8 97
          a=mid:c1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091
          m=video 10004 RTP/AVP 31 32
  This MD is an ordinary video MD:
          a=mid:c2
          a=rtpmap:31 H261/90000
          a=rtpmap:32 MPV/90000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091

   So the answerer assembles this answer:























Worley                   Expires August 12, 2013               [Page 12]

Internet-Draft                SDP Bundling                 February 2013


          o=- 2890844526 2890844526 IN IP4 answer.example.com
          c=IN IP4 answer.example.com
          a=group:BUNDLE c0 c1 c2
  This MD is rejected because it is not understood:
          m=multipart 0 RTP/AVP 0
          m=audio 20000 RTP/AVP 0 8 97
  This MD is accepted.  Transport information is provided:
          a=mid:c1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091
  This MD is accepted.  Transport information is provided:
          m=video 20002 RTP/AVP 31 32
          a=mid:c2
          a=rtpmap:31 H261/90000
          a=rtpmap:32 MPV/90000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091

   Because the first MD is rejected, the offerer knows that the answerer
   has not accepted multiplexing, and it proceeds to interpret the
   second and third MDs directly.

5.2.  Example:  two audio and two video

   In this example, a presentation involves four media roles: the
   speaker's audio, the floor microphone, the video of the speaker, and
   the video of the speaker's slides.  (Blank lines are inserted for
   clarity.)  We use separate MDs because each MDee has a different
   *role*, the application will handle them in distinctly different
   ways.
















Worley                   Expires August 12, 2013               [Page 13]

Internet-Draft                SDP Bundling                 February 2013


          o=- 2890844526 2890844526 IN IP4 host.example.com
          c=IN IP4 host.example.com
          a=group:BUNDLE c0 c1 c2 c3 c4

          m=multipart 10000 RTP/AVP
          a=mid:c0

          m=audio 10002 RTP/AVP 0 8 97
          a=mid:c1
          a=label:speaker-audio
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091

          m=audio 10004 RTP/AVP 100 101 102
          a=mid:c2
          a=label:floor-mic
          a=rtpmap:100 PCMU/8000
          a=rtpmap:101 PCMA/8000
          a=rtpmap:102 iLBC/8000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091

          m=video 10006 RTP/AVP 103 104
          a=mid:c3
          a=label:speaker-video
          a=rtpmap:103 H261/90000
          a=rtpmap:104 MPV/90000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091

          m=video 10008 RTP/AVP 105 106
          a=mid:c4
          a=label:slides
          a=rtpmap:105 H261/90000
          a=rtpmap:106 MPV/90000
          a=candidate:0 1 UDP 2113601791 192.0.2.240 51091 typ host
          a=candidate:1 1 UDP 1694194431 198.51.100.32 51091 typ srflx \
              raddr 192.0.2.240 rport 51091







Worley                   Expires August 12, 2013               [Page 14]

Internet-Draft                SDP Bundling                 February 2013


5.3.  Example:  virtual classroom:  one audio, two videos, and a group
      of videos

   This example is the teacher's connection to a virtual classroom
   server.  The media is:

   - one audio channel, for sending the teacher's voice and receiving
   the voice of any selected student

   - one video channel, for sending the teacher's presentation

   - one video channel, for sending the teacher's face

   - one video channel, for receiving a dynamically varying set of
   students' faces

   The second video MDee contains a large and variable set of video
   captures.  These are handled by a single MDee because they all have
   essentially similar roles -- the application will process them as a
   set.  As Adam Roach would say, "no control surfaces are necessary to
   talk about and/or manipulate the individual streams".  In particular,
   this allows a large number of captures to be handled without
   mentioning them in the SDP, at the expense of not allowing the SDP to
   describe any of them individually.  Similarly, the number of captures
   can vary without having to renegotiate the SDP.

   Once the single transport MDee is demultiplexed based on payload type
   into the four MDees , the second video MDee is demultiplexed based on
   SSRC.

   The SDP is:




















Worley                   Expires August 12, 2013               [Page 15]

Internet-Draft                SDP Bundling                 February 2013


          o=- 2890844526 2890844526 IN IP4 host.example.com
          c=IN IP4 host.example.com
          a=group:BUNDLE c0 c1 c2 c3 c4

          m=multipart 10000 RTP/AVP
          a=mid:c0

          m=audio 10002 RTP/AVP 0 8 97
          a=mid:c1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000

          m=video 10004 RTP/AVP 103 104
          a=mid:c2
          a=label:speaker
  The teacher's face and presentation is send-only:
          a=sendonly
          a=rtpmap:103 H261/90000
          a=rtpmap:104 MPV/90000

          m=video 10006 RTP/AVP 105 106
          a=mid:c3
          a=label:presentation
          a=sendonly
          a=rtpmap:105 H261/90000
          a=rtpmap:106 MPV/90000

          m=video 10008 RTP/AVP 105 106
          a=mid:c4
          a=label:student-thumbnails
  The student video input is receive-only and limited to 24 simultaneous
  SSRCs:
          a=recvonly
          a=max-recv-ssrc:{*:24}
          a=rtpmap:105 H261/90000
          a=rtpmap:106 MPV/90000














Worley                   Expires August 12, 2013               [Page 16]

Internet-Draft                SDP Bundling                 February 2013


6.  Acknowledgments

   TBD

   Describe how people helped me.  List of predecessor drafts and their
   authors.  Long list of people who have helped me directly.

   draft-alvestrand-one-rtp ("TOGETHER") H. Alvestrand
   draft-holmberg-mmusic-sdp-mmt-negotiation ("MMT") C. Holmberg, H.
   Alvestrand draft-ietf-mmusic-sdp-bundle-negotiation ("BUNDLE")









































Worley                   Expires August 12, 2013               [Page 17]

Internet-Draft                SDP Bundling                 February 2013


7.  IANA Considerations

   TBD
















































Worley                   Expires August 12, 2013               [Page 18]

Internet-Draft                SDP Bundling                 February 2013


8.  Security Considerations

   There are no known security implications of these behaviors.
















































Worley                   Expires August 12, 2013               [Page 19]

Internet-Draft                SDP Bundling                 February 2013


9.  Revision History

9.1.  draft-worley-sdp-bundle-00

   Initial version.














































Worley                   Expires August 12, 2013               [Page 20]

Internet-Draft                SDP Bundling                 February 2013


10.  References

10.1.  Normative References

   [sip]      Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

10.2.  Informative References

   [service-examples]
              Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
              K. Summers, "Session Initiation Protocol Service
              Examples", RFC 5359, October 2008.




































Worley                   Expires August 12, 2013               [Page 21]

Internet-Draft                SDP Bundling                 February 2013


Author's Address

   Dale R. Worley
   Ariadne Internet Services, Inc.
   738 Main St.
   Waltham, MA  02451
   US

   Phone: +1 781 647 9199
   Email: worley@ariadne.com









































Worley                   Expires August 12, 2013               [Page 22]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/