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

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 19 Sep 2012 16:41:57 +0000

On Aug 25, 2012, at 11:01 AM, Bernard Aboba <[email-masked]> wrote:

> 
> Cullen -- did you mean to include "baz" on the 
> a=group:BUNDLE foo L1 L2 baz
> 
> line, since the a=mid:baz line is now gone? 

oops - think that was a typo

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 19 Sep 2012 16:43:17 +0000

On Aug 27, 2012, at 2:03 AM, Harald Alvestrand <[email-masked]> wrote:

>> So, IF people think that offering the same port will cause problem,

For me this is not longer an IF, for equipment I am concerned about it has become a does as I explain at last meeting.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Sep 2012 18:53:45 +0200

Hi,

I've put together a new version of BUNDLE, with a dedicated m- line for the bundled media.

It will be submitted very soon, once I get some editorial fixes done.

Regards,

Christer

________________________________________
From: Cullen Jennings (fluffy) [[email-masked]]
Sent: Wednesday, September 19, 2012 7:43 PM
To: Harald Alvestrand
Cc: Christer Holmberg; [email-masked]
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 19 Sep 2012 17:10:59 +0000

As an individual draft or WG draft?  because I am definitely don't think we have consensus for the "m=bundle" approach yet. I just think the m=bundle approach is going to be much harder to get to work with existing equipment. Stuff is used to seeing a=foo lines they don't understand. They are not used to seeing m=foo lines they don't understand. It doubles the size of the SDP. It creates confusing when rest of SDP in the non bundle part does not match bundle part. It's harder to add other things like opportunistic encryption. But my real problem with it is I don't see any advantage of the m=bundle approach over the a=bundle  approach. 

On Sep 19, 2012, at 10:53 AM, Christer Holmberg <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Sep 2012 19:12:27 +0200

Hi,

>As an individual draft or WG draft?

It was meant to be a new version of bundle...

>because I am definitely don't think we have consensus for the "m=bundle" approach yet. I just think the >m=bundle approach is going to be much harder to get to work with existing equipment. Stuff is used to >seeing a=foo lines they don't understand. They are not used to seeing m=foo lines they don't understand. >It doubles the size of the SDP. It creates confusing when rest of SDP in the non bundle part does not >match bundle part. It's harder to add other things like opportunistic encryption. But my real problem >with it is I don't see any advantage of the m=bundle approach over the a=bundle  approach.

What is the a=bundle approach? Offering "normal" (audio, video, etc) m- lines, and then use one of them for the whole bundle?

Regards,

Christer

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 19 Sep 2012 22:24:57 +0000

Christer,
I also did not get the impression that there was agreement on the m=bundle approach since there were a number of open issues.

As Cullen suggested in http://www.ietf.org/mail-archive/web/mmusic/current/msg09561.html, just offer a normal SDP, add a bundle line, and assume the use of the connection information from the first m line.  I agree with Cullen.  I do not agree with the m=bundle approach for all the reasons Cullen mentions.  The only thing I would add is that some networks may require an updated offer be sent listing the correct port (the same one) on each media line if bundle is negotiated.  ICE already requires a 2nd offer in many cases, so I don't see this as a problem.

Richard 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg
> Sent: Wednesday, September 19, 2012 12:12 PM
> To: Cullen Jennings (fluffy)
> Cc: [email-masked]
> >because I am definitely don't think we have consensus for the "m=bundle"
> approach yet. I just think the >m=bundle approach is going to be much
> harder to get to work with existing equipment. Stuff is used to >seeing
> a=foo lines they don't understand. They are not used to seeing m=foo lines
> they don't understand. >It doubles the size of the SDP. It creates
> confusing when rest of SDP in the non bundle part does not >match bundle
> part. It's harder to add other things like opportunistic encryption. But
> my real problem >with it is I don't see any advantage of the m=bundle
> approach over the a=bundle  approach.
> 
> What is the a=bundle approach? Offering "normal" (audio, video, etc) m-
> lines, and then use one of them for the whole bundle?
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> > For me this is not longer an IF, for equipment I am concerned about it
> has become a does as I explain at last meeting.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2012 00:32:06 +0200

Hi,

>I also did not get the impression that there was agreement on the m=bundle approach since there were a number of open issues.

Ok.

>As Cullen suggested in http://www.ietf.org/mail-archive/web/mmusic/current/msg09561.html, just offer a normal SDP, add a bundle line, and 
>assume the use of the connection information from the first m line.  I agree with Cullen. 

