[MMUSIC] ICEbis clarification regarding component id

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Thu, 10 April 2014 07:51 UTC

Return-Path: <palmarti@cisco.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 DC2241A0133 for <mmusic@ietfa.amsl.com>; Thu, 10 Apr 2014 00:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Level:
X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 gWG5sWp6iZeo for <mmusic@ietfa.amsl.com>; Thu, 10 Apr 2014 00:51:08 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3621A0127 for <mmusic@ietf.org>; Thu, 10 Apr 2014 00:51:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=890; q=dns/txt; s=iport; t=1397116268; x=1398325868; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=v8thmMWg1xusO1wjkj6WbOktCbG5nX2vbl8O7gALMUA=; b=RY9Zw2bT58NbkP6iH2ppfCRyjKdY/zc3AuB1f+c4oI90yNq2u+qzqOrO 0rkJ3pKIuhiKOEmSsXv+WO3LT1GX44JKxe6JWUd5au5IvnJYoBQ4ApdWz d3G2luC6+Tcg1sXeUE6yPqGnNGEg0+Fjs57VWAhGPsPF+UBsrcdKgRv/R g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjwFACdNRlOtJA2I/2dsb2JhbABZgwaBEsVJFnSCLIELAYEAJwSID5oasjcXkheBFASJI487kkKDMIIr
X-IronPort-AV: E=Sophos;i="4.97,832,1389744000"; d="scan'208";a="34564885"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 10 Apr 2014 07:50:48 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3A7omVx016510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Thu, 10 Apr 2014 07:50:48 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.19]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 02:50:48 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: "mmusic (E-mail)" <mmusic@ietf.org>
Thread-Topic: ICEbis clarification regarding component id
Thread-Index: AQHPVJGVg867j+sye0qbqNJMVGDRXw==
Date: Thu, 10 Apr 2014 07:50:47 +0000
Message-ID: <B05B14EA-F8A9-4757-9BA4-6B23335A1B03@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.154.75]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5CE21E5D55E7CB4CAC9AAD589218B275@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uovhRNqcqNKz26vRLPsT12lL11Q
Subject: [MMUSIC] ICEbis clarification regarding component id
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: <http://www.ietf.org/mail-archive/web/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: Thu, 10 Apr 2014 07:51:13 -0000

Hi,

Nitpicking, but I just got a question from someone I really could not answer.

ICE usage with RTP and RTCP are well described in  RFC5245. However, it does not specify how to choose the component id for non RTP/RTCP protocols. In our implementation we have just chosen 1 and really never given it any more thought for protocols like BFCP. 

Would it be worthwhile having some clarification text in ICEbis? Something like:

If ICE is used to help non RTP/RTCP protocols through a NAT and that protocol only have one component the component id MUST be set to 1, unless ICE usage is described for that particular protocol elsewhere. For protocols containing more than one component, ICE usage should be described in the protocol description or in a separate RFC.

Apologies if I missed some ting in RFC5245 that spells this out.

.-.
Pål-Erik