Re: [MMUSIC] BUNDLE and RTCP

Jonathan Lennox <jonathan@vidyo.com> Mon, 19 October 2015 18:41 UTC

Return-Path: <prvs=27341cad27=jonathan@vidyo.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 C56DF1B2BA1 for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 11:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.896
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVBpQUxkDnZI for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 11:41:22 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0471B2B76 for <mmusic@ietf.org>; Mon, 19 Oct 2015 11:41:20 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9JIYUaa004683; Mon, 19 Oct 2015 14:41:14 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1xenmhw55v-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Oct 2015 14:41:14 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 19 Oct 2015 13:41:12 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [MMUSIC] BUNDLE and RTCP
Thread-Index: AdEJzH14LMfHNeeTQ5m0MrbuciOcLQAASvagABTmWQAABPyt0P//7NmA///YEmCAAV/wAA==
Date: Mon, 19 Oct 2015 18:41:12 +0000
Message-ID: <54A2A7C6-2CF0-4E76-BB75-68099DB3C0EF@vidyo.com>
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>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B6CCC5@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_54A2A7C62CF04E76BB7568099DB3C0EFvidyocom_"
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-19_15:2015-10-15,2015-10-19,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-1510190319
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/nOpqk-xDhYN-iNTh7nYndfStKXA>
Cc: mmusic <mmusic@ietf.org>
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:41:22 -0000

On Oct 19, 2015, at 3:35 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:


1)      Mandate usage of rtcp-mux with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux MUST be used.

2)      Mandate usage of either rtcp-mux OR the default “+1” port with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux or “+1” MUST be used. The selection is based on whether the rtcp-mux attribute was included in the offer/answer or not.
The solutions above would not allow explicit negotiation of an RTCP port when BUNDLE is used, but maybe we could live with that?

Would using ICE also solve the problem?  ICE candidates for component 2 are RTCP candidates. It might mean putting ICE candidates for component 2 in an m-line that doesn’t “naturally” use two candidates, but that might be cleaner than a=rtcp.

The “+1” technique, by contrast, doesn’t work in any scenario where you’re trying to advertise port numbers on the outside of a NAT, because the endpoint has no control over the mapping of its ports through the NAT.