This is what Harald origianlly suggested, and I raised issues with that solution.

> I do not agree with the m=bundle approach for all the reasons Cullen mentions.  The only thing I would add is that some networks may 
> require an updated offer be sent listing the correct port (the same one) on each media line if bundle is negotiated.  ICE already requires 
> a 2nd offer in many cases, so I don't see this as a problem.

I don't understand... The reason m=bundle came up was because people did NOT want to use the same port on each media line...

Regards,

Christer

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 19 Sep 2012 23:28:20 +0000

What I understood is that the group (Cullen in particular) does not want the same port on multiple media lines when it is not known whether the peer supports bundle.  Once you get agreement to use bundle I don't see a problem, but maybe I missed something...  Does anyone have a different perspective?

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2012 5:32 PM
> To: Ejzak, Richard P (Richard); [email-masked]
> Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line
> for bundled session
> 
> Hi,
> 
> >I also did not get the impression that there was agreement on the
> m=bundle approach since there were a number of open issues.
> 
> Ok.
> 
> >As Cullen suggested in http://www.ietf.org/mail-
> archive/web/mmusic/current/msg09561.html, just offer a normal SDP, add a
> bundle line, and
> > I do not agree with the m=bundle approach for all the reasons Cullen
> mentions.  The only thing I would add is that some networks may
> > require an updated offer be sent listing the correct port (the same one)
> on each media line if bundle is negotiated.  ICE already requires
> I don't understand... The reason m=bundle came up was because people did
> NOT want to use the same port on each media line...
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-
> line
> > for bundled session
> >
> > Hi,
> >
> > > I've put together a new version of BUNDLE, with a dedicated m- line
> for
> > the bundled media.
> > >

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2012 01:42:36 +0200

Hi,

>What I understood is that the group (Cullen in particular) does not want the same port on multiple media 
>lines when it is not known whether the peer supports bundle.  Once you get agreement to use bundle I 
>don't see a problem, but maybe I missed something...  Does anyone have a different perspective?

Then one could claim that the initial offer should be sent without bundle (no matter how the mechanism works), and then enable bundle once you know that the other endpoint supports it.

Regards,

Christer

> > line for bundled session

---

From: Lishitao <[email-masked]>
Date: Thu, 20 Sep 2012 06:21:47 +0000

Hi

> Sent: Thursday, September 20, 2012 7:43 AM
> Then one could claim that the initial offer should be sent without bundle (no
> matter how the mechanism works), and then enable bundle once you know
> that the other endpoint supports it.
> 
Maybe another way round, the sender can always send the initial offer with bundle, then if the other end does not supports,  
the sender can send an update SDP offer without using bundle.

Regards
shitao

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 20 Sep 2012 13:14:43 +0000

On Sep 19, 2012, at 6:43 PM, Christer Holmberg wrote:
> Then one could claim that the initial offer should be sent without bundle
> (no matter how the mechanism works), and then enable bundle once you know

What is the advantage of doing this?  The format suggested by Cullen will be handled correctly by an endpoint that doesn't support bundle and could also be handled correctly by an endpoint supporting bundle (if it is understood that the connection information comes from the first media line in the bundle).  I suggested a second offer/answer only for the benefit of intermediates.

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 20 Sep 2012 13:14:44 +0000

On Sep 20, 2012, at 1:22 AM, Lishitao wrote:
> Maybe another way round, the sender can always send the initial offer with
> bundle, then if the other end does not supports,

But then it will take two transactions to negotiate bundle whereas the other proposal allows negotiation of media with or without bundle during the first offer/answer exchange.  The second offer/answer is primarily to avoid misrepresenting the use of transport flows to intermediates.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2012 18:29:00 +0200

Hi,

>>>What I understood is that the group (Cullen in particular) does not want
>>> the same port on multiple media lines when it is not known whether the peer supports bundle.  Once you
>>> get agreement to use bundle I don't see a problem, but maybe I missed something...  Does anyone have a
>>> different perspective?
>>
> What is the advantage of doing this?  The format suggested by Cullen will be handled correctly by an endpoint that doesn't support 
> bundle and could also be handled correctly by an endpoint supporting bundle (if it is understood that the connection information comes
> from the first media line in the bundle).  I suggested a second offer/answer only for the benefit of intermediates.

