Subject: [MMUSIC] Revised bundling proposal (draft-worley-sdp-bundle-06)

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Mar 2013 17:30:09 -0400 (EDT)

I've submitted a revised bundling proposal
(http://tools.ietf.org/html/draft-worley-sdp-bundle-06).  The major
changes are that it no longer uses encapsulation (Martin Thompson and
Dan Wing explained to me why that is undesirable) and it uses a
special attribute ("a=bundleaccept") along with a zero port number to
indicate that a constituent media description has been accepted within
a bundle.  The powerpoint version is:

Major characteristics:

* SDP m= lines are grouped using a new SDP grouping value.

* There is a separate bundle media description, which uses media type
  "audio" (to avoid tripping legacy SBCs) and proto "bundle" (to
  prevent non-supporting answerers from accepting that media
  description).

* Each constituent media description is offered with a distinct port.

* If the answerer accepts a constituent media description within the
  bundle, it answers with a zero port, but marks the media
  description with "a=bundleaccept".  The media description is still
  listed in the "a=group:BUNDLE" line, which is an extension of RFC
  5888.

* If the offerer did not preallocate TURN relays for constituent media
  descriptions, and the answerer does not support bundling, and TURN
  relays are required on the offerer's side, then the offerer will
  have to update its offer to establish communication.

Advantages:

* Avoids all known limitations of common SBCs.  Only requires SBCs to
  pass unknown proto values.

* Legacy intermediary entities see media which matches the SDP.

* Interoperates directly with non-supporting answerers.

* Requires updated offer only if offerer has not preallocated TURN
  relays for the constituent media descriptions and they turn out to
  be necessary.

* No artificial addresses (e.g., 0.0.0.0) are used, so it places no
  constraints on future uses of artificial addresses (e.g., trickle
  ICE).

A typical offer (with a usual pattern of ICE candidates):

           o=- 2890844526 2890844526 IN IP4 host.example.com
           c=IN IP4 host.example.com

           a=group:BUNDLE bundle con1 con2

           m=audio 10000 RTP/AVP 0 8 97
           a=mid:con1
           a=rtcp-mux
           a=rtpmap:0 PCMU/8000
           a=rtpmap:8 PCMA/8000
           a=rtpmap:97 iLBC/8000
           a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx

           m=video 10002 RTP/AVP 31 32
           a=mid:con2
           a=rtcp-mux
           a=rtpmap:31 H261/90000
           a=rtpmap:32 MPV/90000
           a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx

           m=audio 10004 bundle 0
           a=mid:bundle
           a=candidate:0 1 UDP 2113601791 10.0.1.1 10004 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.32 51004 typ srflx
           a=candidate:2 1 UDP 1006633215 10.0.100.1 31004 typ relay

A typical answer from an endpoint that supports bundling:

           o=- 2890844526 2890844526 IN IP4 answer.example.com
           c=IN IP4 answer.example.com

           a=group:BUNDLE bundle con1 con2

           m=audio 0 RTP/AVP 0 8 97
           a=mid:con1
           a=bundleaccept
           a=rtcp-mux
           a=rtpmap:0 PCMU/8000
           a=rtpmap:8 PCMA/8000
           a=rtpmap:97 iLBC/8000

           m=video 0 RTP/AVP 31 32
           a=mid:con2
           a=bundleaccept
           a=rtcp-mux
           a=rtpmap:31 H261/90000
           a=rtpmap:32 MPV/90000

           m=audio 20000 bundle 0
           a=mid:bundle
           a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx
           a=candidate:2 1 UDP 1006633215 10.0.100.1 32000 typ relay

Dale