FWIW, this topic might also be discussed during next TPAC within the WebRC WG
(https://docs.google.com/document/d/1N8Px_UfBRkvVJbRT3pQMiYKVDmg9grPQIrsOkgFoDWM/edit
<https://docs.google.com/document/d/1N8Px_UfBRkvVJbRT3pQMiYKVDmg9grPQIrsOkgFoDWM/edit>).
What Pauly suggests makes sense to me. Having some discussion during next IETF
meeting seems beneficial.
I would hope we could define a data channel API/QUIC mapping based on TAPS.
Understanding the shortcomings of current data channels would be useful.
I can see some cases that might be interesting to study further:
- Use the same QUIC connection for both media exchange and data channel
- Use an existing QUIC/HTTP connection for data channel: Web Socket or SCTP
data channel replacement
Y
> On Oct 12, 2018, at 12:52 PM, Tommy Pauly <[email protected]> wrote:
>
> I think it would be useful to have agenda time in TAPS to discuss both:
>
> - Transport API mappings for QUIC
> - TAPS API mappings for WebRTC
>
> Having input on the requirements and background for WebRTC + QUIC would be
> great.
>
> Thanks,
> Tommy
>
>> On Oct 12, 2018, at 12:48 PM, Aaron Falk <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On 11 Oct 2018, at 17:14, Tommy Pauly wrote:
>>
>> I think this also brings up a point that it may be good to have a discussion
>> in Bangkok with the group about getting a bit more in detail to how TAPS can
>> best serve WebRTC use cases, and make that aspect of the API really concrete.
>>
>> Are you thinking an offline discussion or would you like to spend some
>> agenda time on the topic? I could invite the authors to present.
>>
>> --aaron
>>
>
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