And how is the m=bundle mechanism not going to be handled correctly by endpoints? An endpoint that doesn't support it would reject it, and an endpoint that supports it can accept it.

Regards,

Christer

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 20 Sep 2012 16:51:43 +0000

> And how is the m=bundle mechanism not going to be handled correctly by
> endpoints? An endpoint that doesn't support it would reject it, and an
> endpoint that supports it can accept it.

This is true, although Cullen has the not unreasonable concern that some endpoints may choke on something this far removed from normal syntax.  m=bundle requires significant extensions to the syntax and also a near doubling in the size of the SDP.  It is harder to specify allowed combinations of codecs and other options that are normally associated with a single m line.  I think we should avoid having duplicate syntax to express all these things that can already be represented in SDP.  

The only issue identified with the original approach is that some endpoints may choke on using the same port for multiple media lines.  Why don't we focus on the simplest fix for that one identified problem?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2012 19:14:30 +0200

Hi,

> This is true, although Cullen has the not unreasonable concern that some endpoints may choke on something this far removed from normal syntax.

I am not sure what "normal syntax" means. The receiver sees an m- line media type that it doesn't support, so I am not sure whether it's even going to look deeper into it.

But, IF the endpoint "chokes", the offerer can send a new offer, without bundle. I don't see why we should specify our mechanism based on how badly implemented endpoints will act...

> m=bundle requires significant extensions to the syntax and also a near doubling in the size of the SDP.  It is harder to specify allowed 
> combinations of codecs and other options that are normally associated with a single m line. 

Please give an example.

> I think we should avoid having duplicate syntax to express all these things that can already be represented in SDP.

We DID have a discussion about whether it should be possible, inside the m=bundle line, to "reference" information existing in the audio/video/etc m- lines, in order to avoid duplication.

> The only issue identified with the original approach is that some endpoints may choke on using the same port for multiple media lines.  Why don't we focus on the simplest fix for that one identifie…

You have said that we need a second offer/answer, with the same port numbers, in order to handle intermediaries. I don't understand why the first offer could not be without bundle, and the second offer (once you know that the remove endpoint supports bundle) according to the current mechanism, with the same port numbers.

Regards,

Christer

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 20 Sep 2012 19:18:49 +0000

> > m=bundle requires significant extensions to the syntax and also a near
> doubling in the size of the SDP.  It is harder to specify allowed

To specify two types of audio flows with very different characteristics I would normally have separate media lines with separate codec lists and attributes.  One may require DTMF and the other silence suppression in addition to the selected (but different) codecs.  We need to keep this characteristic.  We also need a way of specifying bandwidth per (old) media line, which is already supported using separate media lines but requires that something new be defined for m=bundle.  What about RTCP characteristics?  We certainly want to specify them per (old) media line.

I understand that this can be done with m=bundle, but it requires new syntax.  Why bother if we have something that can work?

> You have said that we need a second offer/answer, with the same port
> numbers, in order to handle intermediaries. I don't understand why the
> first offer could not be without bundle, and the second offer (once you
> know that the remove endpoint supports bundle) according to the current
> mechanism, with the same port numbers.

It would seem to be attractive to support negotiation of bundle with the first offer/answer transaction else it will be delayed.  And some networks may not need a 2nd offer/answer if the first one successfully negotiates one of the options.

Richard

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2012 21:32:08 +0200

Hi,

> To specify two types of audio flows with very different characteristics I would normally have separate media lines with separate codec lists and attributes.  One may require DTMF and the other silence suppression in addition to the selected (but different) 
> codecs.  We need to keep this characteristic.  We also need a way of specifying bandwidth per (old) media line, which is already supported using separate media lines but requires that something new be defined for m=bundle.  What about RTCP 
> characteristics?  We certainly want to specify them per (old) media line.
>

I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in order to map attributes to specific flows.

> It would seem to be attractive to support negotiation of bundle with the first offer/answer transaction else it will be delayed. 
> And some networks may not need a 2nd offer/answer if the first one successfully negotiates one of the options.

Only if you can assume that there are not intermediaries in those network - AND that there won't be additional offer/answers for other reasons (you earlier said that there in many cases WILL be additional offer/answers...).

I still think it would be wrong to reject the m=bundle proposal based on badly implemented endpoints. In that case one could claim that endpoints will "choke" if they receive SDPs with RTCWEB datachannels, CLUE channels, whatever channels...

Regards,

Christer

---

From: Lishitao <[email-masked]>
Date: Fri, 21 Sep 2012 01:51:07 +0000

> Sent: Friday, September 21, 2012 3:32 AM
> > To specify two types of audio flows with very different characteristics I would
> normally have separate media lines with separate codec lists and attributes.
> One may require DTMF and the other silence suppression in addition to the
> selected (but different)
> > codecs.  We need to keep this characteristic.  We also need a way of
> specifying bandwidth per (old) media line, which is already supported using
> separate media lines but requires that something new be defined for m=bundle.
> What about RTCP
> > I understand that this can be done with m=bundle, but it requires new syntax.
> Why bother if we have something that can work?
> 
> I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in
> order to map attributes to specific flows.

I would suggest that put the m=bundle proposal in a separate new personal draft or in the annex of the existing working draft, and 
make a comparison for this proposal and the existing proposal. That will make it more clear.
For the existing proposal, I believe that people are not totally against, although it has some issues. (the m=bundle proposal also has some issues).

Regards
shitao

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 21 Sep 2012 21:56:04 +0530

I agree with Cullen & others that m=bundle does not have consensus. We need
more discussion and analysis. The current Bundle syntax is designed in a way

to reuse lot of existing SDP mechanism (Syntax & Semantics). If possible,
let 
us try to fix the open issue with the current mechanism before proceeding 
with m=bundle approach.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lishitao
Sent: Friday, September 21, 2012 7:21 AM
To: Christer Holmberg; Ejzak, Richard P (Richard); [email-masked]
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line
for bundled session

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

I would suggest that put the m=bundle proposal in a separate new personal
draft or in the annex of the existing working draft, and 
make a comparison for this proposal and the existing proposal. That will
make it more clear.
For the existing proposal, I believe that people are not totally against,
although it has some issues. (the m=bundle proposal also has some issues).

Regards
shitao

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2012 19:26:50 +0200

Hi,

>let us try to fix the open issue with the current mechanism before proceeding
>with m=bundle approach.

Feel free to provide input on how you think we can solve that issue :)

Regards,

Christer

-----Original Message-----

for

Regards
shitao

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 24 Sep 2012 00:20:44 +0530

Hi Christer,

IIUC, The same port offer may be rejected by answerer irrespective of 
"m=bundle" or "a=group:BUNDLE" as it is not just new SDP syntax
but also, the same port offer may have impact in other layers like RTP 
in answerer side implementation. The bundling of the different media 
in the same port is not guaranteed to negotiate in the answer side with 
"m=bundle" mechanism. The point is that answerer will reject in case the 
same port offer is not accepted in the specific implementation.

Apart from this, The individual attribute behavior for bundle has to be 
defined somewhere irrespective of "m=bundle" or "a=group:BUNDLE". Say ptime 
attribute applies for the audio codecs only or applies for video codecs
as well in the bundle has to be defined. I'm not see much advantage with 
"m=bundle" here. Instead, Let us discuss the generic categories of
attributes
and mention in this draft.

Thanks
Partha

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 10:57 PM
To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)';
[email-masked]

Hi,

Regards,

Christer

-----Original Message-----

for

Regards
shitao

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic=

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 23 Sep 2012 22:37:13 +0200

Hi,

>same port offer is not accepted in the specific implementation.

If the m=bundle proposal, you don't have to use the same ports. You can assign a separate port for the m=bundle media description.

>"m=bundle" here.

It is already possible to specify attribute values for individual SSRCs. We could do something similar for media types if we want.

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

So, again, if you have any ideas on how to do it I'd like to hear them :)

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, September 21, 2012 10:57 PM
To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)';
[email-masked]

Hi,

Regards,

Christer

-----Original Message-----

for

Regards
shitao

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 24 Sep 2012 14:41:28 -0400

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

--
Jonathan Lennox
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Sep 2012 21:51:03 +0200

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.

That is my current understanding also.

And, IF we need to define new attributes, we will of course define the usage of them from scrath :) 

For example, the m=bundle draft I'm working on defines a new SDP attribute, which maps a PT to a specific media type (audio, video etc), as it cannot be assumed that the rtpmap attribute always can be used to identity the media type (in most cases it can, though).

Regards,

Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 27 Sep 2012 23:13:27 +0530

Hi Christer,

Please read inline.

Thanks
Partha

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, September 24, 2012 2:07 AM
To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)';
[email-masked]

Hi,

>same port offer is not accepted in the specific implementation.

If the m=bundle proposal, you don't have to use the same ports. You can
assign a separate port for the m=bundle media description.
<Partha> I could not understand your explanation here. Please explain how
the separate port for m=bundle solves the problem of answerer which does not
want to have the same port for its multiple media types. </Partha>

>as well in the bundle has to be defined. I'm not see much advantage with

It is already possible to specify attribute values for individual SSRCs. We
could do something similar for media types if we want.

<Partha> In case of using the same port in all "m" line using group
attributes, the specific attributes values works does not need any update
</partha>

<Partha> Paul mentions about some of the categories of the attributes in
http://www.ietf.org/mail-archive/web/mmusic/current/msg09467.html. The
contention for same port in "m" line mechanism is that "those that are
summed across all the bundled media sections". Those issues shall be fixed
by the semantic representation. Say bandwidth parameter in bundle group is
the sum of all the bandwidth in the specific bundle group. </Partha> 

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

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, September 21, 2012 10:57 PM
To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)';
[email-masked]

Hi,

Regards,

Christer

-----Original Message-----

for

Regards
shitao

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic==

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2012 11:20:03 +0200

Hi,

>>"m=bundle" or "a=group:BUNDLE" as it is not just new SDP syntax but 
>>also, the same port offer may have impact in other layers like RTP in 
>>answerer side implementation. The bundling of the different media in 
>>the same port is not guaranteed to negotiate in the answer side with 
>>"m=bundle" mechanism. The point is that answerer will reject in case 
>>the same port offer is not accepted in the specific implementation.
>
><Partha> I could not understand your explanation here. Please explain how the separate port for m=bundle solves the problem of answerer which does not want to have the same port for its multiple media types. </Partha>

If the answerer does not want to do multiplexing, or does not support multiplexing, it sets the m= bundle port to zero, and uses the separate m=audio/video ports.

>>defined somewhere irrespective of "m=bundle" or "a=group:BUNDLE". Say 
>>ptime attribute applies for the audio codecs only or applies for video 
>>codecs as well in the bundle has to be defined. I'm not see much 
>>advantage with "m=bundle" here.
>
><Partha> In case of using the same port in all "m" line using group attributes, the specific attributes values works does not need any update </partha>

Yes, but people have raised issues with using the same port in all "m" lines - that's why we've suggested the m=bundle solution.

> <Partha> Paul mentions about some of the categories of the attributes in http://www.ietf.org/mail-archive/web/mmusic/current/msg09467.html. The contention for same port in "m" line mechanism is that "those that are summed across all the 
> bundled media sections". Those issues shall be fixed by the semantic representation. Say bandwidth parameter in bundle group is the sum of all the bandwidth in the specific bundle group. </Partha> 

Yes. But, again, I don't think the attributes have been the main issue. The issue have been using the same port in multiple m- lines in the first place.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, September 21, 2012 10:57 PM
To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)'; [email-masked]
Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

Hi,

>I agree with Cullen & others that m=bundle does not have consensus. We 
>need more discussion and analysis. The current Bundle syntax is 
>designed in a
way
>to reuse lot of existing SDP mechanism (Syntax & Semantics). If 
>possible, let us try to fix the open issue with the current mechanism 
>before
proceeding

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lishitao
Sent: Friday, September 21, 2012 7:21 AM
To: Christer Holmberg; Ejzak, Richard P (Richard); [email-masked]
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
for
> bundled session
>
> Hi,
>
> >>> m=bundle requires significant extensions to the syntax and also a 
> >>> near doubling in the size of the SDP.  It is harder to specify 
> >>> allowed combinations of codecs and other options that are normally 
> >>> associated with a single m line.
> >>
> >> Please give an example.
> >
> > To specify two types of audio flows with very different 
> > characteristics
I would
> One may require DTMF and the other silence suppression in addition to 
> the selected (but different)
> > I understand that this can be done with m=bundle, but it requires 
> > new
syntax.
> order to map attributes to specific flows.

I would suggest that put the m=bundle proposal in a separate new personal draft or in the annex of the existing working draft, and make a comparison for this proposal and the existing proposal. That will make it more clear.
For the existing proposal, I believe that people are not totally against, although it has some issues. (the m=bundle proposal also has some issues).

Regards
shitao