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

On 12/16/19 5:49 AM, Christer Holmberg wrote:
> Hi,
>
> …
>
>>> 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.
>>>> 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
>> 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.
Agreed.
>
>> 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.
> 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.
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

> Regards,
>
> Christer
>
>
>
>
>
>
>
>
> Den 2019-12-12 kl. 20:12, skrev Christer Holmberg:
> 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
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mailto:mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>