Re: [MMUSIC] Notes from Orlando human language draft discussion

[Bernard Aboba <[e-mail]>]

Gunnar said: 
> This could first lead to an effort to route the call to an endpoint that 
> has declared more suitable language and modality preferences and 
> capabilities.
[BA] The call routing aspect is probably best handled via SIP headers, just as in RFC 6442 we define the Geolocation and Geolocation-Routing Headers.   
> Secondly it can lead to addition of a relay service or translation 
> service if one of the parties has access to such services. It can be 
> added in a three-party call fashion, translating languages or modalities 
> as needed.
[BA] The SIP headers might lead to the call being routed to an endpoint that supports the desired servicesnatively, or it might not.  The O/A exchange will disclose whether the desired services are available, or not. It could be that an entity indicating a language capability in its Answer might have them available on site, ormight have to call out to obtain them, but that doesn't matter to the Offerer as long as they can be deliveredby the Answerer.  On the other hand, if the Answerer doesn't have the required services, the Offerer mightdecide to add them on its own, by making another call to a relay or translation service, possibly joining thatcall to the initial one. 
> If the one who is not using the mechanism is declaring audio and text 
> media capabilities, it will be harder to select what to do.
> The one supporting the mechanism may prefer to use sign language. Having 
> no indication why the other party declares video capability, it may be 
> risky to just connect them.
[BA] I agree. Just because a party declares capabilities doesn't necessarily mean that they are able to use them in the manner that is needed.  Just from an indication of the supported media (e.g. video, text, audio) you won't know if the Answerer supports ASL interpretation, or whether they're trained and willing to transcribe audio to text and back. So it's probably best if support for these services is made explicit. 
>    So, yes, there are many use case variations that need to be captured 
> and best approach described.

[BA] It seems to me that what is needed is a set of tools that can be combined in different ways to address the different use cases.  The tools can include SIP headers, SDP negotiation, and call control functionality.  Once you have the tools, you can describe how different use cases can be addressed using them.