Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

Hadriel Kaplan <hadriel.kaplan@oracle.com> Thu, 08 August 2013 12:21 UTC

Return-Path: <hadriel.kaplan@oracle.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 6C47321F9635 for <mmusic@ietfa.amsl.com>; Thu, 8 Aug 2013 05:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.52
X-Spam-Level:
X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XUt-onGoZIB for <mmusic@ietfa.amsl.com>; Thu, 8 Aug 2013 05:21:22 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5B521F8FAC for <mmusic@ietf.org>; Thu, 8 Aug 2013 05:21:22 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78CLINO024049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 12:21:19 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78CLGn2007799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 12:21:17 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78CLFPu012753; Thu, 8 Aug 2013 12:21:16 GMT
Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 05:21:15 -0700
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se>
Date: Thu, 08 Aug 2013 08:21:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>
References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?
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, 08 Aug 2013 12:21:27 -0000

If I understand your question, you're asking why bundle-only m-lines would use a port number of 0 in the offer, instead of using the same port number as the regular bundle m-line they're going to transport-bundle with?

I believe the rationale was basically argued about before, either in IETF 86 Orlando or IETF 85 Atlanta.  It gets back to the original debate about whether a BUNDLE offer should use the same port numbers or different ones, for bundle m-lines (what was called "BUNDLE vs. CRUNDLE" if I recall correctly).

One WG participant argued against using the same port numbers for bundle lines.  His argument was that since it was never described in an RFC, and he knew of one implementation that didn't handle it well, that therefore we couldn't send an offer using the same port numbers until we found out if the far-end supported BUNDLE or not.

That's what drove the decision to use different port numbers even in regular bundle cases, afaik.

Therefore, even for bundle-only lines, we can't use the same non-0 port number for them, because the same theoretical issue will exist.

Also, from a purely protocol perspective, it seems quite logical to me to use a port number of 0 for an m-line you literally don't want to use if the far-end doesn't support BUNDLE - a port number of 0 effectively means "disabled" today, and that's basically what you want.  What I don't think is right, is (1) having the far-end send an SDP answer back that sets a real port number for those same "disabled" m-lines, and (2) not requiring another offer/answer exchange that then uses the correct (same) port numbers for the previously-disabled m-lines.

What I think should happen is the UAS should send an SDP answer using port=0 for those same m-lines, and the UAC should then send a new offer with those m-lines having the real port number of the bundle transport, and the far-end should answer that in the same fashion.

-hadriel


On Aug 8, 2013, at 2:18 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
>  
> As has been indicated, bundle-only can only be used when one knows that the receiver, and possible intermediaries etc, support it.
>  
> So, based on that assumption, my question is: why do we need port 0? Why not assign the suggested bundle port to the bundle-only m- lines from the beginning? As the bundle port is anyway going to be used (even if the receiver does not want to use bundle), there is no need to reserve additional ports for bundle-only m- lines.
>  
> Regards,
>  
> Christer
>  
> 
> 
> Sent from Windows using TouchDown (www.nitrodesk.com)
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic