Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01

Roman Shpount <roman@telurix.com> Fri, 11 December 2015 20:35 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABCF1A1DE1 for <mmusic@ietfa.amsl.com>; Fri, 11 Dec 2015 12:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 769Ioh5SlZY0 for <mmusic@ietfa.amsl.com>; Fri, 11 Dec 2015 12:35:21 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9A01A19F7 for <mmusic@ietf.org>; Fri, 11 Dec 2015 12:35:21 -0800 (PST)
Received: by mail-ig0-x236.google.com with SMTP id su19so47160539igc.0 for <mmusic@ietf.org>; Fri, 11 Dec 2015 12:35:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RPjpCGTN2TL3gXq0vvhur9GDAU7plZ/kKRW9BupwmIo=; b=p+RV6JZ7S+pGgE8V3E2j3DVWQFrTFNhvKgGOJw7a6B0Zx1/jB+ReCCkXN93OyQuk0i jwwVRQNab/n+qjKd2bTuuRQzt5K7ftLrZzuK3ZqX/Cy51M1txlmL2WCmKRgeNNnBtpOz AP/znViuvEuPCk8WTzh+zlM5uBs5hiHqslThuXjGx1Qrz7RL0A/PKvqueuVtGzJBP+Zq uX7uGj5inN+YPTj130eJa03LQRg8pT1J2OE12rB5z82UTybM37TacQa6bUWez6upr55Q ua7qNKeuX/QgJ65vbRrjbSFVdtE5udC/IP8DdvvnFUORGPREdn3iFXhML8OevcU/sqgA Sleg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RPjpCGTN2TL3gXq0vvhur9GDAU7plZ/kKRW9BupwmIo=; b=SVSlufoybQK+cKmp4C88h2lJYTmNongRBxdQ6rRhi0qgPAVB87oK7jqXC3iAT2nBR3 03cJiuke6CKDSSxpTGxGihbyB2j04qYZWLLSOSjbs8kxKD8SC0y4tySdc4r1auI0Ek5I b8muQ0/zs3XjySOGP5huMqerleIZI8I2JxdEuz6UTDldPN3fK2ern4aKu4dInjfQGJ0P AqjiFMBhzPKr+kQKW9So+Wgrl0H4l/vpvIGsYCUt3p880W08YhR2mosYQX5FxOfQ/rYA UiSGoby4NrpwJvnDrJ3s1o6Efm94kIGEV2gkuGLNCcYUeIbLSImhE84zwkYDRphyMGo6 62gQ==
X-Gm-Message-State: ALoCoQl7KiuaDWTMDrNsX6KgkhRcZI4LCU/I+TWFPZowrjVzb/vJU18Vp8RwnqYN4pEeYFe38Eut9BzonlWM0ZLnwH5W71Pduw==
X-Received: by 10.50.61.37 with SMTP id m5mr6764235igr.4.1449866120559; Fri, 11 Dec 2015 12:35:20 -0800 (PST)
Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id qr1sm1955149igb.21.2015.12.11.12.35.18 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Dec 2015 12:35:18 -0800 (PST)
Received: by igbxm8 with SMTP id xm8so47080973igb.1 for <mmusic@ietf.org>; Fri, 11 Dec 2015 12:35:18 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.23.73 with SMTP id k9mr2948204igf.2.1449866118321; Fri, 11 Dec 2015 12:35:18 -0800 (PST)
Received: by 10.36.205.4 with HTTP; Fri, 11 Dec 2015 12:35:18 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C96443@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37C8D07A@ESESSMB209.ericsson.se> <CAD5OKxsP0_epa+16XgX-v3CumvQ9Uqg7qZuPfuNweo9a9Q1peQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37C96443@ESESSMB209.ericsson.se>
Date: Fri, 11 Dec 2015 15:35:18 -0500
X-Gmail-Original-Message-ID: <CAD5OKxvcZNQx=v+hRZrxXUMi001rafn5MjeNVaor7gkoFL+P9g@mail.gmail.com>
Message-ID: <CAD5OKxvcZNQx=v+hRZrxXUMi001rafn5MjeNVaor7gkoFL+P9g@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="089e0158a9c4f45e820526a5427b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/SjMcq5gxJSa6FUiz26cAoxIMtlI>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 11 Dec 2015 20:35:22 -0000

On Fri, Dec 11, 2015 at 2:23 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> > 1. Are you stating the rtcp attribute for mux-exclusive MUST not contain
> the optional [nettype space addrtype space connection-address] or that it
> may contain this address and it should be set to the value from the c= line?
>
> Good question.
>
> My idea was that the attribute only contains the port, but I do agree that
> we should say something about the optional parts. Either we:
>
> 1)       say MUST NOT use it; or
> 2)      we say MUST use the value from the c= line; or
> 3       we allow both 1) and 2).
>

Unless there is a reason, we should go with 3. Any endpoint that supports
this draft should fully support SDP rtcp attribute and must be able to
parse rtcp attribute with and without the optional address. After the
attribute is parsed there is no additional burden to determine that rtcp
attribute points to the same address/port as c= and m= lines.

We can also specify that 1 SHOULD be preferred, simply to send less
redundant data in SDP.


> >2. In cases when trickle ICE is used, should rtcp SDP attribute contain
> "9 IN IP4 0.0.0.0" per draft-ietf-rtcweb-jsep section 5.2.1 or "9" per your
> draft? Does this mean that JSEP complaint offer is always rtcp-mux
> exclusive?
>
> Good question.
>
> In that case, if you are yet not providing any candidates to begin with, I
> assume you don't know.
>
> Of course, if we want to distinguish the cases, one option would be to
> e.g. use a port value of zero for mux-exclusive?
>
> Perhaps the b=RR/RS bandwidth indicators could also be used somehow, but I
> hope we can avoid that.
>

This is a tricky situation. When no initial candidates are collected, rtcp
attribute set to port 9 can either mean that no rtcp candidates are yet
available or that mux exclusive is used. I do not know what is the solution
here. We definitely do not want to change mux only to require rtcp
attribute with port 0, since this will break legacy interop with end points
that support rtcp attribute but do not rtcp-mux. We might need an
additional SDP attribute to indicate that rtcp mux exclusive is required.
_____________
Roman Shpount