Subject: [MMUSIC] Comments on draft-ejzak-dispatch-msrp-data-channel-00

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Feb 2014 18:13:28 -0500

A few comments/questions on this draft:

Section 5.1.1.2 says:

    The msrp-cema attribute shall be assumed to be present for every MSRP
    session using data channel transport, so the inclusion of the msrp-
    cema attribute is optional.  This ensures that the data channel
    transport for the MSRP session is established without using the path
    attribute.

Why is use of cema mandatory?

RGC6714 has fallback rules for an endpoint that supports cema to 
interoperate with one that does not. That requires removing the 
indication of cema support. How does an msrp data channel endpoint do that?

Section 5.1.3 says:

    Each text-based MSRP message is sent on the corresponding SCTP stream
    using standard MSRP framing and chunking procedures, as defined in
    [RFC4975], with each MSRP chunk delivered in a single SCTP user
    message.

I think it would be better to say:

    Each text-based MSRP message is sent on the corresponding SCTP stream
    using standard MSRP framing and chunking procedures, as defined in
    [RFC4975], with each MSRP chunk delivered in a single Data Channel
    user message.

While data channel user messages map directly onto SCTP user messages, 
they are conceptually distinct.

Section 6 says:

    o  The endpoint establishing an MSRP session using data channel
       transport shall not request inclusion of any relays, although it
       may interoperate with a peer that signals the use of relays.

Why must relays not be requested? That seems the most natural thing to 
do if the goal is to talk to a peer that doesn't support data channels.

In any case, some explanation of how things work with relays would be 
appreciated.

	Thanks,
	Paul

---

From: Richard Ejzak <[email-masked]>
Date: Sun, 23 Feb 2014 19:13:07 -0600

> Why is use of cema mandatory?

Existing MSRP procedures (without CEMA) are based on using the Path
attribute to establish the transport connection (and essentially ignore the
connection information associated with the m line).  If you are going to
use a data channel, then you have no choice but to use the one established
by the peer connection, so the existing MSRP procedure will NOT WORK.  CEMA
allows you to set up a tls or tcp connection based on the connection
information in the m line rather than in the path attribute, but this is
still not everything needed to make it work with data channels.  But it's a
start.

> interoperate with one that does not. That requires removing the indication
> of cema support. How does an msrp data channel endpoint do that?
>

Interoperating with an endpoint that does not support data channel will
require going through a gateway that does.  This gateway will have to do
something to provide a tls or tcp transport connection suitable for the
other peer.  If the gateway can't do the enhanced CEMA procedures described
here, it will have to perform as an MSRP B2BUA.

> they are conceptually distinct.

Agreed.

> Why must relays not be requested? That seems the most natural thing to do
> if the goal is to talk to a peer that doesn't support data channels.
>

The MSRP relay is not typically on the signaling path, so is an unlikely
data channel endpoint unless a separate peer connection and data channel is
established just for MSRP.  This would be silly to do.  We want a gateway
that is on the signaling path to perform any necessary conversion.  The
CEMA gateway model is a much better fit and makes the use of relays
unnecessary (at least on the side of the user using a data channel for
MSRP).

> In any case, some explanation of how things work with relays would be

I must say that CEMA is confusing, and I agree that the CEMA parts of the
document are not easy to follow without a thorough understanding of CEMA.
 Since the CEMA RFC already explains all the confusing bits, I'm reluctant
to repeat all of that here...  Perhaps a note that a thorough understanding
of CEMA is necessary background for the CEMA stuff here?

Richard

>         Thanks,
>         Paul
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Feb 2014 10:24:58 -0500

On 2/23/14 8:13 PM, Richard Ejzak wrote:
>
>
>
> On Sun, Feb 23, 2014 at 5:13 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> attribute to establish the transport connection (and essentially ignore
> the connection information associated with the m line).  If you are
> going to use a data channel, then you have no choice but to use the one
> established by the peer connection, so the existing MSRP procedure will
> NOT WORK.

Ahh! Of course.

> CEMA allows you to set up a tls or tcp connection based on
> the connection information in the m line rather than in the path
> attribute, but this is still not everything needed to make it work with
> data channels.  But it's a start.
>
>
> other peer.  If the gateway can't do the enhanced CEMA procedures
> described here, it will have to perform as an MSRP B2BUA.

I gather you are thinking that this gateway won't be an MSRP relay?

>     While data channel user messages map directly onto SCTP user
>     messages, they are conceptually distinct.
>
>
> Agreed.
>
>
>     Section 6 says:
>
>     Why must relays not be requested? That seems the most natural thing
>     to do if the goal is to talk to a peer that doesn't support data
>     channels.
>
>
> data channel endpoint unless a separate peer connection and data channel
> is established just for MSRP.  This would be silly to do.  We want a
> gateway that is on the signaling path to perform any necessary
> conversion.  The CEMA gateway model is a much better fit and makes the
> use of relays unnecessary (at least on the side of the user using a data
> channel for MSRP).

ISTM there are lots of layers here. With webrtc the "signaling path" is 
pretty much out of scope, so it is unclear exactly what you mean in that 
case. (Usually there will be a web server on the signaling path between 
the two peers. Potentially that web server could have a relationship 
with an MSRP gw, that could have relay capabilities.)

I guess I'm mostly just confused on how this all hangs together.

>     In any case, some explanation of how things work with relays would
>     be appreciated.
>
>
> I must say that CEMA is confusing, and I agree that the CEMA parts of
> the document are not easy to follow without a thorough understanding of
> CEMA.  Since the CEMA RFC already explains all the confusing bits, I'm
> reluctant to repeat all of that here...  Perhaps a note that a thorough
> understanding of CEMA is necessary background for the CEMA stuff here?

Maybe. Obviously *I* need to study CEMA more carefully.

	Thanks,
	Paul

> Richard
>
>
>
>              Thanks,
>              Paul
>
>     _________________________________________________
>     mmusic mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>