Re: [MMUSIC] ICE and RTCP host components

Roman Shpount <roman@telurix.com> Tue, 20 October 2015 18:01 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 893601A88D8 for <mmusic@ietfa.amsl.com>; Tue, 20 Oct 2015 11:01:15 -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 Y0zKGie8ypKr for <mmusic@ietfa.amsl.com>; Tue, 20 Oct 2015 11:01:14 -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 4E9861A88E8 for <mmusic@ietf.org>; Tue, 20 Oct 2015 11:01:14 -0700 (PDT)
Received: by iodv82 with SMTP id v82so31023516iod.0 for <mmusic@ietf.org>; Tue, 20 Oct 2015 11:01:13 -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=kGK3zBfdkSHlfk3AmU+WBbWJm1hbmDFB8+8jseJkdYs=; b=ATEk4aYoWhCH4xS2g4LLsekwbvp6Fs90BxmanJncpjagDFIjYJikvGqV3kO568C7jn gnEkplqpNhDHbKP7cl488ySfvRBa9U9cHuK6EowlxLmW6KYXVaFZEGb2b4DQQr2zosSP 9DK38cCcJTLfHaDHaVYpY86H3VzR3hx+Ktkxxk0q12bWJu0XISdGtZzNbkSbDX60SRZ+ 938wgGoviGS36vqEe3QBf0xfB+OcRfT6aqPH6EfFe+SKAuGwxKhllVBtSId8BzY4F5kt HsWQJUTuYvnM9PA0DoYL3yn5e7pTREq9odNbn5pCgor+marF0FQ0N7XosFjsf1Yc4w71 yz8g==
X-Gm-Message-State: ALoCoQmHyL8trqDStn8ILRWQfYDzjDzJfFESyaWSadArQ1nYH/aTsWKN9FaOjr28fDFlMQm3Rr65
X-Received: by 10.107.3.156 with SMTP id e28mr5424275ioi.151.1445364073740; Tue, 20 Oct 2015 11:01:13 -0700 (PDT)
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id o142sm1932701ioe.17.2015.10.20.11.01.12 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 11:01:12 -0700 (PDT)
Received: by igdg1 with SMTP id g1so68924073igd.1 for <mmusic@ietf.org>; Tue, 20 Oct 2015 11:01:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.20.74 with SMTP id l10mr1687115ige.2.1445364072124; Tue, 20 Oct 2015 11:01:12 -0700 (PDT)
Received: by 10.36.205.67 with HTTP; Tue, 20 Oct 2015 11:01:12 -0700 (PDT)
In-Reply-To: <56266954.3080206@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B37B7AC27@ESESSMB209.ericsson.se> <56266954.3080206@alum.mit.edu>
Date: Tue, 20 Oct 2015 14:01:12 -0400
Message-ID: <CAD5OKxtxHwjdaDnmK9LORM9M0YqQQb+-h66dV8C8Lgy8a6WYiA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=047d7bd75270171fd605228d0ccc
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/zg5JEfuOsXRQBPWmzqwPPPlbhuk>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE and RTCP host components
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: Tue, 20 Oct 2015 18:01:15 -0000

On Tue, Oct 20, 2015 at 12:18 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>
wrote:

> Assume the offerer uses a=rtcp to specify a port for RTCP, but the
>> answerer doesn’t support the attribute (and instead will use RTP port+1
>> for RTCP): Does that mean that the offerer needs to allocate RTCP host
>> components both for the a=rtcp value and RTP port+1?
>>
>
> This has always been non-sensical to me. The reason to use a=rtcp is
> because you *can't* use the +1 rule. I don't see how this could ever work
> when the answerer doesn't support it. But neither do I have an idea how it
> could have been fixed.
>

I think originally a=rtcp was essentially best effort. If answerer did not
support rtcp attribute then sender will not get the RTCP. For legacy audio
flows that was good enough.

Also, if ICE is used without TURN with STUN server only, offer will need to
use rtcp attribute, since the candidate which ICE end point should put in
the m=line should be the server reflexive one, which will likely have the
RTCP port not being rtp+1. This, of cause, is only needed for legacy
interop with the end points that do no support ICE and will use only the
IP/ports from the m= line and rtcp attribute.

Bottom line, if you plan to support end points which do no implement ICE
and end points which are behind NAT at the same time, and you do not make
rtcp-mux required, you must support rtcp attribute.

I almost feel like making ICE required for anything that implements BUNDLE
is the simplest solution.
_____________
Roman Shpount