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

"Roni Even" <ron.even.tlv@gmail.com> Mon, 30 May 2016 14:19 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 A018C12D5E6; Mon, 30 May 2016 07:19:12 -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 fJsvUD-mL-JN; Mon, 30 May 2016 07:19:10 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 93A6A12D5E3; Mon, 30 May 2016 07:19:09 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id n129so73194079wmn.1; Mon, 30 May 2016 07:19:09 -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=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; 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=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 10.194.123.67 with SMTP id ly3mr26748457wjb.135.1464617948021; Mon, 30 May 2016 07:19:08 -0700 (PDT)
Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id jp2sm34716330wjc.16.2016.05.30.07.19.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 07:19:06 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Suhas Nandakumar'" <suhasietf@gmail.com>, "'Christer Holmberg'" <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se> <CAMRcRGRK2s1MrgxsoHir6cF1n6WU1FTEFEAeTJ+VPzcmS9HSHw@mail.gmail.com>
In-Reply-To: <CAMRcRGRK2s1MrgxsoHir6cF1n6WU1FTEFEAeTJ+VPzcmS9HSHw@mail.gmail.com>
Date: Mon, 30 May 2016 17:18:09 +0300
Message-ID: <04d601d1ba7e$189ec900$49dc5b00$@gmail.com>
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: <http://mailarchive.ietf.org/arch/msg/avt/I8XIr4O5u_ux4IQTMd_48TKwBjw>
Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, 'Colin Perkins' <csp@csperkins.org>, avt@ietf.org, mmusic@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: Mon, 30 May 2016 14:19:12 -0000

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