Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 04 November 2016 18:27 UTC

Return-Path: <christer.holmberg@ericsson.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 6A779129627 for <bfcpbis@ietfa.amsl.com>; Fri, 4 Nov 2016 11:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0OdbnZVxmBpM for <bfcpbis@ietfa.amsl.com>; Fri, 4 Nov 2016 11:27:11 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 6DCD7129628 for <bfcpbis@ietf.org>; Fri, 4 Nov 2016 11:26:55 -0700 (PDT)
X-AuditID: c1b4fb2d-5b107980000009f7-77-581cd2ed8009
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id CD.E3.02551.DE2DC185; Fri, 4 Nov 2016 19:26:53 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Fri, 4 Nov 2016 19:26:51 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.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+h6CjBJQAgATKB4CABHhQAIAAQMmAgANalwD//9npAIAANloAgAkodQCAAFwnoIAPp48AgAA/ZJA=
Date: Fri, 4 Nov 2016 18:26:50 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE1E415@ESESSMB209.ericsson.se>
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> <F27839ED-3E3A-4613-8C13-41F95177DE3F@cisco.com>
In-Reply-To: <F27839ED-3E3A-4613-8C13-41F95177DE3F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE1E415ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7lu7bSzIRBuf3GlisPLeC2eLfuqNM FptmfWGzmHFhKrPF+c9A7pUjv9gc2Dym/N7I6rFz1l12jyVLfjJ5rF79kNnj1pSCANYoLpuU 1JzMstQifbsEroyDLyexF/w4z1Rx9v1+lgbGKceZuhg5OCQETCTavkd1MXJyCAmsY5S4tZu7 i5ELyF7MKNEw6SsjSA2bgIVE9z9tkLgISE3vpEYmkAZmAR+Jc7ePsIDYwgLuEo9vvAObKSLg ITGvqxwkLCJQJvG+axc7iM0ioCKxd/UJsFZeAV+JVZdPMULsOs4icfj7drAiTgFbiet9KxhB bEYBMYnvp9ZA7RKXuPVkPpgtISAgsWTPeWYIW1Ti5eN/rBC2ksSi25+h6vMlNk5fxg6xTFDi 5MwnLBMYRWYhGTULSdksJGWzgF5gFtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYRYtT i4tz042M9VKLMpOLi/Pz9PJSSzYxAmPz4JbfujsYV792PMQowMGoxMNbsEgmQog1say4MvcQ owQHs5IIb9gFoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTByc Ug2M/EeCUpwYOJUkhVJX7XAWY9LnyXm311R6z1/lz7N7v00q21Ux03CdSuNM5SmH7tYsZ14b vNrjxo0YZteH1Ty74rg2LZVTWTPL9kfwlunMW4/wW+UXxLesaPaf08cU55lZr9Dwl1Fhut6R X9atF4t4m+eyctzi1gjOmBP0e2rBPvUNYiZFd1qUWIozEg21mIuKEwHAQhWhyQIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/NP_LAEts2kaj7H0BgmSeGFy_7Cs>
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 18:27:15 -0000

Hi,

Note that I intend to discuss the m-line-proto-must-match-default-candidiate-in-asnwer issue during the MMUSIC session in Seoul, for those who are interested.

Regards,

Christer

From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: 04 November 2016 17:38
To: Christer Holmberg <christer.holmberg@ericsson.com>om>; Alan Ford <alan.ford@gmail.com>om>; Tom Kristensen (tomkrist) <tomkrist@cisco.com>om>; 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

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<mailto:christer.holmberg@ericsson.com>>; Alan Ford <alan.ford@gmail.com<mailto:alan.ford@gmail.com>>; Tom Kristensen (tomkrist) <tomkrist@cisco.com<mailto:tomkrist@cisco.com>>; Tom Kristensen <tomkri@ifi.uio.no<mailto:tomkri@ifi.uio.no>>
Cc: bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>; Roman Shpount <roman@telurix.com<mailto: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