Re: [MMUSIC] Bundle offer with different ports - where to expect media?

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 22 May 2013 23:22 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 3225611E815B for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 16:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.282
X-Spam-Level:
X-Spam-Status: No, score=-0.282 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 XMguXqndqT2N for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 16:22:52 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 60E2311E8151 for <mmusic@ietf.org>; Wed, 22 May 2013 16:22:51 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id eySx1l0020xGWP854BNrbl; Wed, 22 May 2013 23:22:51 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id fBNq1l0123ZTu2S3YBNqwX; Wed, 22 May 2013 23:22:51 +0000
Message-ID: <519D5349.2030202@alum.mit.edu>
Date: Wed, 22 May 2013 19:22:49 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Justin Uberti <juberti@google.com>
References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <CAPvvaa+A=LkYp9A+wENAABwCYaQcD0HVeX4o+O_16iJRPXZfNw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <CAPvvaaJsPNk1DAJXYoc8aUgZ0ZayV_8q84W=Mm7vwuRRGuwC-g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <CAOJ7v-398_MiXLWjexU0Z0xQju3A-zWuQFkWkJSLPA5UEGAu+g@mail.gmail.com> <CABkgnnXqBzteoxH2qWBw1Xn9PHt2r___UCsp1Eoq4o8_VWvBZg@mail.gmail.com> <CAOJ7v-2xXb=uz3jBAKSXhyJ2mU9BGvYHZ=dkeKcZTWov7udWKQ@mail.gmail.com> <519CCE58.3000807@alum.mit.edu> <CAMvTgcdPZfBTyzoBZGCdJiHX+TaL3_T8+MnxH8+6vQPFTD4ZOA@mail.gmail.com> <CAOJ7v-1tmfy4Fu05ChcpbZT=bO-zr05qtOh9Lnw5bprbUEnoDw@mail.gmail.com>
In-Reply-To: <CAOJ7v-1tmfy4Fu05ChcpbZT=bO-zr05qtOh9Lnw5bprbUEnoDw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369264971; bh=X8B6aK6t0Q9MHjxjVhvkUB3qFuUjX3NRv6ls0sAqy2M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=heFai+xUlA3nsEOHVlcCuDCa/Urt3Y3uKTFwMJ5cwNYrmnP5m07ub4zHlMfLQI5zg TvPp3qnz/v/VY00Jv02l9c7YxvuCcMrJlPKdWF6hjmySR8Nk7ESowk0Y2NOlifXxRw VISAGkHxi23nQS+PWEYG6gsS4uX76nqwkHhqGJ+PLhxF2sCZ5WYnt13qj39EfSt19m fTbdxMhsDvjZ6csYusMTz1KcUeMPSehnlR9kY/n53gp0LCFpp9NOobOQHo0kH+vdlB lLktf/de26ibIOAPRZSapdF1kr2KVs83IFtnPhpxa/gN8nBUmbWz8VhVsBYLVZJspY QWmHUuJUEZD8g==
Cc: mmusic <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media?
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: Wed, 22 May 2013 23:22:57 -0000

On 5/22/13 6:55 PM, Justin Uberti wrote:
> I think we could do this using the existing syntax, e.g.
>
> an offer of a=group:BUNDLE A B C would indicate that the offerer would
> prefer A, B, and C to be muxed onto A, and
> an answer of a=group:BUNDLE C A would indicate that the answerer is
> going to mux C and A onto C, and send B unbundled.

That would work. I don't have an objection to it.
But I'm also ok with choosing based on static ordering of m-lines.

Whether to allow m-lines with zero ports in the bundle is a separate 
question. This approach could still work with that, as long as the zero 
ones aren't listed first, or the rules are adjusted to use the first in 
the answer bundle that is non-zero.

IIRC the desire to allow zero port m-lines in a bundle was so that an 
offer could indicate what it wants to bundle even though it doesn't want 
to assign ports yet. If that is still of interest then we shouldn't take 
it away.

	Thanks,
	Paul

>
> On Wed, May 22, 2013 at 7:11 AM, Kevin Dempsey <kevindempsey70@gmail.com
> <mailto:kevindempsey70@gmail.com>> wrote:
>
>     Would it make it simpler if the offer included an attribute in
>     bundled m= lines that said where to send the media if bundle is
>     supported by the answerer; and for the answer to include an
>     attribute that said where it was going to send the media (ie. to the
>     bundled destination or the unbundled destination)
>
>
>     On 22 May 2013 14:55, Paul Kyzivat <pkyzivat@alum.mit.edu
>     <mailto:pkyzivat@alum.mit.edu>> wrote:
>
>         On 5/22/13 1:00 AM, Justin Uberti wrote:
>
>             Taking into account Emil's suggestion as well, this leads to
>             this
>             restatement of the rules:
>
>             1.1) An offerer must be prepared to receive unbundled
>             traffic on the
>             offered ports, as if talking to a legacy endpoint.
>             1.2) An offerer must be prepared to receive bundled traffic
>             on any port,
>             except the port associated with the last m= line.
>             2) Once the answer is received, the decision on
>             bundled/unbundled and
>             which ports to use is finalized.
>             2.1) BUNDLEd m= lines use the port of the m= line that
>             appears first in
>             the bundle.
>             2.2) Unused ports can be discarded at this point.
>             3.1) m= lines offered with distinct ports may be omitted
>             from the bundle
>             answer, in line with RFC 5888.
>             3.2) m= lines offered with the same port may not be omitted
>             from the
>             bundle answer, since there is no unbundled port from them to
>             fall back to.
>             3.3) m= lines that are rejected are omitted from the bundle
>             answer, per
>             RFC 5888.
>
>             Quick check on 2.1: are we using the m= line that appears
>             first in the
>             SDP, or the m= line that appears first in the a=group:BUNDLE?
>
>
>         IMO it would be best to use the lexically first m-line that has
>         a non-zero port and that appears in the bundle group of the answer.
>
>         Alternately, it *could* be the m-line with non-zero port that
>         appears first in the bundle group of the answer. But if so, the
>         exception in 1.2 would also need to be correspondingly adjusted.
>
>         AFAICT the only reason to mention that exception in 1.2 is that
>         might provide an opportunity for optimization, by setting up the
>         port with simpler code that doesn't support bundling. I don't
>         see a requirement in 5888 that the bundle group in the answer be
>         ordered the same way as in the offer. So the one m-line
>         guaranteed not to receive bundled traffic would then not be
>         predictable at the time of the offer, so could not be exploited.
>         This problem doesn't exist if the lexical ordering of m-lines is
>         used.
>
>                  Thanks,
>                  Paul
>
>
>         _________________________________________________
>         mmusic mailing list
>         mmusic@ietf.org <mailto:mmusic@ietf.org>
>         https://www.ietf.org/mailman/__listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>
>
>