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

Kevin Dempsey <kevindempsey70@gmail.com> Wed, 22 May 2013 14:11 UTC

Return-Path: <kevindempsey70@gmail.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 A7E0121F9285 for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 07:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level:
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
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 O4hkK+YjZTPf for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 07:11:14 -0700 (PDT)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1085421F9206 for <mmusic@ietf.org>; Wed, 22 May 2013 07:11:13 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id 10so2154213lbf.0 for <mmusic@ietf.org>; Wed, 22 May 2013 07:11:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=auJtTPB9LaIG4a8n5HlSbK+rqWT6XXUbjdK2JwZsjas=; b=hkq0w6DI1dkw77LRmSik3Aabn0VULbrZpnmKCqilmsz5oIUbHzjGbMTtNiHh1q3f20 e48Pep+qyy2S0hVIhQkSDtXeryrSbEWE07+Cwb+Swqnms/Yp8nlCKrRbVgKY5ez8/tER T/Fqg0g1w94eF5FzdRMKTfjFdEcvDQ0/mrVpMWf9WL2M+taxZn4j72VNzYBQIKN2SGQp gHJ2M5ZuojYxnRyXzdLErqtEKSh+OMAEQWTwvXYHZ7FAdE1bnJXU+iWdrLvq8atQa3LF xGhMRTcB1r8R+dowToWv4AMEQV25gGp4raZIWRbjK3765pLTCkF98pLRLSVWF5eFj5rQ qVPg==
MIME-Version: 1.0
X-Received: by 10.152.87.69 with SMTP id v5mr4084720laz.24.1369231872948; Wed, 22 May 2013 07:11:12 -0700 (PDT)
Received: by 10.114.0.139 with HTTP; Wed, 22 May 2013 07:11:12 -0700 (PDT)
In-Reply-To: <519CCE58.3000807@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <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>
Date: Wed, 22 May 2013 15:11:12 +0100
Message-ID: <CAMvTgcdPZfBTyzoBZGCdJiHX+TaL3_T8+MnxH8+6vQPFTD4ZOA@mail.gmail.com>
From: Kevin Dempsey <kevindempsey70@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=001a11c34f4066fce704dd4f23de
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, mmusic <mmusic@ietf.org>
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 14:11:18 -0000

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> 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
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>