[Webkit-unassigned] [Bug 170157] New: [WebRTC] Add support for SDP BUNDLE ("a:group:BUNDLE" and "a=bundle-only" lines)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=170157

            Bug ID: 170157
           Summary: [WebRTC] Add support for SDP BUNDLE ("a:group:BUNDLE"
                    and "a=bundle-only" lines)
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media Elements
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: clopez at igalia.com
                CC: alex at igalia.com, aperez at igalia.com

WebKit SDPProcessor ignores the bundlePolicy defined on RTCPeerConnection(), and doesn't generate the a=group:BUNDLE nor the a=bundle-only lines.

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-19 and https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-36 defines how this should work.

Very summarized, the idea is that we should generate an "a=group:BUNDLE" attribute with the MID identifiers specified in the bundle group in the most recent answer.
If we are creating the offer, then we use our MID identifiers.

          a=group:BUNDLE ${midname1} [... ${midnameN} ]

And then we should generate a number of a=bundle-only lines according to the bundlePolicy defined and the number of tracks.

C&P from draft-ietf-rtcweb-jsep-19::

"""
The set of available policies is as follows:

   balanced:  The first m= section of each type (audio, video, or
      application) will contain transport parameters, which will allow
      an answerer to unbundle that section.  The second and any
      subsequent m= section of each type will be marked bundle-only.
      The result is that if there are N distinct media types, then
      candidates will be gathered for for N media streams.  This policy
      balances desire to multiplex with the need to ensure basic audio
      and video can still be negotiated in legacy cases.  When acting as
      answerer, if there is no bundle group in the offer, the
      implementation will reject all but the first m= section of each
      type.

   max-compat:  All m= sections will contain transport parameters; none
      will be marked as bundle-only.  This policy will allow all streams
      to be received by non-bundle-aware endpoints, but require separate
      candidates to be gathered for each media stream.

   max-bundle:  Only the first m= section will contain transport
      parameters; all streams other than the first will be marked as
      bundle-only.  This policy aims to minimize candidate gathering and
      maximize multiplexing, at the cost of less compatibility with
      legacy endpoints.  When acting as answerer, the implementation
      will reject any m= sections other than the first m= section,
      unless they are in the same bundle group as that m= section.

   As it provides the best tradeoff between performance and
   compatibility with legacy endpoints, the default bundle policy MUST
   be set to "balanced".
"""

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170328/1827d48d/attachment.html>