Subject: [MMUSIC] T140: Usage of "-"fmt value in dcsa encapsulated fmtp attribute

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Dec 2019 19:12:15 +0000

Hi,

When the chairs reviewed the T.140 data channel usage draft, the following issue was raised:

Currently, when we send an fmtp attribute encapsulated in a dcsa attribute, we use "-" as the fmt value.

     Example: a=dcsa:2 fmtp:- cps=20

However, 4566bis says the following about the fmtp attribute:

"The format must be one of the formats specified for the media."

Now, the format is 'webrtc-datachannel', so one could claim that should be used.

     Example: a=dcsa:2 fmtp:webrtc-datachannel cps=20

 But, that applies to the whole SCTP association, and the dcsa attribute is associated with a specific data channel usage. In addition, the usage and syntax of the fmtp attribute may vary depending on data channel usage.

Another option could be to include the sub-protocol:

     Example: a=dcsa:2 fmtp:t140 cps=20

But, the dcsa attribute already maps the fmtp attribute to the sub-protocol.

So, what to do?

My personal suggestion would be to keep "-", and perhaps add a note somewhere. Not sure we would need to update 4566bis, but if people want to do that we could for sure do it.

Anyone having a different opinion?

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 13 Dec 2019 11:05:07 +0000

Hi,

It seems to me that the solution for the "fmt" value definition might be found in sdpneg

In sdpneg section 5.2.1

https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#section-5.2.1

It is said:

 "There may be cases, where the usage of a subprotocol related media
   level attribute depends on the subprotocol's transport protocol.  In
   such cases the subprotocol related usage of the attribute is expected
   to be described for the data channel transport.  A data channel
   specific usage of a subprotocol attribute is expected to be specified
   in the same document that registers the subprotocol's identifier for
   data channel usage as described in Section 9.1<https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#section-9.1>. "

In t140-usage, section4.2.1,
https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-10#section-4.2.1
we have this sentence:
   'If the 'fmtp' attribute is included, the 'format' attribute parameter
   MUST be set to "-". '

It seems to me that the t140-usage draft by that fulfills the requirements of sdpneg and we are fine with fmt=-
Maybe we could even say that for the t.140-data-channel, "fmt" MUST be ommitted, in order to get a simpler syntax (?).

However,

This issue may also relate to the definition of "fmt" in rfc4566bis
 https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-37#section-8.2.3
where we have the following sentences that seem to apply:
"For other protocols, formats MAY be registered according to the rules
   of the associated "proto" specification.

   Registrations of new formats MUST specify which transport protocols
   they apply to."

I have not traced if we are bound to that requirement for dcsa definitions, and how it would map from protocol to sub-protocol, so I hope we can obey sdpneg.

Summary: I would suggest to omit "fmt", or keep fmt=- and claim that the use of fmt is defined in t140-usage as required by sdpneg.

Regards
Gunnar

Den 2019-12-12 kl. 20:12, skrev Christer Holmberg:
Hi,

So, what to do?

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

--

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Dec 2019 11:50:38 +0000

Hi,

>   data channel usage as described in https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#section-9.1. "
>
>   'If the 'fmtp' attribute is included, the 'format' attribute parameter MUST be set to "-". '

The text above is what triggered the discussion :)

> Summary: I would suggest to omit "fmt", or keep fmt=- and claim that the use of fmt is defined in t140-usage as required by sdpneg.

We DO define the usage as required by sdpneg,  so that is not the issue. 

The question is whether it in such definition is allowed to "override" the 4566bis statement saying that the format must be one of the formats specified for the media. As far as SDP is concerned, the only format is 'webrtc-datachannel'.

Again, I personally think we should keep "-" (I don't like to omit information elements), and add whatever text needed to indicate that the 4566bis text does not apply to sub-protocol specific fmtp attributes.

Regards,

Christer

So, what to do?

Regards,

Christer

mailto:[email-masked]

Gunnar Hellström
Omnitor
mailto:[email-masked]
+46 708 204 288

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 13 Dec 2019 15:05:03 -0500

> Again, I personally think we should keep "-" (I don't like to omit information elements), and add whatever text needed to indicate that the 4566bis text does not apply to sub-protocol specific fmtp…

Syntactical consistency and strict adherence to the wording in 4566bis 
would argue for "webrtc-datachannel", whereas conceptual consistency 
would argue more for "t140". I'm not in favor of "-", since it doesn't 
seem to add anything.

Thanks

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Dec 2019 20:30:26 +0000

Hi,

...

>>> The question is whether it in such definition is allowed to "override" the 4566bis statement saying that the format
>>> must be one of the formats specified for the media. As far as SDP is concerned, the only format is 'webrtc-datachannel'.
>>
>> Again, I personally think we should keep "-" (I don't like to omit information elements), and add whatever text needed to
>> indicate that the 4566bis text does not apply to sub-protocol specific fmtp attributes.
>
> Syntactical consistency and strict adherence to the wording in 4566bis would argue for "webrtc-datachannel", 
> whereas conceptual consistency would argue more for "t140". I'm not in favor of "-", since it doesn't seem to add anything. 

There is nothing to add, and that's why we are using "-" to indicate that. I believe there are cases where we use "-" for the fmt in the m= line, aren't there?

Having said that, if the community prefers "webrtc-datachannel" I can live with that. I think it is a waste of characters, but the ship to keep SDP bodies small and compact sailed a long time ago, so... :)

Regards,

Christer

So, what to do?

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 13 Dec 2019 22:01:07 +0000

Hi,

Den 2019-12-13 kl. 21:30, skrev Christer Holmberg:

Hi,

...

I found the permission last in sdpneg section 5.2.1 to override what is specified for fmtp and fmt in RFC4566bis.

 "If
   existing media attributes are used in a datachannel subprotocol
   specific way, then a new dcsa usage level MUST be defined for the
   existing media attribute.  Where the SDP attribute is applicable to a
   particular subprotocol/s this SHALL also be registered by indicating
   the applicable subprotocol identifiers (see
   /[I-D.ietf-mmusic-rfc4566bis<https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#ref-I-D.ietf-mmusic-rfc4566bis>] section-8.5) along with the dcsa usage
   level."

The use of fmtp is specified and registered in t140-usage draft section 9.2 as required.
Maybe the specific syntax of fmt=- should be mentioned in the registration (?).

Regards

Gunnar

Regards,

Christer

So, what to do?

Regards,

Christer

--

Gunnar Hellström
Omnitor

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Dec 2019 18:27:42 -0500

> Having said that, if the community prefers "webrtc-datachannel" I can live with that. I think it is a waste of characters, but the ship to keep SDP bodies small and compact sailed a long time ago,…

IMO using "webrtc-datachannel" would be wrong and confusing.

Using the subprotocol would make sense, but is then redundant. Using "-" 
seems reasonable to me.

	Thanks,
	Paul

> [email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 15 Dec 2019 10:52:17 +0000

Den 2019-12-13 kl. 21:05, skrev Flemming Andreasen:

Hi,

In sdpneg section 5.2.1

However,

Syntactical consistency and strict adherence to the wording in 4566bis would argue for "webrtc-datachannel", whereas conceptual consistency would argue more for "t140". I'm not in favor of "-", since it doesn't seem to add anything.
I tend to lean towards "t140" now, even if it does not add any information.
We could, if needed, draw a map of how different statements in rfc4566bis, sdpneg and t140-usage relate to this topic, and probably find that there is a bit of inconsistency.
But,
RFC4566bis, section 8.2.3
https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-32#section-8.2.3
says for protocols other than rtp and udp

"   For other protocols, formats MAY be registered according to the rules
   of the associated "proto" specification.

sdpneg intends to map dcmap and dcsa into a kind of second level media section,

and in turn hands over to the specific subprotocol specifications to tell how attributes are defined and used.

In t140-usage, section 9.2, the use of the fmtp attribute is registered and a reference to section 4.2.1 made. And in 4.2.1, the rule for fmt is defined.
https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-10#section-9.2

A question is if the fmt parameter value ( "-" or "t140" ) would need to be registered since RFC4566bis says that new formats MAY be registered, or if that requirement is satisfied by the description of the use of "-" in the fmtp attribute in t140-usage section 4.2.1.

If we think that this is too complex, we could get around the problem by instead defining a new value "cps", specified in a dcsa attribute.

/Gunnar

Thanks

-- Flemming

Regards,

Christer

So, what to do?

Regards,

Christer

--

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Dec 2019 10:49:09 +0000

Hi,

…

>> The question is whether it in such definition is allowed to "override" the 4566bis statement saying
>> that the format must be one of the formats specified for the media. As far as SDP is concerned, the
>> only format is 'webrtc-datachannel'.
>>
>> Again, I personally think we should keep "-" (I don't like to omit information elements), and add whatever text
>> needed to indicate that the 4566bis text does not apply to sub-protocol specific fmtp attributes.
>
> We could, if needed, draw a map of how different statements in rfc4566bis, sdpneg and t140-usage relate
> to this topic, and probably find that there is a bit of inconsistency. 
>
> But, RFC4566bis, section 8.2.3 
> ays for protocols other than rtp and udp
>
> " For other protocols, formats MAY be registered according to the rules of the associated "proto" specification.
>    Registrations of new formats MUST specify which transport protocols they apply to."

Yes, but I think that relates more to the 'webrtc-datachannel' value.

> A question is if the fmt parameter value ( "-" or "t140" ) would need to be registered since RFC4566bis says that new formats MAY be registered, or if that 
> requirement is satisfied by the description of the use of "-" in the fmtp attribute in t140-usage section 4.2.1.

That doesn't solve the generic problem, because in future there might be other data channel usages using the fmtp attribute.

Also, I think we should aim at being aligned with the RTP usage when it comes to SDP attributes.

Regards,

Christer

So, what to do?

Regards,

Christer

-- 

Gunnar Hellström
Omnitor

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 16 Dec 2019 10:34:22 -0500

> Yes, but I think that relates more to the 'webrtc-datachannel' value.
Agreed.
> Also, I think we should aim at being aligned with the RTP usage when it comes to SDP attributes.
Agreed again. I think the "fmtp" attribute is the right one to use here 
- the question is simply what format value we use. I'm leaning towards 
"t140", but we should get some general text in sdpneg to account for 
additional media formats in the future.

It would be good to hear from more people on this.

Thanks

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Dec 2019 10:57:35 -0500

> additional media formats in the future.

IIUC you are proposing that the format value in fmtp attributes for data 
subchannels should be the subchannel identifier. Is that right?

While that is redundant I won't oppose that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Dec 2019 16:05:51 +0000

Hi,

I'd be ok with the subchannel identifier.

I do think it would be good to add some generic text to sdpneg, though, saying that whenever the media description format or PT number would normally be used in an attribute (e.g., the fmtp attribute), when encapsulated in a dcsa attribute the subchannel identifier is used instead.

Regards,

Christer

On 16/12/2019, 17.58, "mmusic on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    

    	Thanks,
    	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Dec 2019 11:09:58 -0500

> I do think it would be good to add some generic text to sdpneg, though, saying that whenever the media description format or PT number would normally be used in an attribute (e.g., the fmtp attribu…

+1

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Dec 2019 19:23:30 +0000

Roni, note that this impacts you.

Regards,

Christer

On 16/12/2019, 18.10, "mmusic on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    +1

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 17 Dec 2019 22:23:00 -0500

On 12/16/19 10:57 AM, Paul Kyzivat wrote:
>> Agreed again. I think the "fmtp" attribute is the right one to use 
>> here - the question is simply what format value we use. I'm leaning 
>> towards "t140", but we should get some general text in sdpneg to 
>> account for additional media formats in the future.
>
> IIUC you are proposing that the format value in fmtp attributes for 
> data subchannels should be the subchannel identifier. Is that right?
That's right.

-- Flemming
> .

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 17 Dec 2019 22:23:55 -0500

On 12/16/19 11:09 AM, Paul Kyzivat wrote:
>> I do think it would be good to add some generic text to sdpneg, 
>> though, saying that whenever the media description format or PT 
>> number would normally be used in an attribute (e.g., the fmtp 
>> attribute), when encapsulated in a dcsa attribute the subchannel 
>> identifier is used instead.
>
> +1
Agreed as well.

-- Flemming
>
>> Regards,
>>
>> Christer
>>
>>
>> On 16/12/2019, 17.58, "mmusic on behalf of Paul Kyzivat" 
>> <[email-masked] on behalf of [email-masked]> wrote:
>>
>>           >> Also, I think we should aim at being aligned with the 
>> RTP usage when it comes to SDP attributes.
>>      > Agreed again. I think the "fmtp" attribute is the right one to 
>> use here
>>      > - the question is simply what format value we use. I'm leaning 
>> towards
>>      > "t140", but we should get some general text in sdpneg to 
>> account for
>>      > additional media formats in the future.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 18 Dec 2019 10:01:51 +0000

Den 2019-12-18 kl. 04:23, skrev Flemming Andreasen:

+1
Agreed as well.

-- Flemming

Yes, but not mentioning that the media description format or PT would be normal, because already rfc4566bis section 8.2.2 recognizes that fmt in the media line may be something different for other protocols than rtp and udp:

And also rfc4566bis section 5.14 about the media line does the same:

"

      For media using other transport protocols, the <fmt> sub-field is
      protocol specific.  Rules for interpretation of the <fmt> sub-
      field MUST be defined when registering new protocols (see
      Section 8.2.2<https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-32#section-8.2.2>)."

"

In rfc4566bis, section 6.15, fmtp is specified, and there "fmt" is used for the format value and it is said:

"
The format must be one of the formats specified for the media.

draft-ietf-mmusic-sctp-sdp correctly registers webrtc-datachannel as a valid value for fmt.

So far, this applies to the real media section directly in sdp

Now, sdpneg seems to create a second level of media sections multiplexed on the webrtc-datachannel format,
with some m-line contents in the dcmap attribute and the sdp attributes of the second level media section in the dcsa attributes.

I think that sdpneg might need to recognize this mapping from DCMAP and DCSA to a "simulated" media section more clearly.
Otherwise, the statement about fmtp in rfc4566bis "The format must be one of the formats specified for the media." will seem to be obstructed by sdpneg.

So, the mapping from media section to sdpneg parameters would be:

 m=<media> <port> <proto> <fmt> ...
<media> - undefined.
<port> - from DCMAP <port> parameter
<proto> - webrtc-datachannel
<fmt>   - from DCMAP <subprotocol> parameter     (only one allowed )

 a=<attribute>:<value>

<attribute>:<value> - from DCSA <attribute> parameter

Then the mapping from <subprotocol> to <fmt> for fmtp would follow automatically.

There are traces of this thought in sdpneg.

sdpneg recognizes that usage of attributes may need to be different when applied to a WebRTC data channel with the following insection 5.2.1:

"

 There may be cases, where the usage of a subprotocol related media
   level attribute depends on the subprotocol's transport protocol.  In
   such cases the subprotocol related usage of the attribute is expected
   to be described for the data channel transport.  A data channel
   specific usage of a subprotocol attribute is expected to be specified
   in the same document that registers the subprotocol's identifier for
   data channel usage as described in Section 9.1<https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#section-9.1>.

   SDP attributes that are only defined for use at the dcsa usage level,
   SHALL use the dcsa usage level when registering the attribute.  If
   existing media attributes are used in a datachannel subprotocol
   specific way, then a new dcsa usage level MUST be defined for the
   existing media attribute.  Where the SDP attribute is applicable to a
   particular subprotocol/s this SHALL also be registered by indicating
   the applicable subprotocol identifiers (see
   /[I-D.ietf-mmusic-rfc4566bis<https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#ref-I-D.ietf-mmusic-rfc4566bis>] section-8.5) along with the dcsa usage
   level.

"

It might be sufficient to add a sentence in this area, saying something like:

"The fmt parameter in dcsa attributes shall have the same value as the subprotocol in the corresponding DCMAP attribute."

Or a more thorough description of the mapping of the media section as described above.

Will there be a need to IANA - register the use of each subprotocol as belonging to the namespace of <fmt> for the webrtc-datachannel protocol to be true to the registering requirements from rfc4566bis?

Regards

Gunnar

Regards,

Christer

On 16/12/2019, 17.58, "mmusic on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]><mailto:[email-masked]@alum.mit.edu> wrote:

--

Gunnar Hellström
Omnitor