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

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

Return-Path: <emil@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 AAED321F935A for <mmusic@ietfa.amsl.com>; Mon, 20 May 2013 06:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 kxbLM6DpqC3B for <mmusic@ietfa.amsl.com>; Mon, 20 May 2013 06:18:27 -0700 (PDT)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5F23121F934B for <mmusic@ietf.org>; Mon, 20 May 2013 06:18:27 -0700 (PDT)
Received: by mail-bk0-f51.google.com with SMTP id ji2so3523393bkc.38 for <mmusic@ietf.org>; Mon, 20 May 2013 06:18:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=jqyQ6nZAKBYqBF7N22RVrzGZxtvCa30rYKjQnR3h0O0=; b=UZevl3iRuCt7fXXs44Uz6NEW61zWtWvHv+p2YFkzNffnE42d5Gz+S0UiAtPmMhrQJR WPjcrThaGn/BLfFmG8D8QQ/KE3EKwLwEzzPjQ4y961D6XxRola2ZsuxrdHcg7wYr/9P9 bDzeh9IteVJiMUcZ9dLHOMq/+/jJVG/yC18Gr6clgwOEV6lPIJcHfNBJZiHlUN9yUKc9 Y0+/D+Hvfoq4M8V88pm7mIXrMHeczf1M5Bzi7tvkqE+9dSbag0KWWHz1CRcBnbSYgh4l FdA83OsrkzWysfZQwnOViNV8QH9m6MLHYqQUNWOOjwzh04/3WDE4V7xKGKALa64mrble IX+w==
X-Received: by 10.204.109.200 with SMTP id k8mr19726654bkp.82.1369055906205; Mon, 20 May 2013 06:18:26 -0700 (PDT)
Received: from [192.168.43.3] ([212.5.158.160]) by mx.google.com with ESMTPSA id da16sm5765417bkb.2.2013.05.20.06.18.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 06:18:25 -0700 (PDT)
Message-ID: <519A229D.7090204@jitsi.org>
Date: Mon, 20 May 2013 16:18:21 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlDgYgrscnFDR8ovCzkFHNxxWMHsZM6DQXLtkMG9Cu9kH6xx+mshHLvZyI28Yp07GhsprZ8
Cc: "mmusic@ietf.org" <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: Mon, 20 May 2013 13:18:28 -0000

On 20.05.13, 16:14, Hutton, Andrew wrote:
> 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

> We could say that any port in the bundle could be used but I don't
> see this gains us anything.

Agreed.

Emil
> 
> Andy
> 
> 
> 
> 
>> -----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
> 

-- 
https://jitsi.org