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=
- [MMUSIC] Possible BUNDLE alternative syntax: expl… Jonathan Lennox
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Paul Kyzivat
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Bernard Aboba
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Bernard Aboba
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Bernard Aboba
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Lishitao
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Lishitao
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Parthasarathi R
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Parthasarathi R
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Jonathan Lennox
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Parthasarathi R
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg