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

[Harald Alvestrand <[e-mail]>]

On 10/13/2014 07:02 PM, Wyss, Felix wrote:
>>>> It has to be the same on both ends of the SCTP connection.
>>> This means you can't remap the streams. Or am I missing something?
>> [Raju] When middle box is in the bearer path each end will see middle box
>> as its peer.
>> If the DCEP is used then it gets terminated at middle box and re-
>> originated towards the other end after necessary stream id mapping.
>> One way to avoid such mapping is to use external negotiation of stream ids
>> as an alternative to inband DCEP.
> 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 agree that the DTLS hack is ugly. But glare resolution is ugly too.


>
> --Felix
>


-- 
Surveillance is pervasive. Go Dark.