Re: [MMUSIC] ICE and RTCP host components

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 21 October 2015 04:50 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 74CEE1B2E2B for <mmusic@ietfa.amsl.com>; Tue, 20 Oct 2015 21:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] 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 3rF02RgXohql for <mmusic@ietfa.amsl.com>; Tue, 20 Oct 2015 21:50:19 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461A31A0033 for <mmusic@ietf.org>; Tue, 20 Oct 2015 21:50:19 -0700 (PDT)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-02v.sys.comcast.net with comcast id XgqJ1r00526dK1R01gqJYs; Wed, 21 Oct 2015 04:50:18 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id XgqH1r00G3Ge9ey01gqJTu; Wed, 21 Oct 2015 04:50:18 +0000
To: Roman Shpount <roman@telurix.com>
References: <7594FB04B1934943A5C02806D1A2204B37B7AC27@ESESSMB209.ericsson.se> <56266954.3080206@alum.mit.edu> <CAD5OKxtxHwjdaDnmK9LORM9M0YqQQb+-h66dV8C8Lgy8a6WYiA@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56271989.5010509@alum.mit.edu>
Date: Wed, 21 Oct 2015 00:50:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxtxHwjdaDnmK9LORM9M0YqQQb+-h66dV8C8Lgy8a6WYiA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445403018; bh=f5gYbo7YZXjBOex1qHQ8KJUP/XxktxiM1wApUQ7MLd4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hV6irwAQVd80IesCfyWSunnxYLTfq+Z2GM3EjlOFpsKTcUy1fikqvlBb1sXba3bBU tpWiv4x1f1diJU4kH23hQnIu9rh31oycjnPWyS6mmSnYZ/5ZsPpXcmSetp2HSnXa3p mWlyHgeJnpoaUU8xO52kIv3pesHufieVCx4p9+jy+EP21lx/E9GCJOqCCTfnYa4AeO twAFj4UQDLto5h+aXbuBGiJ4vhKnOZ/HgYTYjrwCC2wngPrqSvNjGUBJQ39M8yQGuU hFoz+OEsWkhhOqD2HwJe95l+jHTf4pa9KclW+JT7T62MypmJEJZG1bENGO8Qpr/uW2 yfjPCfg5u+4uQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/vJaAEQahSbkstrhbn2S60YUoeGg>
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: Wed, 21 Oct 2015 04:50:20 -0000

On 10/20/15 2:01 PM, Roman Shpount wrote:
> On Tue, Oct 20, 2015 at 12:18 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto: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.

The thing is - the sender *will* get the RTCP, at port+1, even if it 
doesn't have port+1 allocated!

It would be better if RTCP wasn't sent in this case. But the other end 
simply didn't understand the a=rtcp, so it will assume default behavior.

	Thanks,
	Paul

> 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