Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 10:42 AM -0500 2/22/17, Dale R. Worley wrote:

 Gunnar Hellström <gunnar.hellstrom@xxxxxxxxxx> 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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]