Subject: [MMUSIC] Questions on draft-ietf-mmusic-sctp-sdp-05

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Jan 2014 11:36:15 +0000

Hi,

Section 5.1 of draft-ietf-mmusic-sctp-sdp-05 describes how an offered SCTP association can be rejected, by in the Answer setting the port value in the associated SDP sctpmap attribute to zero.

Q1:         When an SCTP association is rejected, shall the associated port value in the m- line fmt list also be set to zero? The text only talks about the sctpmap attribute.

The draft does not talk about subsequent offers.

Q2:         Do I need to include all sctpmap attributes in subsequent offers, even if some are associated with previously rejected STCP associations, in order to maintain the order?

Q3:         Can I, in a subsequent offer, remove an SCTP association by setting the associated port value to zero? If so, do I set the port value to zero in the associated sctpmap attribute, and/or the m- line fmt list?

The draft only talks about having a single media-subtype per SCTP association.

Q4:         Is it possible to define multiple media-subtypes per SCTP association?

                Example:

                m=application 54111 DTLS/SCTP 5000
              c=IN IP4 79.97.215.79
              a=sctpmap:5000 webrtc-datachannel 16
              a=sctpmap:5000 bfcp 2
              a=sctpmap:5000 t38 1

                (Each media-subtype could use different SCTP streams within the SCTP association)

Thanks!

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 Jan 2014 15:24:35 +1100

Hello,

Not an answer but a further question related to Q4.
Is it possible to have several of the same media-subtypes per SCTP 
association?
  i.e.         a=sctpmap:5000 webrtc-datachannel 16
               a=sctpmap:5001 bfcp 2
               a=sctpmap:5002 bfcp 1

I think it has been pointed about before but the media-subtypes ABNF is 
incomplete.

The draft also indicates that the use of existing MIME subtypes for the 
media-subtype format is encouraged. I assume this means the use of one 
of the values from the IANA media type registry 
<http://www.iana.org/assignments/media-types/media-types.xhtml>? If so 
then "bfcp" is not a registered type there. However T38 (audio or image) is.

draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 also uses BFCP and 
MSRP. It mentions these in terms of "sub-protocol" which I assume more 
relates to the proto field at 
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2. 
However BFCP and MSRP are not individual values there either and it 
doesn't define t38.

I couldn't find the rtcweb draft that proposes to register 
webrtc-Datachannel in either of the above registries.

I saw draft-ejzak-dispatch-webrtc-data-channel-sdpneg proposing a 
a=webrtc-Datachannel attribute. I thought SDP attributes needed a static 
name (i.e. so it can be registered by IANA). In cl.4.3 of the draft it 
appears that the attribute name is based on the "protocol" in the 
sctpmap. However this would imply a dynamic allocation of attribute names.

I'm confused. Can any one clarify what the media-subtype is meant to be?

Regards,
Christian

On 27/01/2014 10:36 PM, Christer Holmberg wrote:
>
> Hi,
>
> Section 5.1 of draft-ietf-mmusic-sctp-sdp-05 describes how an offered 
> SCTP association can be rejected, by in the Answer setting the port 
> value in the associated SDP sctpmap attribute to zero.
>
> *Q1:*         When an SCTP association is rejected, shall the 
> associated port value in the m- line fmt list also be set to zero? The 
> text only talks about the sctpmap attribute.
>
> *Q2:*         Do I need to include all sctpmap attributes in 
> subsequent offers, even if some are associated with previously 
> rejected STCP associations, in order to maintain the order?
>
> *Q3:*         Can I, in a subsequent offer, remove an SCTP association 
> by setting the associated port value to zero? If so, do I set the port 
> value to zero in the associated sctpmap attribute, and/or the m- line 
> fmt list?
>
> *Q4*:         Is it possible to define multiple media-subtypes per 
> SCTP association?
>
>                 Example:
>
>                 m=application 54111 DTLS/SCTP *5000*
>
>               c=IN IP4 79.97.215.79
>
>               a=sctpmap:*5000* webrtc-datachannel 16
>
>               a=sctpmap:*5000* bfcp 2
>
>               a=sctpmap:*5000* t38 1
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Jan 2014 00:11:57 -0500

>   i.e.         a=sctpmap:5000 webrtc-datachannel 16

AFAICT this should be ok.

BUT, I find associating a media subtype with an sctp association 
nonsensical. Each association represents a set of independent channels. 
What sense does it make to associate a media sub-type with set of 
channels? The existing media subtypes, such as bfcp, are are intended to 
be mapped onto a packet stream, such as you get with UDP or RTP.

A "type" that is associated with an sctp association ought to describe a 
particular usage of a *set* of packet streams, or channels. That is a 
very different sort of thing.

> However BFCP and MSRP are not individual values there either and it

There are a lot of details to iron out, but at least the ejzak draft is 
independently declaring the data type per channel within an association.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2014 07:23:44 +0000

Hi,

>   i.e.         a=sctpmap:5000 webrtc-datachannel 16

As the port values are different, aren't you using two DIFFERENT SCTP associations in the example?

Section 4.1 of the draft says:

	"Running SCTP over DTLS make possible to have multiple SCTP
   	associations on top of the same DTLS connection; each SCTP
   	association make use of a distinct port number that is mainly used to
   	demultiplex the associations."

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 Jan 2014 20:46:30 +1100

Hello Christer,

I guess then in my example there is different SCTP associations. I 
should have probably said the same media-subtype in several a=sctpmap 
attributes under the same m-line.

Christian