Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 24 Oct 2012 20:57:05 +0000

On Sep 24, 2012, at 12:41 PM, Jonathan Lennox <[email-masked]> wrote:

> 
> On Sep 23, 2012, at 4:37 PM, Christer Holmberg wrote:
>> 
>>> Instead, Let us discuss the generic categories of attributes and mention in this draft.
>> 
>> I am not sure I understood.
>> 
>> For sure we will have to discuss how/if attributes are affected, but we need to have a general idea on how the multiplexing is going to be offered. Same ports, m=bundle, or something else...
> 
> 
> One of the major benefits of the "pure" m=bundle proposal is that we *don't* have to discuss categories of attributes (other than to make recommendations to implementors).  The attributes inside each unbundled m= line need to be self-consistent, and the attributes inside the m=bundle line also need to be self-consistent, but there doesn't need to be any standardized mechanism to infer the one from the others.
> 
> 

But the problem is that for some attributes, we have no way of expressing them per ssrc, only per m line. Yes I realize we could write many extentions to SDP to have new ways of doing it all per ssrc but this seems to be a disadvantage to me. All I wanted was to put multiple things on the same port - I should have to redefine a bunch of new  SDP to do that.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Oct 2012 07:36:40 +0000

Hi, 

>> One of the major benefits of the "pure" m=bundle proposal is that we *don't* have to discuss categories of attributes (other than to make recommendations to implementors).  The attributes inside each unbundled m= line need to be 
>> self-consistent, and the attributes inside the m=bundle line also need to be self-consistent, but there doesn't need to be any standardized mechanism to infer the one from the others.
> 
> But the problem is that for some attributes, we have no way of expressing them per ssrc, only per m line.

(That is of course not specific to media type multiplexing, but to the usage of multiple sources per m- line in general.)

> Yes I realize we could write many extentions to SDP to have new ways of doing it all per ssrc but this seems to be a disadvantage to me. All I wanted was to put multiple things 
> on the same port - I should have to redefine a bunch of new  SDP to do that.

RFC 5576 is da answah :)

http://tools.ietf.org/rfc/rfc5576.txt

Or, do you have specific examples/use-cases where it wouldn't work?

Regards,

Chrsiter