[rtcweb] IETF#91: Notes from 1st RTCWEB session

[Christer Holmberg <[e-mail]>]

Hi,

Below are my notes from the 1st RTCWEB session.

Regards,

Christer

----------------



Topic:JSEP

Draft: draft-ietf-rtcweb-jsep-08

Presenter: Eric Rescola



Presentation of the updates in the latest version of the draft.





m- line considerations:



Indicated that the SDP fingerprint attribute will be used to indicate that DTLS-SRTP is used.



It was commented that the fingerprint attribute is currently optional in the SCTP-SDP draft. Indicated that it sounds like an error in the SCTP-SDP draft.





BUNDLE clarification:



It was commented that a JavaScript application cannot request a browser to not offer BUNDLE, in case it is known that the remote peer does not support BUNDLE. Indicated that BUNDLE works with such peers, as BUNDLE will be disabled if not supported by the peer.





BUNDLE/MUX policy (#91):



Question whether we need to be able to explicitly specify usage of rtcp-mux. Why can't the max-bundle option implicitly include usage of rtcp-mux? Indicated that it has previously been stated that one may want to do max BUNDLE, but not use rtcp-mux.



OUTCOME: ???





Value of {local/remote} description when closed (#88).



OUTCOME: This belongs to the W3C spec. No need to say anything in the JSEP draft.





a=ssrc for a=recvonly m= lines (#79):



OUTCOME: The suggested proposal was not accepted. Some more thinking about this is needed.





Death of a one-way stream (#76)



Indicated that we need a way to indicate, for a given m- line, "I am never going to send media associated with this m- line again" and "I never want to receive media associated with this m- line again".



Indicated that it has previously been agreed to bring the issue to MMUSIC, but that has not yet happened. A volunteer is needed.



OUTCOME: This issue needs to be brought to MMUSIC, but unclear who will bring it.





Signaling synchronization (#31):



OUTCOME: If LS is not indicated, streams are synchronized if they share the same CNAME value.





Changing b= (#9):



It was indicated that Magnus was supposed to produce text, and that a new volunteer is needed. However, it was unclear what the issue is.



OUTCOME: Agreed to wait until Magnus comes back, as the issue will most likely delay the JSEP draft.







Topic:WebRTC Data Channels

Draft: draft-ietf-rtcweb-data-channel

Presenter: Salvatore Loreto





Provided status update based on the IESG review. There are no DISCUSSes, but some COMMENTs.



Indicated that we need to decide whether to use DTLS 1.0 or DTLS 1.2.



Indicated that DTLS 1.2 is not widely available at this stage.



OUTCOME:



- MUST support 1.0, SHOULD support latest version.

- No objection to having a reference to RFC 6347.

- We need to adjust the crypto suites (Cullen)







Topic: WebRTC Terminology

Draft: draft-ietf-rtcweb-overview

Presenter: Harald Alvestrand



The discussion focused on the split between a WebRTC browser and a WebRTC device. It was indicated that "device" terminology is confusing.



It was suggested to talk about "native applications" instead of "devices".



It was suggested to simply talk about "non-browsers" instead of "devices".



It was asked whether a browser plug-in, providing WebRTC JavaScript API functionality to a non-WebRTC browser, is considered a "browser" or a "device". The combination of the browser and the plug-in is considered a "browser".



It was asked whether a non-JavaScript library, very similar to the WebRTC JavaScript API, providing similar functionality, the WebRTC API to a non-WebRTC browser, is considered a "browser" or a "device".



OUTCOME: It was agreed to talk about "browsers" and "non-browsers", and the next version of the draft will incorporate that terminology.







Topic: Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC

Draft: draft-schwartz-rtcweb-return

Presenter: Justin Uberti



It was realized that very few people had read the draft.



Half of the participants thought the draft should be adopted as a WG draft.



OUTCOME: Further discussions on the list are needed, before a decision to adopt the draft can be made.







Topic: WebRTC Gateways

Draft: draft-alvestrand-rtcweb-gateways

Presenter: Harald Alvestrand



Indicated that gateways are not part of the core WebRTC architecture, but they are never the less important in order to be able to achieve interoperability between WebRTC devices and legacy devices and systems.



Described how gateway are different from WebRTC browsers, related to security considerations, support of features (e.g. ICE), specific codecs etc.



Indicated that it was previously agreed to add a section about gateway to the common overview document, rather than having a separate document. Indicated the minutes from the previous meeting indicate that having a separate document for gateway was the preferred way forward.



OUTCOME: Further discussions on the list are needed, before a decision to adopt the draft can be made.