IETF Logo Mail Archive

Re: [MMUSIC] The way forward wih mux-exclusive

Roman Shpount <roman@telurix.com> Thu, 14 April 2016 19:49 UTC

Return-Path: <roman@telurix.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 DB2DE12E0AF for <mmusic@ietfa.amsl.com>; Thu, 14 Apr 2016 12:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
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 ZrY_o6Z72wnU for <mmusic@ietfa.amsl.com>; Thu, 14 Apr 2016 12:49:03 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 E3C9512DD40 for <mmusic@ietf.org>; Thu, 14 Apr 2016 12:49:02 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id g185so114651811ioa.2 for <mmusic@ietf.org>; Thu, 14 Apr 2016 12:49:02 -0700 (PDT)
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; bh=YzvYs5uWIxKC0uycs+X40wqbZu3hl249mw8nhI0DJMI=; b=txQZ/OSoC9recXcfiSCyFwostZLExzn3U4L9vrHy6b6Jp5c9vjbr81BMqbuV4IHpio Cc5k/PA7j94rBdmHjStn6QxcWrHf1yZ5bX2L4YRyDrfY4TRR3rk0beZvNTpugZlAp8Ut 4uNgz1evUFthfhoL3+Fcncp/f77CA0P11gJK9UaTrPKhgkz2eF8X9v2BZED/U8MXHaau IgSGoBaesoMPvgBzGJlIFn9k6SttCZQyFkKrsUbq72XWi+JM133dmui/uNThUiG/XXkP UxBMBDWc4cKG5DNtiRbElSiSCEcJTcoHrFHMmgc7zwLc2OuD6rJvgsIJnua/r6hQxS1J aQoQ==
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; bh=YzvYs5uWIxKC0uycs+X40wqbZu3hl249mw8nhI0DJMI=; b=b0RMJBzQND7GD/mNgBSUZbdNh229CVj4kTf0UVqu9pA5VJ8ZP7kIQXzRGEU1t5l+3L HD1LQ5PPXOjhJpbYhhAtLS3QCUvEuUCSZssaGLMc9Cb5s4Pl9+H7Ukn9G44I5qWwapze TRvlWbrisxiCibs7/3VFEmRpQA0gITqQVxhuF0/WQBNrG5dZmvwt5yaBcpnGI5f4ZcKi lA3XdPwwhdoGZQBvR5GwweVSyOiOWEOkDlZHp7LwQMCofle8TcDRp0b4U/+yeaM4OXLY 8eAwl7cSw9cBwYt+ydwMX4FRe5qRBbK9Wn7Ci8/bGpNSU6iEJdZXNExnQ6fv0UUKXKw6 y16g==
X-Gm-Message-State: AOPr4FUdZZ4dGPaYuWLMxaLVprpIPuC6tCdLFrWGxd64u8W42AYIHdQI3li3S/FjM4M1jA==
X-Received: by 10.107.173.69 with SMTP id w66mr20064851ioe.182.1460663342257; Thu, 14 Apr 2016 12:49:02 -0700 (PDT)
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id cj5sm3808122igc.1.2016.04.14.12.49.01 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 12:49:01 -0700 (PDT)
Received: by mail-io0-f169.google.com with SMTP id u185so114528948iod.3 for <mmusic@ietf.org>; Thu, 14 Apr 2016 12:49:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.30.71 with SMTP id e68mr18682754ioe.145.1460663341327; Thu, 14 Apr 2016 12:49:01 -0700 (PDT)
Received: by 10.36.106.194 with HTTP; Thu, 14 Apr 2016 12:49:01 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se>
References: <5707C2A6.2060001@cisco.com> <CAD5OKxshqQA5YMn6RuALcWhYjLTQB4d-H-7+JatMwO7AnT+pCw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> <CAD5OKxtj-58ZN5VqKouu3Pf6c3Hjd+eQz9aD_a6+cLgaf-98tw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se>
Date: Thu, 14 Apr 2016 15:49:01 -0400
X-Gmail-Original-Message-ID: <CAD5OKxuq+djAMceiweSpzNtfVWHzBtm=n8-=-uuhybVHAtvNHQ@mail.gmail.com>
Message-ID: <CAD5OKxuq+djAMceiweSpzNtfVWHzBtm=n8-=-uuhybVHAtvNHQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1140d71e98c09d0530772fd3"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/RD-iIbv9Ym9oh6jZTHRj_C5ThcY>
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] The way forward wih mux-exclusive
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 14 Apr 2016 19:49:06 -0000

This can currently produce interop problems. With current usage, if
rtcp-mux is supported by the remote end point, it will correctly negotiate
with rtcp-mux-exclusive. If you remove rtcp-mux attribute from the offer,
connection will not be established. This will be especially important
during the migration from rtcp-mux to rtcp-mux-exclusive for current
implementations. Only inserting rtcp-mux-exclusive, of cause, is better
long term, since it is removing redundant information from SDP.

Also, does anybody want to rename rtcp-mux-exclusive to rtcp-mux-only? This
is shorter and more inline with typical naming convention for such
attributes.

Regards,
_____________
Roman Shpount

On Thu, Apr 14, 2016 at 3:31 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> So, unless someone objects, I’ll remove the usage of the rtcp-mux
> attribute, and mux exclusive will be indicated using the new attribute only.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Roman Shpount [mailto:roman@telurix.com]
> *Sent:* 14 April 2016 21:38
> *To:* Christer Holmberg <christer.holmberg@ericsson.com>
> *Cc:* Flemming Andreasen <fandreas@cisco.com>; mmusic <mmusic@ietf.org>
> *Subject:* Re: [MMUSIC] The way forward wih mux-exclusive
>
>
>
> On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Currently, the draft defines that, in addition to the new attribute, you
> also insert the rtcp-mux attribute. So, if we keep that, I guess we would
> need to add something to 5761.
>
>
>
> But, if we ONLY include the new attribute (I got the impression that’s
> what people prefer), there is no need to update 5761.
>
>
>
>
>
> Agreed. I simply wanted to point out the RFC5761 requires to provide an
> RTCP fallback when rtcp-mux attribute is used. If RTCP fallback is not
> provided and if rtcp-mux attribute is used (which we are doing now in
> rtcp-mux-exclusive), then we must update RFC5761 (which we are not doing
> now).
>
>
>
> Regards,
>
> _____________
> Roman Shpount
>
>
>

v2.23.0 | Report a Bug | By Email