IETF Logo Mail Archive

Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 24 April 2017 10:48 UTC

Return-Path: <christer.holmberg@ericsson.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 D396F12EC4B for <mmusic@ietfa.amsl.com>; Mon, 24 Apr 2017 03:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3rwrnQ88qPoJ for <mmusic@ietfa.amsl.com>; Mon, 24 Apr 2017 03:48:23 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFDA12F268 for <mmusic@ietf.org>; Mon, 24 Apr 2017 03:48:22 -0700 (PDT)
X-AuditID: c1b4fb3a-9397998000006079-b9-58fdd7f4279e
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 7E.1C.24697.4F7DDF85; Mon, 24 Apr 2017 12:48:20 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Mon, 24 Apr 2017 12:46:20 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Asveren, Tolga" <tasveren@sonusnet.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?
Thread-Index: AQHSvOgCNt6Dk7x2uEaNj1LXZRgEJA==
Date: Mon, 24 Apr 2017 10:46:20 +0000
Message-ID: <D523B2CC.1B92C%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_D523B2CC1B92Cchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdRffL9b8RBst3W1lMXf6YxWJ253sm ByaPJUt+Mnlc+vyfPYApissmJTUnsyy1SN8ugSuj8983loLXXhV//09kaWD86NDFyMkhIWAi sfP2eqYuRi4OIYH1jBJT339nB0kICSxhlLhxUriLkYODTcBCovufNkhYRCBY4nnDDyYQW1gg SOL2mumMMPFri/YzgpSLCOhJNL+LBgmzCKhKXDrQywJi8wpYS2x+cpEZxGYUEJP4fmoN2Bhm AXGJW0/mM0GcIyCxZM95ZghbVOLl43+sILYo0Mh9/76yQcQVJa5OXw7VmyAx9cBlqPmCEidn PmGZwCg0C8nYWUjKZiEpg4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNtaYnLDezZkNQsYOVYx ihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbOwS2/rXYwHnzueIhRgINRiYf3gfLfCCHWxLLi ytxDjBIczEoivN0rgEK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJ MnFwSjUw+gtxzihUsJpTX2xpwr7J/veyw1+2iPb/27u2p9xJS/Wn2BKW1LSLM6atSPN0tPOS e2YX2PPwmOlcbkG7gqj9JuImz6+u32phveuN8KuzziduWE6+XLda8fTRQ69D7SdYpFWHsXll v/dlXbfqiOgF1ULvMwzcxneCCxf80NF4XFMdZVHyrSxCiaU4I9FQi7moOBEADzhroJkCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/c09HaZx_VoJXwwP7aSAN3l4BAGk>
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 24 Apr 2017 10:48:25 -0000

Hi,

RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where we clarify that negotiated mux is always bidirectional.


   "This document updates RFC 5761 [RFC5761] by clarifying that an
   answerer can only include an "a=rtcp-mux" attribute in an answer if
   the associated offer contained the attribute.  It also clarifies that
   the negotiation of RTP and RTCP multiplexing is for usage in both
   directions."

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>> on behalf of Tolga Asveren <tasveren@sonusnet.com<mailto:tasveren@sonusnet.com>>
Date: Monday 24 April 2017 at 13:24
To: "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will be always bidirectional. OTOH, I think RFC5761 allows unidirectional semantics:

5.1.1. SDP Signaling
…

   When SDP is used in a declarative manner, the presence of an "a=rtcp-
   mux" attribute signals that the sender will multiplex RTP and RTCP on
   the same port.  The receiver MUST be prepared to receive RTCP packets
   on the RTP port, and any resource reservation needs to be made
   including the RTCP bandwidth.

Actually this part of RFC5761 sounds a bit odd as in declarative mode I thought an attribute would convey information about the “receipt properties” therefore “rtcp-mux” would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.

It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive that unidirectional multiplexing with declarative mode is not supported.

Example scenario:
A sends rtcp-mux/rtcp-mux-only
B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, it does not want to send multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.
A terminates the session because the answer does not contain rtcp-mux. It can’t determine whether multiplexing is not supported at all or whether B wants to use it in a unidirectional way.

Thanks,
Tolga

v2.23.0 | Report a Bug | By Email