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

Suhas Nandakumar <suhasietf@gmail.com> Fri, 27 May 2016 01:25 UTC

Return-Path: <suhasietf@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 0430B12D17D; Thu, 26 May 2016 18:25:47 -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 Dq3yTZEviGH9; Thu, 26 May 2016 18:25:44 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 8104512B062; Thu, 26 May 2016 18:25:44 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id h19so93353454ywc.0; Thu, 26 May 2016 18:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=WX7i0AJ5WERbWO496YH0UZ3LLP0jydSLO7A/R2SyPZA=; b=b+iB+5DeQLdngaE/iQLYvjbN8Lm/3bUNUI25iNRBTi3WBCoKyvxP+gvZQ5ct2j6jx2 KzS//Zz/zIH5OcHzAiStwSzghGUlNsL+gKJGVazLGGx7LjumjxybeVicYkUzSE/gVFhw tGiXvBtd4QaH1bucibNQMdqUHJ44IqSC1dRIZwcHuaCbIDoFxaGX/f+H+ZAt+1zzSDXz ud1MY1lESVLEztrYSlAVRXGI+rsq1UBQfCpsdZwYbzXQxYO57qzsI9WM3LMuaKkiMxyU iVMBKy6Xpd5qYxESr7fk5DCsTsqQfpH2OsEgcRW5wX3vAazn21vVNUIK87RHzONgcOR/ aOsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=WX7i0AJ5WERbWO496YH0UZ3LLP0jydSLO7A/R2SyPZA=; b=k0106QQEAJCvZPPV1pc9aMzDbAoa1y2jk5/LlJrIRjerT4akegAuBcvQyOCYPe9+ZR LBiBPmbuZit0xtWWg8ZA6RwDHjNcfpmD4DS8a0u7nzZO/TpkaSrnMIOYcqEYK7nk5JDL OC+6t6ISC2oI8jyVrHfyrbnE2fJH57YfWc1CQvoYB8ZTwlUVbP9NZ1ja1nHk0kj1O+RL GLH5XgON+P75cV2fLDrx4F4oONCxvNQE+rLPcjLtUVw3DfP5U5ZoCc6lkBTs8vkLw1pd 03RyQ2/SA3tTuP3r66ohq7o8lg4q5TwVOjrsRP+qnrNB+QFG4LR9QSsF3+hSFsuwN1Ux GW8A==
X-Gm-Message-State: ALyK8tJHaaahrgenD+HvEAfaqycgRxY7I12ZbK+sasShrI1bGdO6d1DljA/dTLRdnXNmxRdOju/oai4OVLp6Lg==
MIME-Version: 1.0
X-Received: by 10.37.15.215 with SMTP id 206mr6826554ybp.171.1464312343636; Thu, 26 May 2016 18:25:43 -0700 (PDT)
Received: by 10.129.54.15 with HTTP; Thu, 26 May 2016 18:25:43 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se>
Date: Thu, 26 May 2016 18:25:43 -0700
Message-ID: <CAMRcRGRK2s1MrgxsoHir6cF1n6WU1FTEFEAeTJ+VPzcmS9HSHw@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a113f58e415328b0533c8c91f
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/gYTl7_7Ghctx3dFtZxfam4GGXGs>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "Colin Perkins \(csp@csperkins.org\)" <csp@csperkins.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] 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: Fri, 27 May 2016 01:25:47 -0000

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