Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE

From: Roman Shpount <[email-masked]>
Date: Wed, 16 Nov 2016 22:05:53 -0500

Adding ICE group to this message.

The approach always was that tcp candidates can potentially go only as far
as SBC and then be terminated by UDP transport. Because of this everything
transmitted over tcp candidate was still considered to be transmitted over
the unreliable out-of-order transport. It is also assumed that candidates
can switch from UDP to TCP based candidate during nomination. This is why,
for instance, we run DTLS with RFC4571 framing over tcp candidates, not
TLS. Because of this I always thought that ICE is UDP first with additional
TCP transports for situation when UDP will not work. So, as a result, I
think ICE-bis should specify that UDP MUST be supported and default
candidate MUST be UDP. ICE SDP can reflect this, but I think this is the
underlying protocol requirement.

I also wanted to add that BFCP needs to examine how ICE support is
implemented by this protocol. I think it is not covered in the current
drafts. I also think I do not think it is possible for TCP/BFCP to run over
ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based
on current DTLS work.

Regards,
_____________
Roman Shpount

On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg <
[email-masked]> wrote:

> I have no problem with Roman’s must-support-UDP suggestion. I guess the
> question is whether the BFCP folks could accept that. Cullen did say that
> TCP-based BFCP deployments have been around for a decade. But, do they
> support ICE?
>
>
>
> If we decide to move forward with such approach, we need to ask ourselves
> whether must-support-UDP should be an ICE requirement (in which case the
> suggestion should be brought to the ICE WG) or whether it should only be an
> ICE-using-SIP-SDP requirement.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Roman
> Shpount
> *Sent:* 17 November 2016 00:52
> *To:* [email-masked]
> *Subject:* [MMUSIC] m= line protocol in case of ICE
>
>
>
> Hi All,
>
>
>
> I just wanted to return to the m= line protocol issue that Christer raised
> during the last MMUSIC session.
>
>
>
> All the ICE implementations I've seen are primarily UDP based with support
> for tcp host candidates which are primarily used to connect to end points
> on public IP. If all ICE implementations are continue to be primarily UDP
> based, then the simplest solution would be to require UDP support when any
> given protocol is implemented over ICE. DTLS and RTP are already primarily
> UDP based so this is a non-requirement. Even more, all protocols that are
> implemented on top of ICE must assume that underling transports (including
> tcp candidates) are unreliable, since candidate pair can change at any time
> between reliable and unreliable transports, so this makes them different
> from protocols implemented on plain TCP or TLS.
>
>
>
> So the first question I wanted to ask is anybody interested in TCP only
> ICE implementation where the protocol running on top of such implementation
> relies on the reliable delivery of underlying messages? By this I mean,
> does anybody wants implement TCP based ICE, with simultaneous open,
> reflexive and relay candidates in such a way that ICE implementation will
> run from behind NAT without ever needing a UDP candidate?
>
>
>
> I understand that BFCP was used for a long time, but I do not think
> TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP,
> UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.
>
>
>
> I think both rfc4582bis and rfc4583bis need a careful review and
> additional sections that describe ICE considerations. I think the most
> obvious thing would be to specify that ICE can only be supported by
> UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case
> RFC4571 is used when tcp candidates are used. Furthermore, when tcp
> candidate is selected with UDP/BFCP transport, it is not the same thing as
> using TCP/BFCP and will need a different transport tag (something like
> TCP/UDP/BFCP). Alternatively we can require that only secure versions of
> BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and
> TCP/DTLS/BFCP.
>
>
>
> To conclude, I would argue that the simplest solution would be that for
> all protocols implemented on top of ICE, UDP MUST be supported and default
> candidates MUST be UDP based. This avoids building uncomfortable artificial
> constructs to avoid ICE mismatch and requires minimal changes to existing
> specifications.
>
>
>
> Regards,
>
> _____________
> Roman Shpount
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Nov 2016 10:01:56 +0000

Hi,

I assume future QUIC candidates will also be considered UDP.

Regards,

Christer

Sent from my iPhone

On 17 Nov 2016, at 12.06, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

