Subject: [Slim] SDP limitations

From: Gunnar Hellström <[email-masked]>
Date: Sat, 3 Oct 2015 12:05:33 +0200

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 3 Oct 2015 14:42:41 -0400

> XML block carried in a defined place, so that it can be reused in

This is not a unique issue here. It seems likely that individual data 
channels over sctp will start to be used in a variety of places where 
UDP is currently used.

See draft-ietf-mmusic-data-channel-sdpneg. In particular section 5.1.2.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 3 Oct 2015 20:37:02 -0700

>> where language negotiation is desirable.

[BA] If we are talking about a WEBRTC application talking over the data channel to a gateway that translates to RTT, the gateway can compose the m=text line to hang the humintlang attributes on.  The WEBRTC application need not speak SDP to the gateway to accomplish this, it just needs to provide the information the gateway needs to compose the m=text line and humintlang attributes. This could be in any desired format: JSON, XML, etc.

>> between languages for media not appearing under their original m= names.

[BA] The gateway would need such a mapping, but it is not clear to me why this application-specific signaling would need to be standardized.

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 4 Oct 2015 08:47:22 +0200

> [BA] The gateway would need such a mapping, but it is not clear to me why this application-specific signaling would need to be standardized.
[GH] It is the usual reasons to standardize. Development of different 
parts of a system can be distributed in time and between organizations. 
What is developed for one application can be reused in another. One part 
of a system can be based on one technology and another part on another 
technology. Application functions can be implemented relatively easily 
end - to - end even if the communicating partners have tools using 
different technologies. Application functions are of interest to the 
users, and can be discussed in general terms with the users and need not 
be limited by lack of specification for the function in one technology 
or between them.

In line with this reasoning is also my hope that what we do to now can 
have as wide scope as possible without extra efforts.
Many WebRTC applications are based on SIP and SDP.  So we could hope 
that the work was directly applicable for these cases, but it is not 
because the current idea relies on consistent media names in m-lines.

Other WebRTC applications use other methods, so you are right in that a 
language and modality indication in JSON or XML could have a wider scope 
than the one merged into the SDP media specifications.

Even within traditional SIP and SDP, we have media specifications that 
can contain different media. E.g. MSRP using m=message with a 
possibility to convey messages with audio, video, images and text. And 
there is SIP MESSAGE transmission without any SDP. These are not really 
real-time communication, so I have accepted that our work does not have 
them in scope. Our scope on the real-time side of slim has so far been 
real-time text, audio and video. But in our scope is also to satisfy RFC 
6881, and there is also messaging specified. There may be users who have 
not enabled real-time text but are used to text messaging, and want to 
use that in an emergency situation. These would also fall beside the 
implicit linking between m-line media names and media. Shall we bother 
about them?
This can be solved by a coding rule that makes an explicit difference 
between text and spoken modality, either in the language tags or in the 
attribute names. By that it would be clear what modality a humintlang 
attribute indicated even if it was hooked on to a media-agnostic media 
specification.

>    
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Christian Groves <[email-masked]>
Date: Mon, 5 Oct 2015 10:44:28 +1100

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

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 5 Oct 2015 08:47:53 +0200

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 5 Oct 2015 12:45:26 -0400

Christian,

>>          a=dcsa:1 cps=30  ; "the RFC4103 default value as example"

The above line can't be right. 'cps=30' doesn't conform to syntax of an 
attribute.

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 6 Oct 2015 00:39:28 +0200

Den 2015-10-05 kl. 18:45, skrev Paul Kyzivat:
> The above line can't be right. 'cps=30' doesn't conform to syntax of 
> an attribute.
Right, it is a subparameter in an fmtp attribute.  fmtp is not of 
interest to carry over to the WebRTC side. So it likely needs to be 
specifically specified as a native attribute in the dat channel subprotocol.

But that was not the point. It was that mapping of humintlang attributes 
to WebRTC RTT stream seem possible but it is no straightforward m=text 
to hook it on to on the WebRTC side.

---

From: Christian Groves <[email-masked]>
Date: Tue, 6 Oct 2015 10:39:53 +1100

Hello Paul,

On 6/10/2015 9:39 AM, Gunnar Hellström wrote:
> But that was not the point. It was that mapping of humintlang 
> attributes to WebRTC RTT stream seem possible but it is no 
> straightforward m=text to hook it on to on the WebRTC side.
[CNG] It was a cut and paste from 
draft-schwarz-mmusic-t140-usage-data-channel. I didn't look at that part 
of the syntax. As Gunnar said I was just illustrating the concept of 
using attributes associated with a data channel.

You're right though it doesn't conform. It probably should be something 
like a=dcsa:1 fmtp:- cps=30. I've cc'd Albrecht on this.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 6 Oct 2015 19:26:03 +1100

Hello Albrecht,

Thanks must go to Paul for catching the fmtp one.

Christian

On 6/10/2015 6:34 PM, Schwarz, Albrecht (Albrecht) wrote:
> Thanks for spotting the "a=dcsa" issue Christian!
>
> Will request MMUSIC to adopt
> draft-schwarz-mmusic-t140-usage-data-channel
> as WG draft and reply on the question below at MMUSIC.
> Its an MMUSIC item and not SLIM in my understanding.
>
> Regards,
> Albrecht
>
>
> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Dienstag, 6. Oktober 2015 01:40
> To: [email-masked]
> Cc: Schwarz, Albrecht (Albrecht)
> Subject: Re: [Slim] SDP limitations
>
> Hello Paul,
>
> draft-schwarz-mmusic-t140-usage-data-channel. I didn't look at that part of the syntax. As Gunnar said I was just illustrating the concept of using attributes associated with a data channel.
>
> You're right though it doesn't conform. It probably should be something like a=dcsa:1 fmtp:- cps=30. I've cc'd Albrecht on this.
>
> Regards, Christian