Re: [MMUSIC] BUNDLE and RTCP

Roman Shpount <roman@telurix.com> Mon, 19 October 2015 18:13 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E121B2B0C for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 11:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 XGF4CCxHv3if for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 11:13:37 -0700 (PDT)
Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (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 71E581B2AFE for <mmusic@ietf.org>; Mon, 19 Oct 2015 11:13:36 -0700 (PDT)
Received: by iofz202 with SMTP id z202so62005992iof.2 for <mmusic@ietf.org>; Mon, 19 Oct 2015 11:13:36 -0700 (PDT)
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:content-type; bh=67ujJo7LjoxvWs8U2Mmxmkzd6MuwfUC74Zld0K1Svt8=; b=YeFH++/a2i7FRxI6e/y8Hwv6f6HDoxeu1Hf8F3h4yShxeGjaH2CB/ftiIrlrz13bvQ tBp6YPADE+Db4+x36si/V/tw9bqnrR5EoDY8h1rr3tdQCzjwdh+ZC/K8wz9k8NSKr9Pm BqG21s+gBDtQ+OE6jrMqqicBw4iQllKdS1PF/AMyx88uC43sdqvwdTRQMkD6+6Zk+RBv j7rGlsSCNsF9W+FIyZk0uyEsKxDJX3ULTWGogzMevJBUPj5YY3GVHv+avU+r7AgdzreK 5E5kuCCueHymM6UbppJ74WYN5N4ReggUshMH33xYOiMbynhtOPIPq9G11CMECKPDIRjg 3hNQ==
X-Gm-Message-State: ALoCoQkAj7uBtv+iGrpi9mb2+XPz+F2Z//ys6Fy/vDMoqISRVl6Cm8J6/oHYe6GRZOkDgEwgI4TH
X-Received: by 10.107.47.219 with SMTP id v88mr10192137iov.134.1445278415797; Mon, 19 Oct 2015 11:13:35 -0700 (PDT)
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id t7sm8189423igz.10.2015.10.19.11.13.34 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 11:13:34 -0700 (PDT)
Received: by iofz202 with SMTP id z202so62003950iof.2 for <mmusic@ietf.org>; Mon, 19 Oct 2015 11:13:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.160.208 with SMTP id j199mr10245347ioe.146.1445278413892; Mon, 19 Oct 2015 11:13:33 -0700 (PDT)
Received: by 10.36.205.67 with HTTP; Mon, 19 Oct 2015 11:13:33 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B74FB0@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37B66DC9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B66EEC@ESESSMB209.ericsson.se> <56248496.2050408@gmail.com> <7594FB04B1934943A5C02806D1A2204B37B6CAC0@ESESSMB209.ericsson.se> <562495FD.7020603@gmail.com> <7594FB04B1934943A5C02806D1A2204B37B6CCC5@ESESSMB209.ericsson.se> <5624FC9C.90904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B74CDC@ESESSMB209.ericsson.se> <562522FB.40706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B74FB0@ESESSMB209.ericsson.se>
Date: Mon, 19 Oct 2015 14:13:33 -0400
Message-ID: <CAD5OKxsx+aHK4b-DFE=n4d+SA_it+SPq_O9cJ6ES3zRaxy7UkQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a1140bfd876349a0522791ab9
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/16Tk53z1Jw1D4rv9rUsmHykWqlc>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] BUNDLE and RTCP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 18:13:39 -0000

On Mon, Oct 19, 2015 at 1:48 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> > IIRC the original reason for a=rtcp was because there are cases when it
> is hard to get an even/odd pair of ports. If the offerer is in that
> situation, then mandating port+1 isn't going to work.
>
> Ok. So, I guess one question is whether such situations still can occur.
>

This situation will occur if you are using BUNDLE with server reflexive
ports from behind NAT without ICE and rtcp-mux. Typically client allocates
two subsequent ports for RTP/RTCP, does STUN requests to determine the
server reflexive address/port and ends up with two non-sequential ports.


> > I am coming around to agree with just requiring rtcp-mux with bundle.
> > I don't unsderstand why RTCP was *ever* defined to run on a separate
> port. Maybe it was just a mistake.
>
> As far as I know, some people still wish to be able to use separate ports
> for RTP and RTCP, even when using BUNDLE. I'd like to know whether port+1
> works for them.


I think some people really wanted non-rtcp-mux together with BUNDLE to
simplify implementation of RTP forwarders that bridge BUNDLE and non-BUNDLE
implementations for cases when RTP payload collides with RTCP.

<sarcasm>Having a non-ICE device behind NAT which is doing non-BUNDLE to
BUNDLE RTP forwarding would be fairly strange, but I am sure someone would
eventually decide that they need a corporate SBC which works exactly like
this.</sarcasm>
______________
Roman Shpount