Re: [MMUSIC] [Technical Errata Reported] RFC8864 (7805)

[Gunnar Hellström <[e-mail]>]

Inspired by Harald's indication of the use of negotiated=true in 
CreateDataChannel, I searched for a corresponding possibility in RFC 
8864 to just do the SDP negotiation there and then use the API and DCEP 
to create the channel, with the application remembering the negotiated 
DCSA parameters, and handing over the DCMAP parameters to DCEP that it 
wants for establishing the negotiated channel.

And I found this sentence by the end of the first *-point in 6.5:  " At 
this point, the offerer may use DCEP negotiation [RFC8832] to open data 
channels."  It is hidden after a lot of talking about what to do if the 
answer does not accept the proposed channels, so that one can get the 
impression that the application gives up with SDP negotiation and moves 
to plain DCEP, but now I read it as "the remaining negotiated data 
channels can be established by DCEP and the webRTC API using the 
negotiated=true parameter and the DCMAP attributes collected during the 
SDP negotiation phase". And remembering the DCSA parameters to act on 
between the applications.

If my reading is right, the sentence " At this point, the offerer may 
use DCEP negotiation [RFC8832] to open data channels." should be made 
stand out better from all the negative statements before it.

And a change to read "The offeror may then use DCEP negotiation 
[RFC8832] to open any remaining positively negotiated data channels."

However, I realize that the leading "At this point" may refer to the 
situation just before that, when no offered data channel was accepted. 
The solution may be usable anyway, it seems to me that the 
negotiated=true on the API side is intended for this kind of solution.

A question: There is talk in RFC 8864 about establishing and reusing the 
SCTP association. Can that also be done by WebRTC API calls?

  Regards

Gunnar

Den 2024-04-04 kl. 19:58, skrev Paul Kyzivat:
> Harald,
>
> I'm confused. I thought DCEP was created to support WebRTC usage. It 
> included the even/odd rule, I suppose because the people defining DCEP 
> thought it was needed. RFC8864 was defined for use by a different 
> constituency. *It* included the even/odd rule solely for compatibility 
> with DCEP. Now it seems you are saying that WebRTC can't comply with 
> the even/odd rule so RFC8864 should be revised to remove that.
>
> Are you also asking for DCEP (RFC8832) to remove its even/odd rule? If 
> not, why not?
>
>     Thanks,
>     Paul
>
> On 4/4/24 10:13 AM, Harald Alvestrand wrote:
>> On 4/4/24 15:58, Christer Holmberg wrote:
>>> Hi,
>>>
>>>>> I am not sure what you mean be "pre-agreed data channels", but I was
>>>>> referring to applications that use both DCEP and SDP.
>>>>
>>>> I was specifically referring to datachannels created with the 
>>>> "negotiated"
>>>> flag
>>>> set to "true".
>>>
>>> Gotcha.
>>>
>>> So, you are saying there ARE applications that use both DCEP and SDP
>>> ("negotiated" flag set to "true") to negotiate data channels?
>>
>> Yes. We've seen it used.
>>
>>>
>>>> WebRTC, as currently specified, will ignore all attempts to negotiate
>>>> datachannels using SDP, so those channels can only be created by the
>>>> application parsing the SDP, extracting the information, and calling
>>>> "createDataChannel" with "negotiated" set to true.
>>>
>>> Correct.
>>>
>>>>> Also, your claim that the DCEP odd/even restriction would not 
>>>>> apply for
>>>>> certain cases is (AFAIK) not defined anywhere. Also, I don't 
>>>>> understand why
>>>>> the odd/even restriction would not apply in the case where you 
>>>>> have pre-
>>>>> agreed data channels.
>>>>
>>>> The WebRTC spec, at
>>>> https://w3c.gi/
>>>> thub.io%2Fwebrtc-pc%2F%23dom-rtcdatachannelinit-
>>>> id&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C3bd0b5c63c86
>>>> 470f330f08dc54a2bc12%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
>>>> %7C638478305114832628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>>> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C
>>>> %7C&sdata=HbedMunDcF%2Fvy7YawmqPo%2FFBhqi7kjeflQWO185SXvQ%3
>>>> D&reserved=0, does not
>>>> mention the odd/even rule. For good reason; both ends have to call
>>>> createDataChannel with the same value for "id", so it *has* to 
>>>> "violate"
>>>> the odd/even rule.
>>>
>>> Both endpoints obviously have to use the same "id", but one endpoint 
>>> has to
>>> decide which "id" to use, and when using SDP the idea was to re-use 
>>> the DCEP
>>> odd/even rule.
>>
>> And that re-use is exactly the thing that we can't do.
>>
>>>
>>> I DO agree that the odd/even rule does not work in SDP actpass cases 
>>> (where
>>> the id has to be set before the DTLS roles have been determined), 
>>> and should
>>> be corrected, but I am not sure whether the correction suggested in 
>>> the errata
>>> is the right way.
>>
>> I'm happy to see alternate text suggested. My suggestion was only in 
>> order to have something specific to suggest in order to get rid of 
>> the inappropriate MUST.
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
------------------------------------------------------------
Gunnar Hellström
GHAccess
[e-mail]
Tel: [phone]