Re: [rtcweb] path forward on bundle

On Oct 5, 2012, at 12:23 PM, Kaiduan Xie <kaiduanx@gmail.com> wrote:

> "Note in the above example the SDP above the m=bundle line is pretty
> much the same as the baseline + the group:BUNDLE line. The m=bundle is
> new media type that indicates many things are bundled together on port
> 10000. A device that understood bundle would know to ignore the m
> lines corresponding to foo and bar mids and would just use the stuff
> from the bas mid."
> ^^^
> 
> Should it be baz mid?

oops - yes - that should be baz , sorry

> 
> /Kaiduan
> 
> On Fri, Oct 5, 2012 at 8:55 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>> On 10/05/2012 02:28 PM, Cullen Jennings (fluffy) wrote:
>>> 
>>> I'm trying to figure out how to move forward on bundle stuff. Let me start
>>> by summarizing what I think the three proposals are then we can try and sort
>>> out pros/cons of each. I think we agree that the goals here is to have
>>> something that gets the SDP so that we can negotiate using less ports.
>>> 
>>> I see it as we have three proposed solutions that I will call "a=bundle
>>> same port", "a=bundle different port", and  "m=bundle". I'll try and
>>> describe these below to make sure we are on same page of what the three are
>>> then we can try and figurer out pros/cons of each and what to do. I'll give
>>> examples of the SDP offer for each but I tried and make everything simple,
>>> I'm going to ignore the RTCP mux and such but I think you can see how that
>>> would get added to all the examples.
>>> 
>>> 
>>> First lets set the baseline of an offer that does not want to multiplex
>>> the audio and video on same port
>>>          v=0
>>>          o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>>>          s=
>>>          c=IN IP4 host.atlanta.example.com
>>>          t=0 0
>>>          m=audio 49170 RTP/AVP 0
>>>          a=mid:foo
>>>          a=rtpmap:0 PCMU/8000
>>>          m=video 49172 RTP/AVP 31
>>>          a=mid:bar
>>>          a=rtpmap:31 H261/90000
>>> 
>>> 
>>> 
>>> Proposal "a=bundle same port"
>>>          v=0
>>>          o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>>>          s=
>>>          c=IN IP4 host.atlanta.example.com
>>>          t=0 0
>>>          a=group:BUNDLE foo bar
>>>          m=audio 49170 RTP/AVP 0
>>>          a=mid:foo
>>>          a=rtpmap:0 PCMU/8000
>>>          m=video 49170 RTP/AVP 31
>>>          a=mid:bar
>>>          a=rtpmap:31 H261/90000
>>> 
>>> In the above example, note that all the m lines for a mid identified in
>>> the group:BUNLDE have the same port (49170)
>> 
>> No issue so far.
>> 
>>> 
>>> 
>>> 
>>> Proposal "a=bundle different port"
>>>          v=0
>>>          o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>>>          s=
>>>          c=IN IP4 host.atlanta.example.com
>>>          t=0 0
>>>          a=group:BUNDLE foo bar
>>>          m=audio 49170 RTP/AVP 0
>>>          a=mid:foo
>>>          a=rtpmap:0 PCMU/8000
>>>          m=video 49172 RTP/AVP 31
>>>          a=mid:bar
>>>          a=rtpmap:31 H261/90000
>>> 
>>> In the above example, note that the port numbers are the same as baseline
>>> - if you device receiving this offer does not support group:BUNLDE, then
>>> this is identical to the baseline. So one m line has a port of 49170 and the
>>> other has a different port. Other than that, it is the same as the "a=bundle
>>> same port". The semantics of group:BUNLDE would be defined to be that if the
>>> SDP receiver supports BUNDLE and wants to use it, then it places a
>>> group:BUNDLE line in the answer and it send all the media to the mids in the
>>> in BUNDLE group to the port number identified for the m-line corresponding
>>> to the first mid in the BUNDLE group. In this example, the first mid on the
>>> a=group:BUNDLE lines is foo, which has a m line with a port of 49170, so
>>> both the H261 and PCMU (mids foo and bar) would go to port 49170 if the
>>> device creating the answer wanted to use BUNDLE. We don't have a draft yet
>>> that says exactly this thought it is very close to the one-rtp draft ( and
>>> for that matter  clo
>> 
>> se to bundle draft )
>> I believe this is the mechanism described in draft-alvestrand-one-rtp-02, or
>> at least what it was intended to say. So we can use the name
>> "a=group:together" for this without risk of confusion.
>> 
>>> 
>>> 
>>> 
>>> Proposal "m=bundle"
>>>          v=0
>>>          o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>>>          s=
>>>          c=IN IP4 host.atlanta.example.com
>>>          t=0 0
>>>          a=group:BUNDLE foo bar baz
>>>          m=audio 49170 RTP/AVP 0
>>>          a=mid:foo
>>>          a=rtpmap:0 PCMU/8000
>>>          m=video 49172 RTP/AVP 31
>>>          a=mid:bar
>>>          a=rtpmap:31 H261/90000
>>>          m=bundle 10000 RTP/AVP 0 8 97 31 32
>>>          a=mid:baz
>>>          a=full-rtpmap:0 audio/PCMU/8000
>>>          a=full-rtpmap:31 video/H261/90000
>>> 
>>> 
>>> Note in the above example the SDP above the m=bundle line is pretty much
>>> the same as the baseline + the group:BUNDLE line. The m=bundle is new media
>>> type that indicates many things are bundled together on port 10000. A device
>>> that understood bundle would know to ignore the m lines corresponding to foo
>>> and bar mids and would just use the stuff from the bas mid.
>> 
>> Yep. I've suggested calling it "m=anytype", but Christer hasn't adopted that
>> so far :-)
>> 
>>> 
>>> 
>>> So before we start discussing the pros / cons of theses three approaches,
>>> let's spend a few days and make sure that I have correctly characterized the
>>> three approaches under discussion.
>>> 
>>> Did I get it right? Do we need more explanation of any of these to see how
>>> they work?
>>> 
>>> Lets keep clarifications only on this thread and I'll start a separate
>>> thread for pro/cons once we get this a bit clearer.
>> 
>> Remember to change the subject line to a descriptive one for the next thread
>> :-)
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb