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

["Parthasarathi R" <[e-mail]>]

Hi Christer,

Please read inline.

Thanks
Partha

-----Original Message-----
From: Christer Holmberg [mailto:[e-mail]] 
Sent: Monday, September 24, 2012 2:07 AM
To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)';
[e-mail]
Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line
for bundled session

Hi,

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

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>

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

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>

>Instead, Let us discuss the generic categories of attributes and mention in
this draft.

I am not sure I understood.

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

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:[e-mail]]
Sent: Friday, September 21, 2012 10:57 PM
To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)';
[e-mail]
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
>with m=bundle approach.

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

Regards,

Christer



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



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Christer Holmberg
> Sent: Friday, September 21, 2012 3:32 AM
> To: Ejzak, Richard P (Richard); [e-mail]
> Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line
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
> 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?
>
> 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

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