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

"Parthasarathi R" <> Thu, 27 September 2012 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 372E621F85AA for <>; Thu, 27 Sep 2012 10:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.001
X-Spam-Level: ***
X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_16=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lZzYC12lxWqO for <>; Thu, 27 Sep 2012 10:43:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1C38A21F8522 for <>; Thu, 27 Sep 2012 10:43:40 -0700 (PDT)
Received: from userPC (unknown []) (Authenticated sender: by (Postfix) with ESMTPA id 272B73E2047; Thu, 27 Sep 2012 17:43:33 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120823; t=1348767819; bh=6Ux16p7FlQy5OOVq0pe/63tMFA4YrJi7sGyc0B0J/pQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hUd0CMTXSDMXkeONZs8n1iRqz/kfs9bTigaaF+1qDEWO4963gzbbx8bOV0SX6jlbP QsTRYlh2VIARtYdnz/SguK5M+epZEVwGuTCfWLuz6QS8kmvWlbMKtRutd/DiaQBfa3 WFRmoJkSVB8RSyKoDbM+/BSLk3u+Y9i2jOLuauXY=
From: Parthasarathi R <>
To: 'Christer Holmberg' <>, 'Lishitao' <>, "'Ejzak, Richard P (Richard)'" <>,
References: <> <> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl> <> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <> <>, <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl> <> <>, <> <>, <> <>, <> <>, <> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356 . e>, <> <>, <> <>, <> <> <>, <000001cd9815$d0882190$719864b0$> <>, <000601cd99bc$5b1e5bb0$115b1310$> <>
In-Reply-To: <>
Date: Thu, 27 Sep 2012 23:13:27 +0530
Message-ID: <000001cd9cd7$9e2f15c0$da8d4140$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
X-CTCH-Spam: Suspect
X-CTCH-VOD: Unknown
X-CTCH-RefID: str=0001.0A0B0209.5064904B.00EB, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Sep 2012 17:43:41 -0000

Hi Christer,

Please read inline.


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


>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

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



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


>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
>to reuse lot of existing SDP mechanism (Syntax & Semantics). If possible,
>let us try to fix the open issue with the current mechanism before
>with m=bundle approach.

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



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

> -----Original Message-----
> From: [] On Behalf
> Of Christer Holmberg
> Sent: Friday, September 21, 2012 3:32 AM
> To: Ejzak, Richard P (Richard);
> Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line
> 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
> 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
> separate media lines but requires that something new be defined for
> What about RTCP
> > characteristics?  We certainly want to specify them per (old) media
> >
> > I understand that this can be done with m=bundle, but it requires new
> 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).


mmusic mailing list