Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language

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

Den 2017-04-27 kl. 05:11, skrev Bernard Aboba:
> On Apr 26, 2017, at 14:15, Adam Roach <[e-mail]> wrote:
>> Given that the direction selected by the WG is to represent language values in SDP, I think this document can *either* say that routing is 100% out of scope and unaddressed, *or* it can add some SIP-level header fields that bear on routing according to human languages.
> [BA] Given that routing work is not in the current WG Charter, my suggestion would be for the current document to say it is out of scope. But it might also say that SIP-level header fields may be defined in future (if only to make it clear that the document is not suggesting SDP-based routing).
The charter is flexible about including routing aspects. It says:
"

  Alternatives such as doing the media
negotiation in SIP have been explored in the past and are out of scope
(although SIP-based mechanisms may be introduced when routing
considerations are addressed).

The group's initial focus will not be on supporting language-based call
routing decisions.  Once the initial work is sufficiently progressed, the
group may  address call routing, with the timing at the judgment of the
chairs.

"

I guess that  the work cannot be considered "sufficiently progressed" yet. So we should not deal with routing.
What we can do is to assume that an emergency service or call center application will put the call in an
appropriate queue just based on SIP fields, and the UAs that have language capabilities matching the indications
will answer.
However, I do not see how we can have a UA deciding if it has the best match among available UAs so that
it shall decide to answer the call.

Section 9.2 of RFC 6443 says: " To enable media-sensitive routing,
    the call should include a Session Description Protocol (SDP) offer
    [RFC3264 <https://tools.ietf.org/html/rfc3264>]."
So, there is an assumption that SDP can be interrogated to make routing decisions.

Can we just be silent about the routing aspects (as we are now) and assume that the
  media-sensitive routing mentioned in RFC 443 can be extended to "media and language based routing"?


Gunnar







-- ----------------------------------------- Gunnar Hellström Omnitor 
[e-mail]