Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-02.txt

From: [email-masked]
Date: Mon, 22 Oct 2012 12:07:54 -0700

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 Working Group of the IETF.

	Title           : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)
	Author(s)       : Salvatore Loreto
                          Gonzalo Camarillo
	Filename        : draft-ietf-mmusic-sctp-sdp-02.txt
	Pages           : 13
	Date            : 2012-10-22

Abstract:
   SCTP (Stream Control Transmission Protocol) is a transport protocol
   used to establish associations between two endpoints.  This document
   describes how to express media transport over SCTP in SDP (Session
   Description Protocol).  This document defines the 'SCTP', 'SCTP/DTLS'
   and 'DTLS/SCTP' protocol identifiers for SDP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-02

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

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 24 Oct 2012 09:05:20 +0300

Hi there,

I have updated the draft trying to capture the result of the discussion 
we had in this mailing list
writing down for SCTP a <fmt> syntax similar to that used for RTP,
i.e. with "channle numbers" being used in a way analogous to payload 
type numbers.

The proposal is a very first attempt to see if this is the direction we 
want to go
and it is obviously incomplete lacking the possibility to define
all the properties of the specific channel...

feedback and comments are very welcome and necessary at this point

best regards
Salvatore

On 10/22/12 10:07 PM, [email-masked] wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Oct 2012 11:46:36 -0400

Salvatore,

IMO the new version is going in a good direction. But it does lead me to 
a number of additional questions:

- there is going to be a need to work out the offer/answer rules.
   It is currently just touched upon wrt a=setup and a=connection.
   But what are the rules for channel numbers in offers and
   answers, as well as a=streams and a=datachannel in offers and
   answers? Must the channel number be present in both offer and
   answer to be used?

- the mention of both uni- and bi-directional data channels seems good.
   But how is a decision made whether a channel is uni- or bi-
   directional? Is it fixed based on the channel type? Or is it
   negotiated via O/A? (RTP also effectively has this distinction,
   though not clearly defined. It is negotiated via O/A. But it is
   negotiated for the entire m-line, not just for a single payload type.)

   I guess I would prefer that this be settled via O/A. Perhaps
   a=datachannel:n defines what you want to *receive* on the datachannel.
   If there is none, then you don't want to receive, so it's uni-
   directional. If present and has the same datachannel type in both
   O/A then it is bi-directional. If it is present in both O/A but
   channel type is different on two sides then it's two uni-directional
   streams.

- How do datachannel numbers map to stream numbers? It would be
   convenient if they mapped 1:1 so no further syntax was needed.
   That could work well for bi-directional channels, and for uni-
   directional channels that all point the same direction. But when
   there are uni-directional channels in each direction do we want
   to require that the number in the reverse direction be "wasted"?

   In spite of the potential "waste", I guess I prefer the 1:1
   mapping for simplicity.

- what are the assumptions/rules for streams within the limit that
   don't have negotiated datachannel numbers? Are they free to be
   used for unspecified purposes? If so, then what happens if a
   subsequent O/A reuses the connection and adds another datachannel
   number corresponding to a stream already in use?

- There is currently a statement that every channel number that is
   listed MUST be used. Why? What does that mean? What if I have
   nothing to send? Or does it just mean that the receiving end
   must be prepared to receive on that channel?

- the syntax of the datachannel attribute is inconsistent with the
   examples. It makes no provision for the datachannel type or
   the "label" and "options" parameters shown.

- What are the semantics of the datachannel type? Open issue 2
   talks about registering RTCWeb. But what would be in that
   registration? Assuming this is to follow the model for RTP,
   and the examples, then it would be mime type "application/rtcweb"
   that is registered, and that should define the message format for
   messages on the channel. But my understanding of the intended
   use of datachannels in RTCWEB tells me that the message format
   for datachannels will vary. (Or is there a common "wrapper"
   type for all data in RTCWEB channels?)

- Also for datachannel type: If the RTP pattern is followed, so
   that the mime type is formed from the <media> of the m-line
   and the datachannel type from the a=datachannel line, then every
   channel of the SCTP connection must have the same top level
   mime type. (All "application", or "audio", etc.) This is similar
   to the problem being confronted in
   draft-holmberg-mmusic-sdp-mmt-negotiation. There the solution is
   to introduce a *special* <media> value ("anytype") and then another
   attribute (a=mmtype) to specify the <media> type on a per-payload
   number basis. Presumably the same solution could be used here.

So many questions, so little time. :-)

	Thanks,
	Paul