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

[Christer Holmberg <[e-mail]>]

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.

> 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.

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:[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic

-- 

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

Gunnar Hellström
Omnitor
mailto:[e-mail]
[phone]