Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

[Jose M Recio <[e-mail]>]

On 16/05/20 01:46, Christer Holmberg wrote:
>      > The problem is that there are multiple ways to set up a chat session
>      > under sip. This is much like the old problem of whether to IPv4 or IPv6
>      > in a c= line when you could do both. It took ICE to solve *that* problem
>      > in an acceptable way. AFAICT it isn't solved for chat. (The only likely
>      > solution that comes to mind is capability negotiation. But hardly
>      > anybody implements that do they?)
>      >
>      > I don't think it is necessary to solve it in this draft. But it would be
>      > good to at least acknowledge the problem.
>
>      This draft does *not* cover how you establish the SCTP association, and how you choose between IPv4, IPv6 etc for that association. There is a separate draft for that.
>
>      This draft does *not* even cover the generic procedures for negotiation a data channel. There is a separate draft for that.
>
>      This draft only describes the specifics associated with negotiation a data channel for MSRP usage.
I believe part of the confusion is that using data channels, transport 
negotiation and MSRP negotiation are not as tightly related as with 
other transports.

Given an example with the following sequence of steps on a web-based 
user UI:
- Alice wants to chat with Bob, opens a web page, logs in, selects Bob 
in an application-based address book, writes "Hello" and clicks Send

What this triggers, assuming that a) there is no pre-existing WebRTC 
PeerConnection between Alice and Bob; and b) session is established 
directly between Alice and Bob, i.e., no MSRP data channel gateway is used:
1. Alice and Bob setup a WebRTC PeerConnection that includes a SCTP 
association. An out-of-band signaling channel, provided by the web 
application, is used to exchange the messages required for the negotiation
2. WebRTC PeerConnection and SCTP association are established. As part 
of that, Alice and Bob web endpoints have found ICE candidates through 
which communicate
3. MSRP data channel is negotiated according to this draft. It will be 
instantiated as a new stream over the existing SCTP association, so the 
underlying transport (SCTP association, DTLS, ICE) is already setup, in 
advance. As this draft builds on mmusic-data-channel-sdpneg, an 
out-of-band signalling protocol is needed to exchange the SDPs, 
tipycally the same used to establish the WebRTC PeerConnection, provided 
by the web application.
3.1. Alice web endpoint fills up the SDP used to negotiate a MSRP data 
channel over the already existing SCTP association, in particular:
3.1.1 IP address and port for m= and c= lines are obtained from the 
appropriate ICE candidate in the WebRTC PeerConnection
3.1.2 domain part of the MSRP URI are obtained from application policy, 
configuration, or address book
3.2. Bob receives the MSRP data channel SDP offer from Alice, fills up 
the response also using the IP address and port from the ICE candiate in 
the WebRTC PeerConnection for the m= and c= lines, and so on
3.3. MSRP data channel negotiation succeeds, and MSRP session is open
4. Alice MSRP stack sends "Hello" over the negotiated MSRP data channel 
and message is received by Bob MSRP stack

This is not so complicated in practice. For browser endpoints, steps 1 
and 2 are hidden behind the W3C WebRTC JS API. Steps 3 and 4 can reuse 
existing MSRP stacks, unchanged for the most part, and driven by 
negotiation code