The approach always was that tcp candidates can potentially go only as far as SBC and then be terminated by UDP transport. Because of this everything transmitted over tcp candidate was still considered to be transmitted over the unreliable out-of-order transport. It is also assumed that candidates can switch from UDP to TCP based candidate during nomination. This is why, for instance, we run DTLS with RFC4571 framing over tcp candidates, not TLS. Because of this I always thought that ICE is UDP first with additional TCP transports for situation when UDP will not work. So, as a result, I think ICE-bis should specify that UDP MUST be supported and default candidate MUST be UDP. ICE SDP can reflect this, but I think this is the underlying protocol requirement.

I also wanted to add that BFCP needs to examine how ICE support is implemented by this protocol. I think it is not covered in the current drafts. I also think I do not think it is possible for TCP/BFCP to run over ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based on current DTLS work.

Regards,
_____________
Roman Shpount

On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
I have no problem with Roman’s must-support-UDP suggestion. I guess the question is whether the BFCP folks could accept that. Cullen did say that TCP-based BFCP deployments have been around for a decade. But, do they support ICE?

If we decide to move forward with such approach, we need to ask ourselves whether must-support-UDP should be an ICE requirement (in which case the suggestion should be brought to the ICE WG) or whether it should only be an ICE-using-SIP-SDP requirement.

Regards,

Christer

From: mmusic [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Roman Shpount
Sent: 17 November 2016 00:52
To: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] m= line protocol in case of ICE

Hi All,

I just wanted to return to the m= line protocol issue that Christer raised during the last MMUSIC session.

All the ICE implementations I've seen are primarily UDP based with support for tcp host candidates which are primarily used to connect to end points on public IP. If all ICE implementations are continue to be primarily UDP based, then the simplest solution would be to require UDP support when any given protocol is implemented over ICE. DTLS and RTP are already primarily UDP based so this is a non-requirement. Even more, all protocols that are implemented on top of ICE must assume that underling transports (including tcp candidates) are unreliable, since candidate pair can change at any time between reliable and unreliable transports, so this makes them different from protocols implemented on plain TCP or TLS.

So the first question I wanted to ask is anybody interested in TCP only ICE implementation where the protocol running on top of such implementation relies on the reliable delivery of underlying messages? By this I mean, does anybody wants implement TCP based ICE, with simultaneous open, reflexive and relay candidates in such a way that ICE implementation will run from behind NAT without ever needing a UDP candidate?

I understand that BFCP was used for a long time, but I do not think TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.

I think both rfc4582bis and rfc4583bis need a careful review and additional sections that describe ICE considerations. I think the most obvious thing would be to specify that ICE can only be supported by UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when tcp candidates are used. Furthermore, when tcp candidate is selected with UDP/BFCP transport, it is not the same thing as using TCP/BFCP and will need a different transport tag (something like TCP/UDP/BFCP). Alternatively we can require that only secure versions of BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.

To conclude, I would argue that the simplest solution would be that for all protocols implemented on top of ICE, UDP MUST be supported and default candidates MUST be UDP based. This avoids building uncomfortable artificial constructs to avoid ICE mismatch and requires minimal changes to existing specifications.

Regards,
_____________
Roman Shpount

---

From: Alan Ford <[email-masked]>
Date: Fri, 18 Nov 2016 01:14:10 +0000

Adding bfcpbis.

You raise a good point Roman - there’s no definition of how to actually use ICE with BFCP at the protocol level - this only came up in some very late reviews of 4582bis. The initial suggestion was to use the same text as in draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that, given BFCP does not have a MTI protocol, if the offerer supported both they would include their preferred option, but if the receiver supported the other variant, there’s no way to immediately negotiate that without a re-INVITE.

Christer’s suggestion to relax the requirement that the m-line protocol in the answer matches one of the ICE candidates would support the case where the offerer supports both but prefers UDP, but the answerer only supports TCP. Although no implementations currently do ICE here, this relaxation would leave the door open to gaining this negotiation flexibility in bfcpbis implementations. There seems no reason to have this requirement applied to the answer in the first place.

I don’t understand the comment about SBCs; today, tcp candidates are used for media and data channels end-to-end in WebRTC, to name but one implementation.

Regards,
Alan

> On 17 Nov 2016, at 03:05, Roman Shpount <[email-masked]> wrote:
> 
> On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>   <>
> From: mmusic [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Roman Shpount
> To: [email-masked] <mailto:[email-masked]>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Nov 2016 21:13:35 -0500

Hi All,

There are three comments I wanted to make regarding general nature of all
existing protocols designed to work ICE

1. Protocols running on top of ICE assume that regardless what candidate
pair is used, including tcp candidates, the underlying network transport is
unordered and unreliable. During nomination, including continuous
nomination, candidate pairs can switch, including switching from udp to tcp
or from tcp to udp. This typically means that protocol re-transmit timers
are operational, packets are re-ordered at the protocol level, and
 UDP-friendly packet sizes are used even when packets are sent over tcp
candidates. For instance DTLS and SCTP re-transmit timers, reordering, and
fragmentation support are still running when tcp candidates are used.

2. Protocols do not assume that particular candidate network transport runs
all the way from origination to final destination of the protocol packets.
For instance there are SBC which only handle ICE. These SBC run the ICE
state machine and then transmit the underlying protocol data to the final
destination using public IP. Because of this, it is not unusual for RTP to
run over tcp candidate until SBC and then run over UDP to the final
destination. This is one more reason why re-transmit timers and other
mechanisms used to deal with UDP are still running over tcp candidates.

3. I am not aware of any current protocol running over ICE tcp candidates
which is not using RFC4571 framing. For instance DTLS could have been
implemented using DTLS protocol framing without RFC4571 over tcp
candidates, but this was not the case. This is partially done to simplify
implementation of SBC which terminate ICE and transmit protocol data using
UDP. By using RFC 4571 framing, SBC can packetize/de-packetize data
transmitted over tcp candidates without knowing protocol details.

To conclude, up until this point ICE tcp candidates were not treated as
reliable transport and served simply as another way to transmit UDP packets
through firewalls. Because of this, I would argue that BFCP running over
tcp candidate is not the same as TCP/BFCP, in the same way as DTLS running
over tcp candidate is not TLS.

I would also argue that any protocol running over ICE is, in essence, a UDP
based protocol, using tcp candidates only as a fall back mechanism for
firewall traversal, same way as when data is relayed over TURN TCP, it is
still considered sent over UDP at the protocol level.

If ICE group agrees, I think this should be documented by saying that UDP
is a MUST implement for any protocol using ICE and that default candidate
should be UDP based.

Regards,
_____________
Roman Shpount

On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford <[email-masked]> wrote:

> Adding bfcpbis.
>
> You raise a good point Roman - there’s no definition of how to actually
> use ICE with BFCP at the protocol level - this only came up in some very
> late reviews of 4582bis. The initial suggestion was to use the same text as
> in draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that,
> given BFCP does not have a MTI protocol, if the offerer supported both they
> would include their preferred option, but if the receiver supported the
> other variant, there’s no way to immediately negotiate that without a
> re-INVITE.
>
> Christer’s suggestion to relax the requirement that the m-line protocol *in
> the answer* matches one of the ICE candidates would support the case
> where the offerer supports both but prefers UDP, but the answerer only
> supports TCP. Although no implementations currently do ICE here, this
> relaxation would leave the door open to gaining this negotiation
> flexibility in bfcpbis implementations. There seems no reason to have this
> requirement applied to the answer in the first place.
>
> I don’t understand the comment about SBCs; today, tcp candidates are used
> for media and data channels end-to-end in WebRTC, to name but one
> implementation.
>
> Regards,
> Alan
>
>> All the ICE implementations I've seen are primarily UDP based with
>> support for tcp host candidates which are primarily used to connect to end
>> points on public IP. If all ICE implementations are continue to be
>> primarily UDP based, then the simplest solution would be to require UDP
>> support when any given protocol is implemented over ICE. DTLS and RTP are
>> already primarily UDP based so this is a non-requirement. Even more, all
>> protocols that are implemented on top of ICE must assume that underling
>> transports (including tcp candidates) are unreliable, since candidate pair
>> can change at any time between reliable and unreliable transports, so this
>> makes them different from protocols implemented on plain TCP or TLS.
>>
>>
>>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 20 Nov 2016 18:23:26 -0500

Hi All,

I just wanted to add to my previous email, that according to RFC
6544 protocols running over tcp candidates MUST use  RFC 4571 framing (
https://tools.ietf.org/html/rfc6544#section-10.1). This means that BFCP
running over tcp candidate is not TCP/BFCP and will require a different
transport tag.

Regards,

_____________
Roman Shpount

On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpount <[email-masked]> wrote:

> 2. Protocols do not assume that particular candidate network transport
> runs all the way from origination to final destination of the protocol
> packets. For instance there are SBC which only handle ICE. These SBC run
> the ICE state machine and then transmit the underlying protocol data to the
> final destination using public IP. Because of this, it is not unusual for
> RTP to run over tcp candidate until SBC and then run over UDP to the final
> I would also argue that any protocol running over ICE is, in essence, a
> UDP based protocol, using tcp candidates only as a fall back mechanism for
>> The approach always was that tcp candidates can potentially go only as
>> far as SBC and then be terminated by UDP transport. Because of this
>> everything transmitted over tcp candidate was still considered to be
>> transmitted over the unreliable out-of-order transport. It is also assumed
>> that candidates can switch from UDP to TCP based candidate during
>> nomination. This is why, for instance, we run DTLS with RFC4571 framing
>> over tcp candidates, not TLS. Because of this I always thought that ICE is
>> UDP first with additional TCP transports for situation when UDP will not
>> work. So, as a result, I think ICE-bis should specify that UDP MUST be
>> supported and default candidate MUST be UDP. ICE SDP can reflect this, but
>> I think this is the underlying protocol requirement.
>>
>>> If we decide to move forward with such approach, we need to ask
>>> ourselves whether must-support-UDP should be an ICE requirement (in which
>>> case the suggestion should be brought to the ICE WG) or whether it should
>>> only be an ICE-using-SIP-SDP requirement.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 21 Nov 2016 00:27:46 +0100

2016-11-21 0:23 GMT+01:00 Roman Shpount <[email-masked]>:
> I just wanted to add to my previous email, that according to RFC 6544
> protocols running over tcp candidates MUST use  RFC 4571 framing
> (https://tools.ietf.org/html/rfc6544#section-10.1). This means that BFCP

IMHO the exact transport is just "ICE". ICE itself is a "virtual
transport" that can use many "real transports" (UDP, TCP+RFC4571,
etc).

So ICE/BFCP would be my way to go.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Nov 2016 09:25:46 +0000

Hi Roman,

Good catch.

That basically means that bfcpbis would have to document the usage of framing for BFCP-TCP – assuming they want BFCP-TCP to work with ICE.

I assume the same applies to MSRP (when not using an MSRP relay).

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 21 November 2016 01:23
To: Alan Ford <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] m= line protocol in case of ICE

Hi All,

I just wanted to add to my previous email, that according to RFC 6544 protocols running over tcp candidates MUST use  RFC 4571 framing (https://tools.ietf.org/html/rfc6544#section-10.1). This means that BFCP running over tcp candidate is not TCP/BFCP and will require a different transport tag.

Regards,

_____________
Roman Shpount

On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

There are three comments I wanted to make regarding general nature of all existing protocols designed to work ICE

1. Protocols running on top of ICE assume that regardless what candidate pair is used, including tcp candidates, the underlying network transport is unordered and unreliable. During nomination, including continuous nomination, candidate pairs can switch, including switching from udp to tcp or from tcp to udp. This typically means that protocol re-transmit timers are operational, packets are re-ordered at the protocol level, and  UDP-friendly packet sizes are used even when packets are sent over tcp candidates. For instance DTLS and SCTP re-transmit timers, reordering, and fragmentation support are still running when tcp candidates are used.

2. Protocols do not assume that particular candidate network transport runs all the way from origination to final destination of the protocol packets. For instance there are SBC which only handle ICE. These SBC run the ICE state machine and then transmit the underlying protocol data to the final destination using public IP. Because of this, it is not unusual for RTP to run over tcp candidate until SBC and then run over UDP to the final destination. This is one more reason why re-transmit timers and other mechanisms used to deal with UDP are still running over tcp candidates.

3. I am not aware of any current protocol running over ICE tcp candidates which is not using RFC4571 framing. For instance DTLS could have been implemented using DTLS protocol framing without RFC4571 over tcp candidates, but this was not the case. This is partially done to simplify implementation of SBC which terminate ICE and transmit protocol data using UDP. By using RFC 4571 framing, SBC can packetize/de-packetize data transmitted over tcp candidates without knowing protocol details.

To conclude, up until this point ICE tcp candidates were not treated as reliable transport and served simply as another way to transmit UDP packets through firewalls. Because of this, I would argue that BFCP running over tcp candidate is not the same as TCP/BFCP, in the same way as DTLS running over tcp candidate is not TLS.

I would also argue that any protocol running over ICE is, in essence, a UDP based protocol, using tcp candidates only as a fall back mechanism for firewall traversal, same way as when data is relayed over TURN TCP, it is still considered sent over UDP at the protocol level.

If ICE group agrees, I think this should be documented by saying that UDP is a MUST implement for any protocol using ICE and that default candidate should be UDP based.

Regards,
_____________
Roman Shpount

On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford <[email-masked]<mailto:[email-masked]>> wrote:
Adding bfcpbis.

Regards,
Alan

On 17 Nov 2016, at 03:05, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
_____________
Roman Shpount

Regards,

Christer

Hi All,

Regards,
_____________
Roman Shpount

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Nov 2016 09:27:14 +0000

Hi,

>> (https://tools.ietf.org/html/rfc6544#section-10.1). This means that 
>> BFCP running over tcp candidate is not TCP/BFCP and will require a 
>> different transport tag.
>
> IMHO the exact transport is just "ICE". ICE itself is a "virtual transport" that can use 
> many "real transports" (UDP, TCP+RFC4571, etc).
>

This has been discussed before: the procedures have to be backward compatible with non-ICE endpoints.

If anyone wants to define new "ICE transports", that's fine, but it should be done as a separate task.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 21 Nov 2016 16:38:42 +0100

> This has been discussed before: the procedures have to be backward compatible with non-ICE endpoints.

I'd rather deprecate non-ICE endpoints.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 22 Nov 2016 15:43:30 -0500

Christer,

I think this is another way around -- BFCP would have to use RFC 4571
framing when using tcp candidates.

There is deployed equipment (SBC) that rely on the fact that RFC 4571
framing is used by tcp candidates in ICE. I am not sure there are ICE
implementations of BFCP. I think new implementation should be updated to
comply with existing standards, not another way around.

Can someone provide some insight regarding BFCP with UDP and ICE
implementation? Are there implementations of either? I see the RFC for
TCP/BFCP, but it looks like UDP/BFCP and BFCP with ICE only exist in drafts.

My proposal either to limit ICE support to UDP/DTLS/BFCP and TCP/DTLS/BFCP,
or define new transport tag DBFCP (datagram BFCP), and define ICE support
for UDP/DBFCP and TCP/DBFCP, where UDP version of BFCP is used over udp and
tcp ICE candidates, with  RFC 4571 framing used in case of tcp candidates.

If this is done, we can make UDP/DTLS/BFCP MUST implement if ICE is
supported for encrypted (and UDP/DBFCP for non-encrypted), make default
candidate UDP, and all the ICE problems disappear.

Not sure about the current state of MSRP and ICE, but I do not think there
are any implementations of it. Probably the best way to implement it now
would be over datachannel or quick.

Regards,

_____________
Roman Shpount

On Mon, Nov 21, 2016 at 4:25 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Roman,
>
>
>
> Good catch.
>
>
>
> That basically means that bfcpbis would have to document the usage of
> framing for BFCP-TCP – assuming they want BFCP-TCP to work with ICE.
>
>
>
> *From:* Roman Shpount [mailto:[email-masked]]
> *Sent:* 21 November 2016 01:23
> *To:* Alan Ford <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [MMUSIC] m= line protocol in case of ICE
>
>
>
> Hi All,
>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 22 Nov 2016 23:15:13 +0100

2016-11-22 21:43 GMT+01:00 Roman Shpount <[email-masked]>:
> implementation? Are there implementations of either?

I bet there is no one implementation. In fact, I implemented "JSFCP"
(JSON version of BFCP) over WebSocket.

> are any implementations of it.

Of course not. And the fact that there are MSRP relays (by spec) makes
it even more difficult to move to more efficient solutions such as
"anything" over UDP/ICE/DTLS/SCTP or similar.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Nov 2016 05:16:05 +0000

Hi,

>"anything" over UDP/ICE/DTLS/SCTP or similar.

The deployments I am aware of don¹t use relays. Anyway, *IF* someone wants
to define ICE support for MSRP, he/she can ³write a draft² :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 23 Nov 2016 10:58:15 +0100

2016-11-23 6:16 GMT+01:00 Christer Holmberg <[email-masked]>:
> The deployments I am aware of don¹t use relays.

Yep. I'm pretty sure those deployments don't use Outbound/GRUU (RFC
5626/5627) nor MSRP relay servers (RFC 4976). Probably they all use
their own private SIP extensions to handle TCP based connections and
probably they implement middle-boxes that prevent SIP body encryption
(draft-ietf-simple-msrp-sessmatch) because those magic middle-boxes
need to mangle the SDP for things to work in walled gardens.

However, the IETF is supposed to do stuff for the real Internet, and
there are still good guys building real stuff on top of real Internet
standards:

http://msrprelay.org/

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 29 Nov 2016 17:48:18 +0000

It seems to me that the most straightforward approach would be to mandate support for BFCP over UDP when using ICE, use UDP as the default candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that would be even better.
Thoughts?

Charles

From: bfcpbis <[email-masked]> on behalf of Alan Ford <[email-masked]>
Date: Thursday, November 17, 2016 at 5:14 PM
To: Roman Shpount <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

Adding bfcpbis.

Regards,
Alan

Regards,
_____________
Roman Shpount

Regards,

Christer

Hi All,

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Nov 2016 13:38:29 -0500

On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) <[email-masked]
> wrote:

> It seems to me that the most straightforward approach would be to mandate
> support for BFCP over UDP when using ICE, use UDP as the default candidate,
> and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the
> use of DTLS, that would be even better.
>
> Thoughts?
>
>
>

I agree.

The only issue that I still have, if DTLS is not used, what protocol is
used when ICE tcp candidate is selected for transport. Is this TCP/BFCP
(which goes against RFC6544)  or is it UDP/BFCP with RFC4571 framing? If it
is UDP/BFCP with RFC4571 framing, what transport tag should be used in the
re-INVITE which is sent after ICE nomination with only selected candidate?
Should it be TCP/UDP/BFCP or something similar?

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Nov 2016 19:31:10 +0000

I also agree.

More generally, I suggest that ANY protocol supporting ICE should always have a MTI transport, which in the case of ICE-SDP also MUST be used as default candidate. That way we would avoid offers with m- line transport values not supported by the answerer.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 29 November 2016 20:38
To: Charles Eckel (eckelcu) <[email-masked]>
Cc: Alan Ford <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Christer Holmberg <[email-masked]>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
It seems to me that the most straightforward approach would be to mandate support for BFCP over UDP when using ICE, use UDP as the default candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that would be even better.
Thoughts?

I agree.

The only issue that I still have, if DTLS is not used, what protocol is used when ICE tcp candidate is selected for transport. Is this TCP/BFCP (which goes against RFC6544)  or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 framing, what transport tag should be used in the re-INVITE which is sent after ICE nomination with only selected candidate? Should it be TCP/UDP/BFCP or something similar?

Regards,
_____________
Roman Shpount