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

Emil Ivov <emcho@jitsi.org> Mon, 20 May 2013 13:46 UTC

Return-Path: <emcho@sip-communicator.org>
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 0F37321F8C1A for <mmusic@ietfa.amsl.com>; Mon, 20 May 2013 06:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 MQ0ZeGcsR2ZN for <mmusic@ietfa.amsl.com>; Mon, 20 May 2013 06:46:39 -0700 (PDT)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id AAA9321F93B1 for <mmusic@ietf.org>; Mon, 20 May 2013 06:46:39 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id bg2so5640187pad.25 for <mmusic@ietf.org>; Mon, 20 May 2013 06:46:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=5fniZlfr1ouQCyjsmqSRDHEfN186rsM/us1D0dMRCkU=; b=MeZSFmgdf7uogErzh/acTySJrm0IO8xMW0GWeHeBiCDxc1xYRI6Zb+0U687xXKoYso 8aQFs1ffTu8i8o9TVJtK5Mf4fA54KLmWFFQFkGVNP2+qQA5dwEt6XNAa1PbA9R+FlOPm oEFdxrttZ3pr/oivuIfZGm5SuY87qs7Zfj1Jsk7uukkUkXIlMh7Y5zs1IqtkLzNFiOMo PmrVz9uvaa49iRqTgtkYqgz4at94EbEp4FQFNTEi9ohdCdqYAnZxOfq2kPo7xPbRTbNl zbuFbVGPmoH/NpZqNo+SmmO154q5q0BvcuV9b4wn+fNSK1iwdOc96VQ5jE0B/AzxvW4C ItIw==
X-Received: by 10.66.193.136 with SMTP id ho8mr19964777pac.27.1369057599345; Mon, 20 May 2013 06:46:39 -0700 (PDT)
Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [2607:f8b0:400e:c01::22c]) by mx.google.com with ESMTPSA id ih1sm24185611pbb.44.2013.05.20.06.46.38 for <mmusic@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 06:46:39 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id wz12so1102351pbc.31 for <mmusic@ietf.org>; Mon, 20 May 2013 06:46:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.115.167 with SMTP id jp7mr59717311pbb.145.1369057598345; Mon, 20 May 2013 06:46:38 -0700 (PDT)
Received: by 10.66.27.148 with HTTP; Mon, 20 May 2013 06:46:37 -0700 (PDT)
Received: by 10.66.27.148 with HTTP; Mon, 20 May 2013 06:46:37 -0700 (PDT)
In-Reply-To: <519A2768.5010904@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>
Date: Mon, 20 May 2013 16:46:37 +0300
Message-ID: <CAPvvaa+A=LkYp9A+wENAABwCYaQcD0HVeX4o+O_16iJRPXZfNw@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=e89a8ffba1afd3ae5104dd268f1c
X-Gm-Message-State: ALoCoQm1ND5LO/XqusrLuOFcByyF178vjZPFQ7jz1HPX7/YyN5zlFn0W3xS0YhPrmxSG68wfkip1
Cc: 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: Mon, 20 May 2013 13:46:44 -0000

What happens when the offerer knows the answerer has bundle support, sends
all m-lines with the same port, then the answerer splits the first line
away from the bundle? Would the answerer still send everything to the same
port?

If so, I don't see why it should be different in the case where the offerer
could not make the assumption about the bundle support.

--sent from my mobile
On May 20, 2013 4:39 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

> 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 <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://www.ietf.org/mailman/listinfo/mmusic>
>>>>>
>>>>>
>>>> -- https://jitsi.org
>>>> ______________________________**_________________ mmusic mailing
>>>> list mmusic@ietf.org https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>>>>
>>>
>>>
>>
> ______________________________**_________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>