Re: [Slim] SDP limitations

Den 2015-10-04 kl. 05:37, skrev Bernard Aboba:
>>> 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.
> [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.
>
>>> 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.
> [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
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim