Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

[Randell Jesup <[e-mail]>]

On 10/14/2014 3:33 AM, Harald Alvestrand wrote:
> On 10/13/2014 07:02 PM, Wyss, Felix wrote:
>
>> They would only see it as a peer if it were a full B2B user agent.  As an example, in VoIP the endpoints do not consider an SBC as a peer--yet it sits in the middle and may inspect the media passing through it.
>>
>> With respect to DCEP: If we already define a protocol for establishing the channels in-band, why not make ID selection and conflict resolution an explicit part of it?  That certainly would beat the IMHO rather distasteful DTLS role hack.
> When rethinking this, I've come to the conclusion that my original
> conclusion (that there couldn't possibly be a point in preserving
> channel numbers across a relay) was probably wrong. Please consider that
> withdrawn.
>
> I now see a tradeoff between allowing such non-mapping boxes (operating
> below the SCTP layer but above the DTLS layer in our model) and avoiding
> additional complexity (either extending DCEP with glare resolution -
> something it was designed to avoid needing - or requiring such boxes to
> not use actpass).

I'll note that not only does it have to sit between the SCTP and DTLS 
layers, but also it has to be the offerer to both sides as well.  While 
certainly there are some use-cases for that, it's by no means the common 
case.  WebRTC applications designed to work with such a midpoint may 
need to fall back on "external" negotiation, perhaps running a short 
sequence at opening time to decide who will get even and odd (assuming 
that both sides actually open channels dynamically).

It means you may not be able to drop such a middlebox (and have it 
initiate offers to both sides) without a cooperative application (or one 
known to have a compatible usage patter) - but likely you need some 
level of known compatibility anyways, or more likely the entity 
deploying the middlebox also deploys or chooses the application - 
especially as we've explicitly said that signaling protocols and 
transmission (i.e. sending the offer, etc) is explicitly not defined by 
the WG, so the middlebox, in order to generate the offers to both sides 
*must* be in bed somehow with the applications - at least to where they 
all agree on signaling.

> I agree that the DTLS hack is ugly. But glare resolution is ugly too.

Quite so.  We had glare resolution in earlier versions. It sucked and 
caused lots of problems, especially with 0-rtt opens.

While DTLS role isn't wonderful, neither was anything else proposed.  
Offerer/answerer status has the same problem.  An SDP parameter would 
allow a middlebox to specify to the endpoints compatible (complementary) 
values; however from a DataChannels perspective, this is almost the same 
as external negotiation if the middlebox and applications are 'matched'.

-- 
Randell Jesup -- rjesup a t mozilla d o t com