Re: [rtcweb] Default proto transport in JSEP

[Iñaki Baz Castillo <[e-mail]>]

On Mon, 19 Nov 2018 at 22:08, Roman Shpount <[e-mail]> wrote:

> If anybody ever implements data channels over QUICK vs SCTP, proto is the place to specify this. ICE candidates will only tell the end point that UDP vs TCP,. Kind only tells the type of stream. If there is more then one way to transport this data (SCTP vs QUICK), proto is required.

I understand your points, and you are right in all of them. I just
don't believe that this is gonna happen in SIP world within next 25
years. I mean: in order to explain this you have moved to
DataChannels, which will never exist in SIP-land (BFCP already exists
which is implemented by 2-3 devices).


> Also, you ignored the question that I asked you. What is the issue that you see with:
> m=audio 9 UDP/TLS/RTP/SAVPF [codec PTs]
> c=IN IP4 0.0.0.0

No problem other than announcing UDP while the effective candidate
pair may use TCP. If that's not a problem, then ok.


>> > Please read https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5
>> > Some people for some reason insist on following specifications. If you propose to do two opposite things, random things start being implemented.
>>
>> So, that spec is completely making it imposible to enable ICE trickle
>> because it mandates that the value in c= and m= must already match an
>> existing a=candidate line in the same SDP. This is not true when using
>> Trickle ICE since candidates may be sent later that the SDP:
>>
>> https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-18
>>
>
> ICE trickle is supported. Please read  second bullet point of https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5

Didn't know that. Thanks.


-- 
Iñaki Baz Castillo
<[e-mail]>