Re: [Slim] SDP limitations

[Christian Groves <[e-mail]>]

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>

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
>