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

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2019 18:43:39 +0000

Hi,

...

>> Also, section 6 says: "Path attributes SHALL NOT be used for transport level interworking." What is meant by that?
>>    
> My understanding is that it means that the URI fields (IP, port, etc) 
> should not be used for the purposes of establishing the transport 
> towards the endpoint.

In fact, I think the whole paragraph is unclear:

   "Alternately, the gateway can use CEMA procedures to provide transport
   level interworking between MSRP endpoints using different transport
   protocols as follows.  For example, if the gateway is implemented on
   an Session Border Controller, it can use CEMA towars the inside
   network, using a non-data channel transport; but the gateway can not
   use CEMA towards endpoints using data channel transport.  Path
   attributes SHALL NOT be used for transport level interworking."

What is an "inside network"? I assume that is what is meant by the legacy TCP/TLS MSRP network, but we shall not call it  "inside network". I will use "legacy" network in this reply.

I think the procedures (when the gateway is NOT an MSRP B2BUA are as following):

- The gateway MUST use CEMA towards the legacy network. Because, the gateway will insert itself in the MSRP path by modifying the c/m- lines, and it needs to make sure the remote peer sends its MSRP messages towards the gateway (the path points towards the data channel endpoint).
- The gateway MUST insert, remove of modify the path attribute. It will simply forward the path attribute received from the data channel- and legacy endpoints.
- The gateway MUST NOT modify the setup value

I think the second and third bullet is trying to define some of the above, but the text is unclear. For example, it talks about forwarding TCP and TLS parameters. Forward what and where? The TCP and TLS parameters are only going to be used on the legacy network.

- If the legacy network does *not* support CEMA, the gateway needs to act as an MSRP B2BUA.

Regards,

Christer   

    >
    > Regards,
    >
    > Christer
    >
    >
    > On 18/07/19 17:18, Christer Holmberg wrote:
    >> 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
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >> On 13/07/2019, 15.24, "mmusic on behalf of Makaraju, Raju (Nokia - US/Naperville)" <[email-masked] on behalf of [email-masked]> wrote:
    >>
    >>       >[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
    >>       >using data channel transport.
    >>       [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
    >>       
    >>       
    >>       On 9/7/19 10:57 AM, Makaraju, Raju (Nokia - US/Naperville) wrote:
    >>       > 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.
    >>       
    >>       [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 only one MSRP m= line?
    >>       >
    >>       [JM] I agree for RCS should be like that. Would mandating this restrict applicability for other applications?
    >>       
    >>       > 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-cha
    >>       > nnel/
    >>       >
    >>       > 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-dat
    >>       > a-channel-11
    >>       >
    >>       > A diff from the previous version is available at:
    >>       > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-ch
    >>       > annel-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
    >>       >
    >>       > _______________________________________________
    >>       > mmusic mailing list
    >>       > [email-masked]
    >>       > https://www.ietf.org/mailman/listinfo/mmusic
    >>       
    >>       _______________________________________________
    >>       mmusic mailing list
    >>       [email-masked]
    >>       https://www.ietf.org/mailman/listinfo/mmusic
    >>       
    >>       _______________________________________________
    >>       mmusic mailing list
    >>       [email-masked]
    >>       https://www.ietf.org/mailman/listinfo/mmusic
    >>       
    >>

---

From: Jose M Recio <[email-masked]>
Date: Wed, 14 Aug 2019 19:45:08 +0800

On 12/08/19 02:43, Christer Holmberg wrote:
> - If the legacy network does*not*  support CEMA, the gateway needs to act as an MSRP B2BUA.
The last paragraph would remove a lot of issues and your proposal 
captures in a more clear way the gist of what I believe the draft 
intended to say.

Following your sugestion I have uploaded the xml document to this github 
repo:
https://github.com/josemrecio/draft-msrp-data-channel

I have already incorporated your very good suggestion to work in 
progress version 13 draft and committed.