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

"Parthasarathi R" <partha@parthasarathi.co.in> Sun, 23 September 2012 18:50 UTC

Return-Path: <partha@parthasarathi.co.in>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD7E21F8471 for <mmusic@ietfa.amsl.com>; Sun, 23 Sep 2012 11:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.105
X-Spam-Level:
X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPWtd-CEHeBh for <mmusic@ietfa.amsl.com>; Sun, 23 Sep 2012 11:50:54 -0700 (PDT)
Received: from outbound-us3.mailhostbox.com (unknown [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AB21F8468 for <mmusic@ietf.org>; Sun, 23 Sep 2012 11:50:54 -0700 (PDT)
Received: from userPC (unknown [122.166.137.12]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 34B1C14D8164; Sun, 23 Sep 2012 18:50:47 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1348426253; bh=zNQ7gBoG5o3XSp/aAFYu+L1fe6iiX62y5MZAhJDdrQY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=e5LC7RQqssLP/PHpeGoh5O4XP5GGHgTKUBgqUziZlFGDTzvzFH+gPRfdjwE8HhpoH WLyT9NHHn2B/K3RWreh6AXbqDU307SQfkf2Q7d4YRVXxLlBHiQch5gOhP5cUK9eMqN d3dYEcCYd9Z9ToW4HUu+slrdmu/Z714KhUgfoILk=
From: Parthasarathi R <partha@parthasarathi.co.in>
To: 'Christer Holmberg' <christer.holmberg@ericsson.com>, 'Lishitao' <lishitao@huawei.com>, "'Ejzak, Richard P (Richard)'" <richard.ejzak@alcatel-lucent.com>, mmusic@ietf.org
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl> <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356. e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> <DA165A8A2929C6429CAB403A76B573A5146A1409@szxeml534-mbx.china.huawei.com>, <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>
Date: Mon, 24 Sep 2012 00:20:44 +0530
Message-ID: <000601cd99bc$5b1e5bb0$115b1310$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAOLngIAANkgAgAAGWYCAAAZdAIAAIryAgAADuQCAAOzj0IAA9jxggAAP5uyAAzJQoA==
Content-Language: en-us
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-RefID: str=0001.0A0B0208.505F5A0D.0073, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Sep 2012 18:50:55 -0000

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:christer.holmberg@ericsson.com] 
Sent: Friday, September 21, 2012 10:57 PM
To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)';
mmusic@ietf.org
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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
Lishitao
Sent: Friday, September 21, 2012 7:21 AM
To: Christer Holmberg; Ejzak, Richard P (Richard); mmusic@ietf.org
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line
for bundled session



> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Christer Holmberg
> Sent: Friday, September 21, 2012 3:32 AM
> To: Ejzak, Richard P (Richard); mmusic@ietf.org
> 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
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic=