Subject: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Mar 2013 16:11:38 +0100

Hi,

I have reviewed the SDP description of SCTP and have some comments and
suggestions.

1. My first comments is a very general one and concerns the relationship
between the proposed SCTP related proto identifiers and ICE for the
DTLS/SCTP encapsulation.

When ICE was defined it was natural to include ICE by reftorfitting it
to existing proto identifiers. However, given that this specification
intorduce a number of new identifiers I do woner if we should be more
explicit about the ICE usage in the proto field. I think have both pro
and cons for this.

So my considerations is basically to include specification of
ICE/DTLS/SCTP, where the lower layer transport is defined by what ICE
agrees on. This makes a lot of sense given that ICE can in fact arrive
on the usage of TCP/framing/DTLS/SCTP, TCP/TURN/DTLS/SCTP in addition to
more expected choices as UDP/DTLS/SCTP. This makes it clears that you do
require ICE to negotiate this transport flow. At the same time it is a
significant downside if ones negotiation needs are to chose between
using ICE or a specific lower layer transport.

These comments doesn't apply when one runs SCTP on top of IP.

2. Section 1:
RFC4145 [RFC4145] specifies a general mechanism for
   describing and establishing TCP (Transmission Control Protocol)
   streams.

I do dislike that usage of the RFC number as the explanation of what the
referenced document is. The previous sentence is how I prefer it to be
done:
   SDP (Session Description Protocol) [RFC4566] provides a general-
   purpose format for describing multimedia sessions in announcements or
   invitations.

Use the document title or an abbreviated explanation for what the
referenced document specifies and one gets much better flow in the
reading as one don't have stop look up the reference to find out what is
referred to.

3. Section 1:
I think having first a paragraph for SCTP and then having "Additionaly
.." with the other two protos are bit strange. Why not simpley say. This
document defines three proto identifiers: list of them with explnation.

