Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Fri, 04 November 2016 15:38 UTC
Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E643129592 for <bfcpbis@ietfa.amsl.com>; Fri, 4 Nov 2016 08:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level:
X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 0vDpvIsLHYaO for <bfcpbis@ietfa.amsl.com>; Fri, 4 Nov 2016 08:38:03 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61E7129521 for <bfcpbis@ietf.org>; Fri, 4 Nov 2016 08:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32250; q=dns/txt; s=iport; t=1478273882; x=1479483482; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n0IbNSioUPzcwCX2m/yK6td17MvT7OWJdRGVEqr2UQ8=; b=iNuya8cEfb1TB7WAryg7OMxP/Vx+caa4pJvfuvW/00tEHqFbSq9hJqQB +euZ1bNxtJyfVk8RQQe5YNI+sRH534XOu5j25+FTUtOMcpesdEYro2k5f d1aYLWEG4hpYBrTy+AGa9giQ8bOJlYZrAbzVaSvdIt2vpsPouhOL7Zrru E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BuAQBCqhxY/4UNJK1dGgEBAQECAQEBAQgBAQEBgnM7AQEBAQEfWHwHjTGXAIdgjGaCCIYjAhqBfD8UAQIBAQEBAQEBYiiEYQEBAQQjVhACAQgRBAEBIQcDAgICHxEUCQgCBAENBRsEiB8DF69ViHgNg3sBAQEBAQEBAQEBAQEBAQEBAQEBAQEciDwIglCCR4I2gk4tgi8FiS+LFYUqNQGJPoNLgzaBboRviS2HKYFYhCCEAwEeNyRIgygcgV1yhTgHgSmBDAEBAQ
X-IronPort-AV: E=Sophos;i="5.31,443,1473120000"; d="scan'208,217";a="344332828"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 15:38:01 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uA4Fc1Cw007679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 15:38:01 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 10:38:01 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 4 Nov 2016 10:38:00 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Alan Ford <alan.ford@gmail.com>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>, Tom Kristensen <tomkri@ifi.uio.no>
Thread-Topic: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
Thread-Index: AQHSGa3x+izuQLaNQkCcn/MwWSz+h6Cjee0AgASV34CABKx3AIAADJmAgANakACAAA4hAIAAAiIAgAl+NYCAABlDAIAPQs4A
Date: Fri, 04 Nov 2016 15:38:00 +0000
Message-ID: <F27839ED-3E3A-4613-8C13-41F95177DE3F@cisco.com>
References: <9BE360E6-8462-49BC-9491-7143D476EEAD@cisco.com> <28B9D43D-FF01-4294-BCD6-93E72C0C07E1@gmail.com> <D426777A.11238%christer.holmberg@ericsson.com> <42A8BAE9-A6C2-4112-97FC-2DAE01F9AB0D@gmail.com> <D42A6D07.1138D%christer.holmberg@ericsson.com> <D42D3DE9.11645%christer.holmberg@ericsson.com> <EC53FDEE-0A52-488D-AF36-EDACE0A69232@gmail.com> <D42D4B50.1165E%christer.holmberg@ericsson.com> <35E11A60-C03F-43CF-9958-4E93EC499FF6@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BDCE32C@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BDCE32C@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.182.35]
Content-Type: multipart/alternative; boundary="_000_F27839ED3E3A46138C1341F95177DE3Fciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/ZzsClAkBEZqcgDWM-lio_HHkJIA>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Roman Shpount <roman@telurix.com>
Subject: Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2016 15:38:05 -0000
Thanks Christer. We should be able to do the same for BFCPBIS and keep the approach consistent between the two drafts. Cheers, Charles On 10/25/16, 8:35 AM, "Christer Holmberg" <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote: Hi, Please see the updated text proposal on the MMUSIC. For example, the second paragraph has been removed, because it is generic ICE and should be added to draft-ietf-mmusic-ice-sip-sdp. Regards, Christer From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: 25 October 2016 15:05 To: Christer Holmberg <christer.holmberg@ericsson.com>; Alan Ford <alan.ford@gmail.com>; Tom Kristensen (tomkrist) <tomkrist@cisco.com>; Tom Kristensen <tomkri@ifi.uio.no> Cc: bfcpbis@ietf.org; Roman Shpount <roman@telurix.com> Subject: Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value This issue was discussed in more detail on the mmusic list. Here is the solution Christer applied to draft-ietf-mmusic-sctp-sdp. "When an SDP offer or answer is sent, the rules in [I-D.ietf-mmusic-ice-sip-sdp] apply regarding when the proto value must match the transport protocol associated with the default candidate. If an endpoint switches between TCP-based and UDP-based candidates during a session the endpoint is not required to send an SDP offer in order to modify that proto value of the associated m- line.” This seems like a good approach. I suggest we do the same for draft-ietf-bfcpbis-rfc4583bis by adding this text to section 10. Cheers, Charles On 10/19/16, 3:06 PM, "Christer Holmberg" <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote: Hi, I guess one solution would be to allow the answerer to use a m- line proto value that does NOT match the default candidate (or, doesn¹t match ANY candidate). That would certainly work in this scenario - different from the SCTP text, but would permit this behaviour, whilst still providing clear guidance. We would update the SCTP text too. However, I fear that would go against the ICE spec; specifically, 5245 says: The transport addresses that will be the default destination for media when communicating with non-ICE peers MUST also be present as candidates in one or more a=candidate lines. So we¹d no longer be adhering to that in the answer. The text is certainly valid for the offer, but when the answer is sent it is known whether the peers support ICE or not. In any case, I don¹t think there should be different rules for BFCF, SCTP etc. This should be defined in draft-ietf-mmusic-ice-sip-sdp as a generic rule. I was thinking a little more about this: maybe indicating a transport in the m- line that you don’t support isn’t a very good idea - even if it won’t be used with ICE. Maybe it would be better to say that the m- line shall contain a transport that the peer is “most likely” to support. In case of BFCP, I guess neither TCP or UDP is mandatory to support, but in other cases there is often a mandatory transport. That still implies they need to support the transport in question, so it’s not dissimilar to the SCTP text about default candidate. The idea was that, if the answerer doesn’t support the transport in the m- line of the offer, it would have to reject the m- line (as you pointed out earlier). Question really is - and this is probably something more for icebis than here - would it be legitimate to relax that requirement in the text I quoted earlier for the answerer? (The way it is written in 5245 suggests it applies to both offerer and answerer). I don’t see it being a problem for endpoints, but I’d be worried some proxies may expect behaviour here which isn’t true. I DID send an e-mail to the MMUSIC list (I think it is more related to SIP/SDP-usage of ICE than ICE in general) about this a few days ago, but nobody has replied. Feel free to jump on the discussion :) Obviously, if you e.g., include TCP in the m- line of the answer (because the offer contained TCP), but you don’t actually support TCP, the m- line port value would only be a “dummy value”. Regards, Christer
- [bfcpbis] BFCPbis: UDP- and TCP candidates and pr… Christer Holmberg
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Charles Eckel (eckelcu)
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Alan Ford
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Christer Holmberg
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Alan Ford
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Christer Holmberg
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Christer Holmberg
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Alan Ford
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Christer Holmberg
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Charles Eckel (eckelcu)
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Christer Holmberg
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Charles Eckel (eckelcu)
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Christer Holmberg
- Re: [bfcpbis] BFCPbis: UDP- and TCP candidates an… Charles Eckel (eckelcu)