IETF Logo Mail Archive

Re: [rtcweb] [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt

"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Thu, 21 February 2013 14:52 UTC

Return-Path: <richard.ejzak@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68C21F8E05; Thu, 21 Feb 2013 06:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.242
X-Spam-Level:
X-Spam-Status: No, score=-9.242 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259]
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 i3BADaVgmc9C; Thu, 21 Feb 2013 06:52:45 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id F200821F8DE4; Thu, 21 Feb 2013 06:52:44 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1LEpo3b021684 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Feb 2013 15:52:32 +0100
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 21 Feb 2013 15:52:02 +0100
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 21 Feb 2013 09:51:59 -0500
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt
Thread-Index: AQHOD2W+toYseWtIxEKEwtE+xBCEiZiCxbWggAHMggD//8Z4EIAAV40A//+xRqA=
Date: Thu, 21 Feb 2013 14:51:58 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
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.83
Subject: Re: [rtcweb] [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 14:52:46 -0000

Hi Christer,
Please see below.

Richard

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]


> >My proposal never has a zero port on a valid m line, in either offer
> or
> >answer.  I only use unspecified address (with valid port number) for
> subsequent m lines in answers.  I'm not sure how you got this from the
> description.  Let's discuss this on the call today.  I hope you are
> available.
> 
> Sorry, I mixed up terminology.
> 
> But, still, if you want to disable/reject the m- line which contains
> the bundle ADDRESS, you will have to move the address to another m-
> line.

Yes.  As long as there is a simple rule for doing so I don't see a problem.

> 
> And, still, you expect intermediaries to retrieve media types,
> protocols, payload types etc from the m- lines, which addresses are
> unspecified - but at the same time you say that no resources will be
> reserved for the m- lines with unspecified addresses...

Intermediaries forwarding BUNDLE information have to understand SOMETHING about BUNDLE or they have no business forwarding it in the first place.  It's only in this case that the intermediary might need to use m lines with unspecified address to identity additional bandwidth requirements.  I meant that -port- resources could be released in this case.  I should have been more careful in describing this point.

Sending a subsequent offer with the same port in all bundled m lines has its own problems in 3pcc scenarios.  You should always send an offer that can pass through intermediaries that do not understand BUNDLE.  My proposal has that characteristic but I'm not sure that yours does.

> 
> Regards,
> 
> Christer

v2.23.0 | Report a Bug | By Email