Subject: Re: [rtcweb] path forward on bundle

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Oct 2012 14:41:40 +0200

Hi,

>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

Correct.

>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)

Correct. This is what is currently described in draft-bundle.

>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  close to bundle draft )

This is more or less Harald's original proposal.

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

Correct. Later today, we are planning to submit an individual draft (ie *not* a new version of draft-bundle) on this alternative, so that people have some text to look at.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 05 Oct 2012 14:55:32 +0200

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.
>
>
No issue so far.
> 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  close 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.
> 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 :-)

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 5 Oct 2012 12:28:34 +0000

Proposal "m=bundle"
         v=0

---

From: Kaiduan Xie <[email-masked]>
Date: Fri, 5 Oct 2012 14:23:17 -0400

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

/Kaiduan

On Fri, Oct 5, 2012 at 8:55 AM, Harald Alvestrand <[email-masked]> 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.
>>
>>
>> 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.
>
>>
>>
>>
>> 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
>> 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.
>>
>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 5 Oct 2012 18:48:59 +0000

> lines corresponding to foo and bar mids and would just use the stuff

oops - yes - that should be baz , sorry