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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 20 May 2013 13:39 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 F35FE21F9375 for <mmusic@ietfa.amsl.com>; Mon, 20 May 2013 06:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.104, 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 0YPuatBnYqJ5 for <mmusic@ietfa.amsl.com>; Mon, 20 May 2013 06:38:56 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 7190421F9374 for <mmusic@ietf.org>; Mon, 20 May 2013 06:38:55 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id eCoH1l0021ei1Bg51Dep0F; Mon, 20 May 2013 13:38:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id eDep1l00o3ZTu2S3kDepv1; Mon, 20 May 2013 13:38:49 +0000
Message-ID: <519A2768.5010904@alum.mit.edu>
Date: Mon, 20 May 2013 09:38:48 -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: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369057129; bh=GYa1LXGM2MzkfniqOf9h6PH0MpEB4BhCM8JN/gEh69A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EJclVAFwG+xeORSOao5fno79TTBq9PEGnps2EPELM5GxdnFiQ/CXm47pBHyLSFlEI QsTj2/sVzrH5IB1zop4mURXycRCV32aruYHCSYrOZiKzYx+bxY1rVO0RsuNUDYJcXf 9/mqWl+Pwf5zWWSiXxuZZWh3geszgkZJjlmH1RQCN2JI8ghzvuEftbBowvV3MNxa42 Q2ARHIar/s0kk4RiZnyhW3CHnxSqLoAHstUt/DZlwAXqmV3r8XKDsKj72LeR//w/mx UOrV35Dv/OttW8AYV1GFXVvJEVsKAf20FGChqfVs2asQBjwbfsNNOZjAu6HQaBeECn 0aw2DvYT+oipg==
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: Mon, 20 May 2013 13:39:01 -0000

I agree with Christer's analysis here. The bundle port must be one 
associated with an m-line that is accepted, and included in the bundle, 
in the answer. That means the bundle port may not be the one from the 
first bundled m-line in the offer.

A corollary of that is that the offerer needs to be prepared to receive 
bundled media on any of the ports listed in the offer.

	Thanks,
	Paul

On 5/20/13 9:27 AM, Christer Holmberg wrote:
> Hi,
>
>>> Agree with Emil but think maybe the question was meant to be on which
>>> port(s) it needs to be able to receive bundled media.
>>>
>>> This is covered by the last para in section 6.3 which states that the
>>> answerer MUST use the port and everything else relating to the 1st m=
>>> line. So far I thought this to be reasonable and even if the 1st m=
>>> line is rejected this can still be the bundle port.
>>
>> +1
>
> I agree that is what the spec currently says.
>
> But, again, the following can happen:
>
> 1) The answerer rejects the 1st m- line; or
>
> 2) The answerer accepts the 1st m- line, but removes it from the bundle group. Yes, in this case the answerer WILL send media on that port, but ONLY media associated with that m- line (as it is no long part of the bundle group). The media associated with the remaining m- lines in the bundle group has to be sent somewhere else.
>
> Again, once the second offer has been sent, the "bundle port" is explicitly signaled (as each m- line in the bundle group uses the same port number).
>
> Regards,
>
> Christer
>
>
>
>>> -----Original Message----- From: mmusic-bounces@ietf.org
>>> [mailto:mmusic-bounces@ietf.org] On Behalf Of Emil Ivov Sent: 20 May
>>> 2013 13:13 To: Christer Holmberg Cc: mmusic@ietf.org Subject:
>>> Re: [MMUSIC] Bundle offer with different ports - where to expect
>>> media?
>>>
>>> Hey Christer,
>>>
>>> On 20.05.13, 14:43, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> Currently BUNDLE defines that the first offer is sent with separate
>>> port
>>>> numbers (later, if the answerer has indicated support of BUNDLE, the
>>>> offerer will send a second offer, with identical port numbers).
>>>>
>>>> Some people have indicated that the offerer shall be able to receive
>>>> data already when the first offer has been sent. The question is on
>>>> which port(s) it needs to be able to receive media.
>>>
>>> Do we really have a choice here? We send the offer with different
>>> port numbers so that it would work with endpoints that have no
>>> knowledge of bundle. Such endpoints can start streaming media to any
>>> port. Bundled devices can, on the other hand, start streaming media
>>> on the bundle port.
>>>
>>> So in other words, the offerer need to expect media arriving on any
>>> port just as it needs to expect any stream arriving on the bundle
>>> port.
>>>
>>> This would be consistent with what we do for rtcp-mux.
>>>
>>> Emil
>>>
>>>
>>>>
>>>>
>>>>
>>>> -          Some have suggested the port of the first non-zero m-
>>>> line within the offered bundle group.
>>>>
>>>> -          Some have suggested ANY port
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The issue with assuming the first non-zero m- line is that the
>>> answerer
>>>> in the answer may reject it (put the port to zero), or remove it
>>>> from the bundle group (which people seem to want to allow). In both
>>>> cases
>>> it
>>>> would be strange to assume the first m- line.
>>>>
>>>>
>>>>
>>>> Now, in case e.g. ICE is used, the offerer will be able to send the
>>>> second offer before any media is received to begin with. But, the
>>>> offerer could still receive STUN connectivity checks on any of the
>>>> ports, until the second offer has been sent.
>>>>
>>>>
>>>>
>>>> We need text in BUNDLE about this, so comments/inputs are welcome
>>>> :)
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________ mmusic mailing list
>>>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> -- https://jitsi.org
>>> _______________________________________________ mmusic mailing
>>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>>
>