Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt

From: "Makaraju, Raju (Nokia - US/Naperville)" <[email-masked]>
Date: Tue, 9 Jul 2019 02:57:33 +0000

Do we need to make any further clarifications for the references to CEMA?
Section 5.1.1.2 has a sentence that is a little awkward, but seems to be saying the CEMA is out of scope.
But in section 6 for gateway function it mentions CEMA can be used.

My understanding is I think section 6 suggests to use CEMA equivalent procedures without CEMA attributes!

Also, in section 6 should we add a further statement that the gateway assumes one MSRP data channel instance and one sub-protocol per SIP dialog as RCS mandates that a single SIP session/dialog has only one MSRP m= line?

Thanks
Raju

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of [email-masked]
Sent: Saturday, June 1, 2019 11:22 PM
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF.

        Title           : MSRP over Data Channels
        Authors         : Keith Drage
                          Maridi R. Makaraju (Raju)
                          Juergen Stoetzer-Bradler
                          Richard Ejzak
                          Jerome Marcon
                          Jose M. Recio
	Filename        : draft-ietf-mmusic-msrp-usage-data-channel-11.txt
	Pages           : 19
	Date            : 2019-06-01

Abstract:
   This document specifies how the Message Session Relay Protocol (MSRP)
   can be instantiated as a data channel sub-protocol, using the SDP
   offer/answer exchange-based generic data channel negotiation
   framework.  Two network configurations are documented: a WebRTC end-
   to-end configuration (connecting two MSRP over data channel
   endpoints), and a gateway configuration (connecting an MSRP over data
   channel endpoint with an MSRP over TCP or TLS endpoint).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-11
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-data-channel-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-11

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Jose M Recio <[email-masked]>
Date: Tue, 9 Jul 2019 21:23:19 +0800

> Section 5.1.1.2 has a sentence that is a little awkward, but seems to be saying the CEMA is out of scope.

[JM] Draft covers either direct connection to an endpoint or direct 
connection to a gateway. As middleboxes are out of scope in the 
connection using data channel, then CEMA is out of scope. This short 
explanation currently appears as justification for saying that CEMA is 
out of scope. I can remove the explanation and just state that CEMA is 
out of scope.

> But in section 6 for gateway function it mentions CEMA can be used.

[JM] Draft supports gateways providing transport level interworking 
between MSRP endpoints using different transport protocols. CEMA can't 
be used towards the endpoints using data channel transport, but the GW 
could use CEMA to interwork with endpoints using other protocols.

For example, if the GW is implemented on an SBC, it can use CEMA towars 
the inside network, using a non-dc transport. But not towards endpoints 
using data channel transport.

> My understanding is I think section 6 suggests to use CEMA equivalent procedures without CEMA attributes!

[JM] GW can use CEMA with endpoints using non-dc transports. This can be 
removed, but I think it would make the GW transport interwork option too 
restrictive. The B2BUA GW would not be affected.

> Also, in section 6 should we add a further statement that the gateway assumes one MSRP data channel instance and one sub-protocol per SIP dialog as RCS mandates that a single SIP session/dialog has…
[JM] I agree for RCS should be like that. Would mandating this restrict 
applicability for other applications?

---

From: "Makaraju, Raju (Nokia - US/Naperville)" <[email-masked]>
Date: Sat, 13 Jul 2019 12:23:53 +0000

>[JM] Draft covers either direct connection to an endpoint or direct connection to a gateway. As middleboxes are out of scope in the connection using >data channel, then CEMA is out of scope. This short explanation currently appears as justification for saying that CEMA is out of scope. I can remove >the explanation and just state that CEMA is out of scope.
[Raju] I agree with that.

> For example, if the GW is implemented on an SBC, it can use CEMA towars the inside network, using a non-dc transport. But not towards endpoints 
[Raju] Let's please make this clear in the draft.

>[JM] I agree for RCS should be like that. Would mandating this restrict applicability for other applications?
[Raju] I agree that such design limitation should only be for RCS (self-imposed), but not for other applications.

Thanks
Raju

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Jose M Recio
Sent: Tuesday, July 9, 2019 8:23 AM
To: [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt

> Section 5.1.1.2 has a sentence that is a little awkward, but seems to be saying the CEMA is out of scope.

[JM] Draft covers either direct connection to an endpoint or direct connection to a gateway. As middleboxes are out of scope in the connection using data channel, then CEMA is out of scope. This short explanation currently appears as justification for saying that CEMA is out of scope. I can remove the explanation and just state that CEMA is out of scope.

> But in section 6 for gateway function it mentions CEMA can be used.

[JM] Draft supports gateways providing transport level interworking between MSRP endpoints using different transport protocols. CEMA can't be used towards the endpoints using data channel transport, but the GW could use CEMA to interwork with endpoints using other protocols.

For example, if the GW is implemented on an SBC, it can use CEMA towars the inside network, using a non-dc transport. But not towards endpoints using data channel transport.

> My understanding is I think section 6 suggests to use CEMA equivalent procedures without CEMA attributes!

[JM] GW can use CEMA with endpoints using non-dc transports. This can be removed, but I think it would make the GW transport interwork option too restrictive. The B2BUA GW would not be affected.

> Also, in section 6 should we add a further statement that the gateway assumes one MSRP data channel instance and one sub-protocol per SIP dialog as RCS mandates that a single SIP session/dialog has…
[JM] I agree for RCS should be like that. Would mandating this restrict applicability for other applications?

> Subject: [MMUSIC] I-D Action: 
> draft-ietf-mmusic-msrp-usage-data-channel-11.txt
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jul 2019 09:18:31 +0000

Hi,

If think there is a bigger question here, that MAY have to be clarified ietf-mmusic-data-channel-sdpneg:

To my understanding, the SDP dcsa attribute is used to provide information that is needed to operate the protocol (MSRP in this case) on the data channel - between the data channel endpoints.

Now, if the data channel peer is a GW, and you need to provide some information (path attributes etc in the case of MSRP) for what happens beyond the GW, is the dcsa attribute really intended for that?

So, if the data channel peer is an MSRP GW, using legacy MSRP on the "other side", is the dcsa attribute the correct mechanism to provide the GW with whatever information is are needed on the "other side"?

Regards,

Christer

    

    Thanks
    Raju

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jul 2019 20:37:04 +0000

Hi,

I have been thinking more about signalling of the path attribute within a dcsa attribute.

I think it is fine to do it, but we need to make it clear that it is not used for routing MSRP between the data channel endpoints, as the MSRP messages will be routed inside a data channel. The draft already has text about that, so so far so good.

One thing that needs to be clarified, however, is whether there should be a path attribute pointing to the peer data channel endpoint. I could not find much text on that in the draft. Section 4.4 talks about "the MSRP-URI that represents an MSRP data channel endpoint", but I can't find any text on how it is actually used.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic <[email-masked]> Puolesta Makaraju, Raju (Nokia - US/Naperville)
Lähetetty: lauantai 13. heinäkuuta 2019 15.24
Vastaanottaja: Jose M Recio <[email-masked]>; [email-masked]
Aihe: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt

> For example, if the GW is implemented on an SBC, it can use CEMA 
>towars the inside network, using a non-dc transport. But not towards endpoints using data channel transport.

Thanks
Raju