4. Section 1:
   DTLS/SCTP :  to allow the usage of SCTP on top of the Datagram
      Transport Layer Security (DTLS) protocol, as defined in
      [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP.  SCTP over DTLS is
      used by the RTCWeb protocol suite for transporting non- media data
      between browsers.

This definitions says nothing of the lower transport layer for DTLS/SCTP
even if UDP is referred to in a later section. I think this needs to be
clarified and discussed in the context of which lower layers do we
expect to be supported? From my perspective I think two makes sense.
ICE/DTLS/SCTP that allows ICE to negoiate what ever and then
UDP/DTSL/SCTP that only uses UDP as lower layer. Lets other add other
variants in the future if needed.

5. Section 3:
   The 'DTLS/SCTP' protocol identifier indicates that the media
   described will use SCTP on top of the Datagram Transport Layer
   Security (DTLS) protocol as specified in
   [I-D.tuexen-tsvwg-sctp-dtls-encaps].

I would like to point out that the referenced document does not at all
indicate what lower layer is being used under DTLS.

6. Section 4.1:

This section discuss the usage of the "data channels" within the SCTP
association. My personal position is that for the moment this appears to
be unnecessary. The most important part is the SCTP association
establishment. Then one can discuss the general application using the
SCTP association as whole. Examples of such are WebRTC data channel.

If anyone want stream level information in SDP then I propose that this
is handled as a extension to this signaling, not an from the start
included functionality as we don't appear to have clear requirement for
that.

7. Section 4.2:

What are the requirements behind being able to establish multiple SCTP
association over the same DTLS connection? I am very unclear why this
would be required, and if not really needed I would suggest keeping
things simple.

8. Section 4.3: I guess this can for the moment be removed as it appears
to be taken care in other places, such as the RTCWEB WG data channel
protocol proposal.

9. If you are removing the multiple association and the "data channel"
parameters then most of the issues in section 5 vanish. If not I have
additional feedback on this section.

10. Section 8.

   Current NATs do not typically support SCTP.  As an alternative to
   design SCTP specific NATs, Encapsulating SCTP into UDP
   [I-D.tuexen-sctp-udp-encaps] makes it possible to use SCTP in
   networks with legacy NAT and firewalls not supporting SCTP.

First of all, there is a WG version for this document:
draft-ietf-tsvwg-sctp-udp-encaps-14. Which is in IESG evaluation. Thus I
wonder why signalling for this is not included when all the other
options are included, even less mature ones then this?

To me it looks like this document need to have some high level decisions
on what to include and not and then try to finish it up within the
agreed constraints. From my perspective I think it should focus on a
single SCTP association per m= line and the actual SCTP association.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Mar 2013 00:55:05 +0800

Magnus,

Some comments on your review, from a CLUE perspective:

> included functionality as we don't appear to have clear requirement for

Who is "we"?

In CLUE we expect to use this mechanism for a CLUE data channel.
And we intend to do so in pure sip-sip cases as well as webrtc-sip and 
webrtc-webrtc cases.

While webrtc-webrtc may have an independent mechanism to work out the 
channel usage, that is certainly not so for sip-sip sessions.

So I think "we" (CLUE) have a requirement to negotiate channel usage in SDP.

> would be required, and if not really needed I would suggest keeping

I agree there has been no compelling need advanced for multiple SCTP 
associations over the same DTLS connection. But the fact is that SCTP 
has its own notion of port, and that needs to be dealt with one way or 
another. At a minimum this document should specify what SCTP port is to 
be used when conforming to this specification.

> to be taken care in other places, such as the RTCWEB WG data channel

See above. That doesn't meet CLUE needs.

	Thanks,
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Mar 2013 11:15:17 +0100

>> included functionality as we don't appear to have clear requirement for

MMUSIC WG

> And we intend to do so in pure sip-sip cases as well as webrtc-sip and

Yes.
> So I think "we" (CLUE) have a requirement to negotiate channel usage in

Do you? Or it is sufficient to say

m=application 12234 UDP/DTLS/SCTP CLUE

Indicating that this SCTP association is using CLUEs defined way, not
WebRTC. I want to separate the usage of individual SCTP streams and the
general usage of the SCTP association.

> be used when conforming to this specification.

Agreed, there need to be clarity on the port usage.

> See above. That doesn't meet CLUE needs.

Disagree, I don't think CLUE need SCTP stream specific indication or
negoitation. It will be sufficient to indicate that this is CLUE using SCTP.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Mar 2013 14:22:59 +0100

One high level comment:

This series of comments points out that the purpose of the thing called 
"proto identifier" in SDP is not really well documented.

As far as I can tell, the requirement is that it uniquely identifies the 
parser one needs to use for the stuff under this m= line, and that is 
the sum total of the requirements on it - as we painfully learned with 
RTP/AVP, RTP/AVPF, SRTP/AVP and SRTP/AVPF, making detailed information 
about the parameters available via the "proto identifier" is not really 
a Good Idea.

I suggest we go for DTLS/SCTP, as specified in the document currently, 
and document that the lower layer used has to be identified from the 
elements inside the m= line block; if there is ICE, ICE can negotiate 
it; if there is only a port number, it's UDP; if there are more 
extensions to specify that the lower layer is LTE over pterodactyls, the 
identifier doesn't change.

Same handling as for RTP/AVP(F), and no double specifications.

On 03/20/2013 04:11 PM, Magnus Westerlund wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Mar 2013 04:01:33 +0800

> general usage of the SCTP association.

Then what do we do for an WEBRTC client doing CLUE, talking to a native 
sip CLUE endpoint?

I guess clue could live with a mechanism that reserves the complete SCTP 
association, with all of its streams, as globally managed in a 
clue-specific way, as long as we can sort out the interop with webrtc.

	Thanks,
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Mar 2013 11:18:09 +0100

> clue-specific way, as long as we can sort out the interop with webrtc.

What I understand you can't really in the general case sort out the
WebRTC interoperability. WebRTC is after all a JavaScript specific usage
of a generic bi-directional multi-channel data transmission. Where the
generic bi-directional paradigm is realized using RTCWEB defined data
protocol. Clue could reuse that basic scheme but it would not make it
clear about will be on specific channels, that can be explicit or
implicit and depends on the WebRTC application.

It might be that certain usages becomes standardized and that we can
agree on labeling them and interconnect them with other systems. Doest
that need to happen in SDP. Don't think so. What I think will be
happening is that when you like to connect to a CLUE system using a
WebRTC supporting browser then you deploy a CLUE speaking JS, that will
use the data channel in a CLUE agreed way requiring minimal translation.
In fact the only adaptation is likely that the PeerConnection peer must
be capable of accepting peerConnections and interconnect them with a
CLUE system. In such system I don't see the WebRTC endpoint indicating
that it is CLUE interoperable, it is the CLUE JS APP plus the WebRTC to
CLUE gateway that ensures that this works. No changes to the WebRTC browser.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Mar 2013 11:21:22 +0100

> identifier doesn't change.

I am fine with this and it is likely the most pragmatic choice. However,
the current draft is not clear on the lower layer at all. If it adds
this and makes it clear on the handling I don't see an issue. Especially
as what ICE provides may not be UDP at all.

Cheers

Magnus Westerlund

---

From: Mary Barnes <[email-masked]>
Date: Fri, 22 Mar 2013 09:28:48 -0500

> CLUE gateway that ensures that this works. No changes to the WebRTC browser.

[MB] This is exactly how I was anticipating it to work for the most
part.  CLUE is defining a data model and from that I believe we can
extract the data relevant to the CLUE JS APP. I also don't see how we
could do it without a gateway. [/MB]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Mar 2013 23:58:28 +0800

> could do it without a gateway. [/MB]

I'm not certain if I agree with my co-chair or not. :-)

I do agree that clue-specific JS must be delivered to the browser. And 
so this calls for a webserver that can do that and knows it should. And 
in the webrtc-sip case that means the webserver must serve as a 
signaling gateway for sip.

I don't think this requires that there be a signaling gateway for the 
clue protocol. It ought to be possible for the clue protocol to be 
direct between the browser and the sip-clue endpoint. That in turn means 
that the SCTP association setup and channel usage must be identical 
between the SIP UA and the browser. The webserver can of course adjust 
the JS to arrange that to be the case. I suppose it can arrange for the 
SCTP m-line to reference "clue" when talking to the sip server, while 
the SDP interface in the browser says "webrtc" for that.

This isn't the way I would *like* to be signaling SCTP usage in SIP/SDP, 
but I can live with it. Perhaps it is better to work on the taxonomy 
document before doing more. (I think we should at some point include 
SCTP associations and streams/channels in the taxonomy.)

	Thanks,
	Paul