Re: [Slim] SDP limitations

[Gunnar Hellström <[e-mail]>]

Den 2015-10-05 kl. 01:44, skrev Christian Groves:
> Hello Gunnar,
>
> It would be possible to "hook" the humanlang attributes to the 
> specific instance of the datachannel. You simply use the humanlang 
> tags in the dcsa attribute. The protocol is indicated via the 
> subprotocol element in the dcmap attribute. E.g.
>
>          m=application 911 <L4>/DTLS/SCTP webrtc-datachannel
>          c=IN IP4 11.9.19.65
>          a=max-message-size:1000 ;
>          a=sctp-port 5000
>          a=dcmap:1 label="text conversation";subprotocol="t140"
>          a=dcsa:1 cps=30  ; "the RFC4103 default value as example"
>          a=dcsa:1 humintlang-send:<language tag>
>          a=dcsa:1 humintlang-recv:<language tag>
(GH) Thanks for the good hint.
I tried to decode section 5.1.2 Sub-Protocol Specific Attributes in the 
data-channel-sdpneg draft to see if there is a need to specify somewhere 
that the lang and humintlang attributes are allowed in 
subprotocol="t140" environment. But I did not find the answer. The lang 
and humintlang attributes are not really subprotocol specific, even if 
there are SDP-media and data-subprotocols where they are meaningless. 
They are commonly useful in many stream specifications. So there is 
probably a need for another section in data-channel-sdpneg to tell about 
common attributes.
The idea is however clear and useful. Thanks.

That leaves us with a possibility to extend the use of lang and 
humintlang relatively easy into part of the WebRTC area.
It requires a bit more application awareness of the negotiation parser. 
On the traditional SIP side we have so far said that under m=text, we 
have language attributes for text streams, while now it must know also 
that under a dcmap with subprotocol="t140" lang and humintlang 
specifications talk about text streams.

It would help parsing a lot if we had an explicit way to differentiate 
written language from spoken language in the language tag itself. Can we 
revive that issue?

/Gunnar


>
> Regards, Christian
>
> On 3/10/2015 8:05 PM, Gunnar Hellström wrote:
>> The limitations of having the language indications in SDP is 
>> eternally popping up as a problem when planning its use.
>> I know that this has been discussed a lot in the past and that we 
>> have agreed to go the SDP path.
>>
>> But I want to question it again.
>> I got a reminder from reviewing the latest specification of real-time 
>> text in WebRTC.
>> https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-02 
>>
>>
>> There, the real-time text stream is a subchannel multiplexed in the 
>> WebRTC data channel, with sdp-specification m=application.
>> So, there is no m=text to hook our humintlang attributes on.
>>
>> It is quite likely that WebRTC terminals will be used in situations 
>> where language negotiation is desirable.
>> If we keep it under SDP, we would then need to define some mapping 
>> rules between languages for media not appearing under their original 
>> m= names.
>> A tempting alternative is to move the whole language indication to an 
>> XML block carried in a defined place, so that it can be reused in 
>> different environments.
>>
>> Gunnar
>>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim