Re: [MMUSIC] ICE and RTCP host components

Roman Shpount <> Thu, 22 October 2015 05:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3AD451B2DD9 for <>; Wed, 21 Oct 2015 22:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p0vvLCVIaHhR for <>; Wed, 21 Oct 2015 22:22:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8E581B2D5E for <>; Wed, 21 Oct 2015 22:22:36 -0700 (PDT)
Received: by iofz202 with SMTP id z202so80633326iof.2 for <>; Wed, 21 Oct 2015 22:22:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K4VInw3WQjjP7UrxJh9MOM+4JkkZDevvv4D8MgBO63k=; b=enufqn7gmW6vm/q63QKh2THu0Dn1GLZY4GVs3/xoVoMGwWqYAjtKR91QfEngoLdg1I a9m2QrNPS4F0iDYaDy5e9LneSW4W7Vfx7DtFYNxv3dM21pO5Vj+hR7Eh/6DAnJxc5YXA vgxMMPCPwIzBeRNgWLKWTS1wewZmy0bvvMM7DOZJj+NLjrLIXX6b4JYvtW5I2vRH7WNf liVgU4s+i0fD8jF6NVkLCrbTbiqrFghFUqINNYhgfmwEsCtDfJRGOdkZ5nWAkY/rkzGR A70KQqRoAy/FzwKzJFUsQte4Zpf6NMTLVtifvHnyP3P0kiodVt3bWTVDnYnrtb1k8kuk 85zQ==
X-Gm-Message-State: ALoCoQmCP+sOf/lLgVrO89t/J4wGxaqnTNnUIHqWPzRf35D9moS6jWOfuxkqVFrcfzKcVgkQQPhT
X-Received: by with SMTP id 189mr12935281iof.161.1445491356039; Wed, 21 Oct 2015 22:22:36 -0700 (PDT)
Received: from ( []) by with ESMTPSA id s7sm9475411igh.3.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 22:22:34 -0700 (PDT)
Received: by igdg1 with SMTP id g1so102067831igd.1 for <>; Wed, 21 Oct 2015 22:22:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id h1mr14713386igh.24.1445491354521; Wed, 21 Oct 2015 22:22:34 -0700 (PDT)
Received: by with HTTP; Wed, 21 Oct 2015 22:22:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 22 Oct 2015 01:22:34 -0400
Message-ID: <>
From: Roman Shpount <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary="001a11c3dab8b657c80522aaae86"
Archived-At: <>
Cc: "" <>
Subject: Re: [MMUSIC] ICE and RTCP host components
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Oct 2015 05:22:38 -0000

On Wed, Oct 21, 2015 at 12:50 AM, Paul Kyzivat <>

> On 10/20/15 2:01 PM, Roman Shpount wrote:
>> On Tue, Oct 20, 2015 at 12:18 PM, Paul Kyzivat <
>> <>> 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.
It is actually worse, since RTCP port not being rtp+1 is normally due to
NAT. This means RTCP traffic will got to the NAT router and then NAT router
will forward this traffic to some random end-point. There is no way to stop
RTCP in such case either, since there is no standard way to negotiate no

Basically, end points must implement ICE and be deployed with TURN servers
to play well with other end points. If you implement ICE with STUN servers
only, one would need to make sure to set up connections only to end points
they control, which implement ICE or at least SDP rtcp attribute.
Everything else breaks in interesting and unpleasant ways. Building
anything new now without ICE, and consent to send traffic which is part of
ICE, would be highly dangerous and can be used for DOS attacks. So, I think
it might be safer to remove interop with legacy.from anything that supports
ICE, and require that remote party implements at least ice-lite, or no
media flow will be established.
Roman Shpount