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

Gunnar Hellström <> Sun, 10 May 2020 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AE623A0BAD for <>; Sun, 10 May 2020 13:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9ulVmp-1tDnc for <>; Sun, 10 May 2020 13:47:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22B0F3A0BAA for <>; Sun, 10 May 2020 13:47:21 -0700 (PDT)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id C58052009C; Sun, 10 May 2020 22:47:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1589143638; bh=gx+8Y/VD1JKeWFR8L3fXCXEpiMSyyr6qXSh0Y8GvC2U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=aC+yIH2Qr1fD8e+yi7Uxg92uqFu3JASp3BT4uDnRFTOtX9in0QGSowEjjh6OJ52XN 2J8d1nrDYb1PcY1pmfG4oCGUzddAqzQn4CrGBOpjtK/dSu9fipxO5+gNcf/xu7ZFT1 +okG+8ZZnIhW5REaA8D2NECrk9z1zr8vRu/Y6QSI=
To: Christer Holmberg <>, Jose M Recio <>, "" <>
References: <> <> <> <> <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Sun, 10 May 2020 22:47:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------D1147BA50B218AA86A4058A1"
Content-Language: sv
Archived-At: <>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 May 2020 20:47:31 -0000


Den 2020-05-10 kl. 19:57, skrev Christer Holmberg:
> ​Hi,
> >>>I have the following comments/questions:
> >>>1. Should the draft say that it updates RFC 4975?
> >>>The msrps scheme is also IANA-registered in RFC 4975 section 15.5.2.
> >>>Please check if that registration need update because of the reuse 
> of the msrps scheme.
> >>
> >>Thanks for bringing this back. WG was asked for feedback about 
> updating IANA registry or
> >>keeping as it is, with the argument that data channel uses DTLS so 
> it would conform
> >>original “msrps” requirement, that refers to TLS. There was no clear 
> outcome.
> >>
> >>If there are no comments opposing this, I would follow your comment 
> and add it to IANA updates section
> >Good.
> >Would it also be suitable to say that the draft updates RFC 4975, 
> because of this?
> I agree that a reference to the document should be added to the IANA 
> registry for the "msrps" scheme.
> And, if people think 4975 should be updated, I guess we could say 
> something like:
> "This document RFC 4975, by allowing the usage of the "msrps" scheme 
> when the underlying connection is protected with DTLS."
I assume you mean that the sentence starts: "This document updates RFC 
4975 ...."
> ---
> >>>2. Data reception is not mentioned.
> >>>Section 5.5 is about data sending and reporting. There is no 
> section about data receiving.
> >>>It seems that as for sending, it would be sufficient to refer to 
> RFC 4975.
> >>>I suggest that data reception is included in section 5.5.
> >>
> >>I propose:
> >>"Data sending, receiving and reporting procedures SHALL conform to 
> RFC4975"
> >
> >Fine.
> I am ok with that.
> On a more generic level, should be replace "SHALL" with "MUST" 
> throughout the document? Currently we are using both "MUST" and 
> "SHALL", and I think it would be good to be consistant.
> ---
> >>>3. Channel or association failure handling should be specified
> >>>There is nothing said about channel failures or SCTP association 
> failures. I assume
> >>>that transmission failures are handled under "reporting" in section 
> 5.5, but that does
> >>>not cover channel or association failures.
> >>>
> >>>RFC 4975 has a section 5.4 "MSRP Connection Model" that includes 
> connection failures, and
> >>>considerations for retrying a failed connection. Please check if it 
> can be sufficient to refer to
> >>>that section for this issue.
> >>
> >>I think RFC4975 should be enough, failures detected at transport 
> (data channel) level should
> >>trigger the actions specified in RFC4975. I will add a comment.
> >>
> >>> Sections 4.6 and 5.3 in the draft are about session closing, 
> requiring SDP signaling for session closing.
> >>> Consider adding some words about that nomal closing requires SDP 
> signaling, while connection failure
> >>> may result in session closing without sdp exchange.
> >
> >What about this:
> >
> >Changing "The closure of an MSRP session MUST be signaled via an SDP" 
> -> "Normal closure of an MSRP session MUST be signaled via an SDP"
> >
> >Adding "Connection failure may result in session closing without SDP 
> exchange. If the endpoint attempts to re-create the session,
> >procedures specified in RFC4975 SHALL be followed"
> Actually, I would suggest some re-wording.
> Some details can be removed, since we are following the procedures in 
> draft-mmusic-data-channel-sdpneg: we don't need to talk about 
> offer/answer, and we don't need to talk about which endpoint triggers 
> the actual data channel closure procedure.
> Also, there is no need for a MUST, because we simply describe how the 
> MSRP session is closed.
> OLD:
>     The closure of an MSRP session MUST be signaled via an SDP offer/
>     answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute
>     lines associated with the MSRP session from the associated DTLS/SCTP
>     based media description.  This results in the associated data channel
>     being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg],
>     where the actual data channel closure procedure is typically
>     initiated by the SDP answerer right after having accepted the SDP
>     offer.
> NEW:
>     An MSRP session is closed by closing the associated data channel,
>     fllowing the procedures in [I-D.ietf-mmusic-data-channel-sdpneg].


But I think the draft lacks general requirements to apply procedures 
from RFC 4975 and just modify them by msrp channel specific procedures.

It may be felt as obvious, but I cannot find it stated anywhere.

Especially in the beginning of section 5. MSRP Considerations :

Current text: "

  This section describes the MSRP considerations specific to a MSRP
    data channel.


Proposed text:

" The procedures specified in RFC 4975 apply except when specifications 
in the present document introduces other procedures.

This section describes the MSRP considerations specific to a MSRP

    data channel."

> >I think you are also obliged to do some actions to clean up from the 
> lost channel or association. Please check the
> >data channel specs if anything more is needed. E.g. sdpneg section 
> 6.6.1, but I am not sure that the channel close
> >that is specified there is close because of failure.
> Per 4975, if the connection fails, endpoints MUST consider the MSRP 
> session failed. There is no requirement to do any clean-up, or try to 
> re-establish the connection.
Yes, but I meant clean-up after the lost MSRP data channel, e.g. sdpneg 
section 6.6.1, and maybe something more if the closure is because of a 
connection failure.
> We could add something like:
> "If the SCTP association [RFC4960] used to realize the MSRP data 
> channel fails and gets torn down, the endpoints MUST consider the MSRP 
> session
> failed. An MSRP endpoint MAY, based on local policy, try to 
> re-establish the SCTP association, and negotiate a new MSRP data channel."
Yes, but I suggest adding  both sdpneg section 6.6.1 and RFC 4975 
section 5.4 Connection model.

(I think there may be a general lack of specification in the RTCWeb and 
WebRTC and data channel documents about how to handle connection and 
association failures, but that is a topic for another discussion)



> Regards,
> Christer
Gunnar Hellström