Re: [MMUSIC] ICE and RTCP host components

Jonathan Lennox <> Tue, 20 October 2015 14:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F0B6E1A21BC for <>; Tue, 20 Oct 2015 07:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.896
X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 949GL9L1F19D for <>; Tue, 20 Oct 2015 07:01:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7C691A90CD for <>; Tue, 20 Oct 2015 07:01:10 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id t9KDtgbJ025026; Tue, 20 Oct 2015 10:01:06 -0400
Received: from ([]) by with ESMTP id 1xenmhwkgv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Oct 2015 10:01:06 -0400
Received: from ([fe80::50:56ff:fe85:4f77]) by ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 20 Oct 2015 09:01:05 -0500
From: Jonathan Lennox <>
To: Christer Holmberg <>
Thread-Topic: [MMUSIC] ICE and RTCP host components
Thread-Index: AdELMspQZuqUGadKR+G+TYSjfMsEiQANuDAA
Date: Tue, 20 Oct 2015 14:01:04 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B92DC9887675469FB9000ED8D64492D6vidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-10-20_05:2015-10-20,2015-10-20,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510200230
Archived-At: <>
Cc: mmusic <>
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: Tue, 20 Oct 2015 14:01:33 -0000

On Oct 20, 2015, at 8:28 AM, Christer Holmberg <<>> wrote:


ICEbis and ice-sip-sdp say that, when a separate port is used for RTCP, separate components are allocated for RTP and RTCP.

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?

Section of ICEbis talks about the rtcp-mux, when it is now known whether the answerer will support it, but this is about having two different ports for RTCP.

I think it’s reasonable to say that any endpoint that supports ICE MUST also support a=rtcp.  Thus, the backward compatibility case only needs to worry about the RTP port+1 for the default candidate (the one in the m/c line).

If your default candidate is either your host candidate or your TURN candidate, this is easily achieved (using EVEN-PORT in the latter case).  It’s only server-reflexive candidates where the endpoint has no control over the RTCP port. (This was the motivation for the invention of a=rtcp, as I understand it.)