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

[Paul Kyzivat <[e-mail]>]

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

On 10/24/12 2:05 AM, Salvatore Loreto wrote:
> 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