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

"Roni Even" <> Wed, 22 June 2016 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34B7212D8B0; Wed, 22 Jun 2016 08:48:50 -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 SNK1UCKvU8tj; Wed, 22 Jun 2016 08:48:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBB9A12DC44; Wed, 22 Jun 2016 08:37:27 -0700 (PDT)
Received: by with SMTP id f126so92895218wma.1; Wed, 22 Jun 2016 08:37:27 -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=Th9CdbO0JSnEiQRyy6YR6TOUAh/lfGJzx/u0r1zL3ao=; b=DD6qxsk2Hvsurhix4divT2sUAZZbpb7YSj7w5dYs/bamfY7tWvsP8qsPj8fXiUfAOy QQBDEy/r+4O1CdaPOX8mpztFggSxgWXIzazVzT7z+jf/sBBd0duajcrZfgEQsb15WD3z XJPufr9iITDK9BBfSJxDzoXIuL+LX14kTxYlHTOZzgu9KvApocPO+I1FJMHLIR/G3dzt MT1PPBk8DRnaWtWfT2PnX/XnW42R/ow8QHdC8cWb4bpg9tn6eX4i1I8aYPS7o7p0Wg9f dmTkefej3HAEQUO4kOR8hFG1Hl3P/R+2DmBegw4SPzkG+Pvv7vUVxqBxrVvtjyxqg1oa 3vlg==
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=Th9CdbO0JSnEiQRyy6YR6TOUAh/lfGJzx/u0r1zL3ao=; b=Uh5f8wg58M9/pLLJ1vLe9uzTZ/SmzbPc6VwbSnbi+SRv3Af+lwz3Ltk2aEcjMWNUxc xaru0G62ELvgKZN+NOFiuT0jQi8PL70BigKFkHy0d6zrYvuqR6/wbk2WngGymNRifmf9 041cdnB7UXFlgijda16gcPYD362+SOpCL2Df8O4iUIvGLX8Rwuc8rEsy2dxWzMfpsrGS hTtMdnTty+y4giNGHEV8wpHMs+iWckfEbN/RTzCMvINgxzpFdMoxeU8GWFgeQofAAFPx oT7wRDHn25lYfIo5JFd36aUfQJQZr2i9dAWMyueXzk6UdVpL6VavAiGaHNW4Rbvg9pAm oxRA==
X-Gm-Message-State: ALyK8tI93QJ6NtDB8js8ZXokWD4VFPMvi9/5FfbH42qhbw/eBL840QfJvIhGzK2ynHzeDA==
X-Received: by with SMTP id di10mr25846057wjb.52.1466609846324; Wed, 22 Jun 2016 08:37:26 -0700 (PDT)
Received: from RoniPC ( []) by with ESMTPSA id u71sm1179456wmu.13.2016. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 08:37:25 -0700 (PDT)
From: "Roni Even" <>
To: "'Christer Holmberg'" <>, "'Suhas Nandakumar'" <>
References: <> <>, <04d601d1ba7e$189ec900$49dc5b00$> <>
In-Reply-To: <>
Date: Wed, 22 Jun 2016 18:35:59 +0300
Message-ID: <13f501d1cc9b$c8409d50$58c1d7f0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_13F6_01D1CCB4.ED904650"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIVDnqmqgE4v4cr5iz6Tekgwmz3YwI2aa3TAgpzyWkB91axhp89WGvg
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: Wed, 22 Jun 2016 15:48:50 -0000

Hi Christer,

I am not sure I understand you answer. I was wondering if the answerer can
ask to receive RTP/RTCP multiplex even if the offer did not include the
rtp/rtcp-mux attribute by providing in an

A=rtcp the port of for the RTP stream?



From: Christer Holmberg [] 
Sent: Monday, May 30, 2016 5:26 PM
To: Roni Even; 'Suhas Nandakumar'
Cc: Magnus Westerlund; 'Colin Perkins';;
Subject: RE: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not
included in offer?



In an offer a=rtcp is used to provide a fallback port, in case the answerer
does not support RTP/RTCP-mux (but does support a=rtcp).



Sent from my Windows Phone


From: Roni Even <> 
Sent: ‎30/‎05/‎2016 17:19
To: 'Suhas Nandakumar' <> ; Christer Holmberg
Cc: Magnus Westerlund <> ; 'Colin
Perkins' <> ;;
Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not
included in offer?


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