At 10:42 AM -0500 2/22/17, Dale R. Worley wrote:
Gunnar Hellström <gunnar(_dot_)hellstrom(_at_)omnitor(_dot_)se> writes:
A. Call failure
If a call fails due to no available language match, in what way(s)
does it fail? Section 5.3 says
If such an offer is received, the receiver MAY
reject the media, ignore the language specified, or attempt to
interpret the intent
But I suspect it's also allowed for the UAS to fail the call at the
SIP level. Whether or not that is allowed (or at least envisioned)
should be described. And what response code(s)/warn-code(s) should
be used for that?
The text you quote has been deleted. The draft does not mandate if
the call should proceed or fail if there is no language match
possible, although the draft does provide an optional mechanism to
indicate the caller's preference that the call not fail, and the draft
does mention that in the emergency services case, the call will likely
proceed, but that's a matter of policy not protocol.
You may have a version where it is proposed that the text is deleted. We
need to see that new text and agree if it was good to delete it.
There are more places in the draft where failing the call is mentioned,
so the question about how it is failed is relevant anyway. A 603 Decline
from the proxy would likely be the natural way to fail the call when it
is because of lack of matching languages. But I do not see any natural
way for an addressed UA to signal this.
I would argue strongly against using a 6xx response, as the defined
effect of those is to make the call fail all the way back to the
caller, rather than allowing alternative forks of the call to possibly
succeed. The way to handle a call that *this* proxy can't route due to
language incompatibility is a 4xx response.
My question wasn't for the draft to be prescriptive on this issue (and
that seems to align with what the WG/authors intend), but to provide
implementation advice, best practices as it were -- There are a lot 4xx
responses available, and if you don't read their descriptions carefully,
it can be easy to choose one with the wrong semantics. E.g., a 415
response is "Unsupported Media Type", but it's not for unsupported media
in the *session* (i.e., the SDP), it's for unsupported media in the
*INVITE body* (i.e., you can't process application/sdp).
OK, here it is: RFC 3261 section 13.3.1.3:
A UAS rejecting an offer contained in an INVITE SHOULD return a 488
(Not Acceptable Here) response. Such a response SHOULD include a
Warning header field value explaining why the offer was rejected.
section 21.4.26:
21.4.26 488 Not Acceptable Here
The response has the same meaning as 606 (Not Acceptable), but only
applies to the specific resource addressed by the Request-URI and the
request may succeed elsewhere.
A message body containing a description of media capabilities MAY be
present in the response, which is formatted according to the Accept
header field in the INVITE (or application/sdp if not present), the
same as a message body in a 200 (OK) response to an OPTIONS request.
and section 21.6.4:
21.6.4 606 Not Acceptable
The user's agent was contacted successfully but some aspects of the
session description such as the requested media, bandwidth, or
addressing style were not acceptable.
A 606 (Not Acceptable) response means that the user wishes to
communicate, but cannot adequately support the session described.
The 606 (Not Acceptable) response MAY contain a list of reasons in a
Warning header field describing why the session described cannot be
supported. Warning reason codes are listed in Section 20.43.
And my memory was correct; a Warning header is appropriate in a 488
response. Section 20.43 gives the details; it looks like a warn-code in
the range 390-398 is appropriate, or perhaps 300-329. It seems like the
choice should be either 308 or 390, the first available codes in those
ranges. And the ideal message text would contain the list of compatible
languages:
Warning: 308 proxy.example.com "Supported languages are: es, en"
The registration would be something like:
308 Incompatible language specification: No requested [this RFC]
language is supported and offerer requested failure.
The text should include the list of supported languages.
Thanks, Dale. It seems that it would be useful
for the draft to suggest (not require) that a
session rejected due to lack of
mutually-supported languages use 488 or 606, and
also include a Warning header field with the
suggested 308 code that the draft would register.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
We are what we repeatedly do. Excellence, then, is not an act but a habit.
--Aristotle