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

"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Thu, 20 September 2012 13:15 UTC

Return-Path: <richard.ejzak@alcatel-lucent.com>
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 0B01221F8562 for <mmusic@ietfa.amsl.com>; Thu, 20 Sep 2012 06:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.649
X-Spam-Level:
X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 Fye2hS3slaR5 for <mmusic@ietfa.amsl.com>; Thu, 20 Sep 2012 06:15:05 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 44CF021F8504 for <mmusic@ietf.org>; Thu, 20 Sep 2012 06:15:05 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8KDEf76014417 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Sep 2012 15:15:00 +0200
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Sep 2012 15:14:48 +0200
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.110]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 20 Sep 2012 09:14:43 -0400
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1gADic5A=
Date: Thu, 20 Sep 2012 13:14:43 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com>
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> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
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: Thu, 20 Sep 2012 13:15:06 -0000

On Sep 19, 2012, at 6:43 PM, Christer Holmberg wrote:
> >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.

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.