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

"Roni Even" <ron.even.tlv@gmail.com> Wed, 22 June 2016 15:48 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7212D8B0; Wed, 22 Jun 2016 08:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SNK1UCKvU8tj; Wed, 22 Jun 2016 08:48:47 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 CBB9A12DC44; Wed, 22 Jun 2016 08:37:27 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id f126so92895218wma.1; Wed, 22 Jun 2016 08:37:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.194.95.74 with SMTP id di10mr25846057wjb.52.1466609846324; Wed, 22 Jun 2016 08:37:26 -0700 (PDT)
Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id u71sm1179456wmu.13.2016.06.22.08.37.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 08:37:25 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Christer Holmberg'" <christer.holmberg@ericsson.com>, "'Suhas Nandakumar'" <suhasietf@gmail.com>
References: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se> <CAMRcRGRK2s1MrgxsoHir6cF1n6WU1FTEFEAeTJ+VPzcmS9HSHw@mail.gmail.com>, <04d601d1ba7e$189ec900$49dc5b00$@gmail.com> <7594FB04B1934943A5C02806D1A2204B3801E9C6@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3801E9C6@ESESSMB209.ericsson.se>
Date: Wed, 22 Jun 2016 18:35:59 +0300
Message-ID: <13f501d1cc9b$c8409d50$58c1d7f0$@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/avt/ChV1UB1ooIplCdBRe_GKmsBxVLM>
Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, mmusic@ietf.org, 'Colin Perkins' <csp@csperkins.org>, avt@ietf.org
Subject: Re: [AVTCORE] [MMUSIC] RTP/RTCP-mux: Attribute in answer if not included in offer?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=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?

Roni

 

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

 

Hi,

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).

Regards,

Christer

Sent from my Windows Phone

  _____  

From: Roni Even <mailto:ron.even.tlv@gmail.com> 
Sent: ‎30/‎05/‎2016 17:19
To: 'Suhas Nandakumar' <mailto:suhasietf@gmail.com> ; Christer Holmberg
<mailto:christer.holmberg@ericsson.com> 
Cc: Magnus Westerlund <mailto:magnus.westerlund@ericsson.com> ; 'Colin
Perkins' <mailto:csp@csperkins.org> ; avt@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not
included in offer?

Hi,

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

 

Roni

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Suhas Nandakumar
Sent: Friday, May 27, 2016 4:26 AM
To: Christer Holmberg
Cc: Magnus Westerlund; Colin Perkins (csp@csperkins.org); mmusic@ietf.org;
avt@ietf.org
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 ..

 

thanks

Suhas

 

On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:

(Sorry for the cross-posting)

 

Hi,

 

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:

 

       v=0

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

       s=-

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

       t=1153134164 1153137764

       m=audio 49170 RTP/AVP 97

       a=rtpmap:97 iLBC/8000

       a=rtcp-mux

 

   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"

   attribute.

 

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.

 

Regards,

 

Christer

 


_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt