Re: [AVTCORE] [MMUSIC] RTP/RTCP-mux: Attribute in answer if not included in offer?

"Roni Even" <> Mon, 30 May 2016 14:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A018C12D5E6; Mon, 30 May 2016 07:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fJsvUD-mL-JN; Mon, 30 May 2016 07:19:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93A6A12D5E3; Mon, 30 May 2016 07:19:09 -0700 (PDT)
Received: by with SMTP id n129so73194079wmn.1; Mon, 30 May 2016 07:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=KUxdjzWqZ12ybSY1BE1ceYJ1JBpSEBTExcPFok5wDY0=; b=TTRNcneNYC9FsvkgSmmDw19vb5E1VLutoPvyCgZi3PDjz7lRFB2GoACXZVSeqnwKkv moODTOVAEubyMpcmsgdyuMSWmn1xt1FYk/ryHDqSXhG4P40OYs+wqO+gZzz+qQok8Mjv u+XWm0h/QaBm8r27VheuMh2w0y6nCP1E1iOo0h2yU3CNG0aaqOonNPrV+B+G4cwyeLT7 qjMmatDvz385g3OqewemJ0JWoA42AApPoHXM+JnypA4iyGotMfBjzYYX4XtDuTsTlNdO D3hHsDZZmwBwSC73ik0zpBxvk2Eo1WqEutMKwUNXm5yG1ynyhsx9IXZ1GNTe1mL0wGKH 16NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=KUxdjzWqZ12ybSY1BE1ceYJ1JBpSEBTExcPFok5wDY0=; b=BGGpu7Rtdnq6aMYi+2bnRBfaygpg6zsqw915mQeMDmGWzRU8PFF9iVxglGgQ6Kqx96 JpZlOTmddCrmaOoqa1bzyewdjg2CoJ4ca4X0QcPfVQUI8HQ0WP0s5kh7csTKpmj2O0hs E9goowDkXTcVqri42giml2kQHxISfcocuBeJ7xqFupV/oQv2xj3hXoy5f7eJsJzDvfF5 QGiPKhosPbPwA7Rd0P1g+NPdsuf6OE2IQzy4H29FPkDd4r4UEyTnrUVueBWjKXjNn0NV uf+viO2P+Hd3ARW/e6A7eUPKPnvl10PAhrd+N1AsbG55CjaSY9WcB//QNUdw6vq+quXh Drcw==
X-Gm-Message-State: ALyK8tICvKHfoEVRSMVw+fanJ8rDjJ/GoHPqkphr9l4rcOmwBUXKnwYMW6zRNPGrixWZpQ==
X-Received: by with SMTP id ly3mr26748457wjb.135.1464617948021; Mon, 30 May 2016 07:19:08 -0700 (PDT)
Received: from RoniPC ( []) by with ESMTPSA id jp2sm34716330wjc.16.2016. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 07:19:06 -0700 (PDT)
From: "Roni Even" <>
To: "'Suhas Nandakumar'" <>, "'Christer Holmberg'" <>
References: <> <>
In-Reply-To: <>
Date: Mon, 30 May 2016 17:18:09 +0300
Message-ID: <04d601d1ba7e$189ec900$49dc5b00$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04D7_01D1BA97.3DEDFCD0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIVDnqmqgE4v4cr5iz6Tekgwmz3YwI2aa3Tnzkp6SA=
Content-Language: he
Archived-At: <>
Cc: 'Magnus Westerlund' <>, 'Colin Perkins' <>,,
Subject: Re: [AVTCORE] [MMUSIC] RTP/RTCP-mux: Attribute in answer if not included in offer?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 May 2016 14:19:12 -0000


Agree with Suhas but have a question

What if the offer has an a=rtcp with a port different from the RTP one, and the response include a=rtcp using the same port as the RTP port? Is it allowed, at least in RFC3605 did not see any discussion about this




From: mmusic [] On Behalf Of Suhas Nandakumar
Sent: Friday, May 27, 2016 4:26 AM
To: Christer Holmberg
Cc: Magnus Westerlund; Colin Perkins (;;
Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?


Going along O/A negotiation procedures, i would lean towards your former conclusion that the offer needs to include the rtcp-mux ability.

If the offer doesn't include a=rtcp-mux and the answerer wants to mux , then it needs a new O/A from the answerer's perspectives.



If we make a=rtcp-mux a declarative SDP it might solve the other use-case ..





On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg <> wrote:

(Sorry for the cross-posting)




There has been a discussion in 3GPP regarding RFC 5761 (RTP/RTCP-mux).


Section 5.1.1 says:


5.1.1.  SDP Signalling


   When the Session Description Protocol (SDP) [8] is used to negotiate

   RTP sessions following the offer/answer model [9], the "a=rtcp-mux"

   attribute (see Section 8) indicates the desire to multiplex RTP and

   RTCP onto a single port.  The initial SDP offer MUST include this

   attribute at the media level to request multiplexing of RTP and RTCP

   on a single port.  For example:



       o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e


       c=IN IP6 2001:DB8::211:24ff:fea3:7a2e

       t=1153134164 1153137764

       m=audio 49170 RTP/AVP 97

       a=rtpmap:97 iLBC/8000



   This offer denotes a unicast voice-over-IP session using the RTP/AVP

   profile with iLBC coding.  The answerer is requested to send both RTP

   and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.


   If the answerer wishes to multiplex RTP and RTCP onto a single port,

   it MUST include a media-level "a=rtcp-mux" attribute in the answer.

   The RTP payload types used in the answer MUST conform to the rules in

   Section 4.


   If the answer does not contain an "a=rtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,

   it should send and receive RTCP on a port allocated according to the

   usual port-selection rules (either the port pair, or a signalled port

   if the "a=rtcp:" attribute [10] is also included).  This will occur

   when talking to a peer that does not understand the "a=rtcp-mux"



Q: The question is whether it is allowed to include a=rtcp-mux in an answer if the associated offer did NOT contain a=rtcp-mux.


The second last paragraph in the text above does say that, if the answer wishes to do RTP/RTCP-mux, it includes a=rtcp-mux in the answer.


BUT, in my view that is it based on the first paragraph, which assumes a=rtcp-mux is also included in the offer.


Or, am I wrong? Is it allowed to include a=rtcp-mux in the answer, even if it’s not included in the offer? If so, how will the offerer then indicate whether mux is used or not.






Audio/Video Transport Core Maintenance