lost: lost_held_dereference do not handles error message

[sergey-safarov]

Description

When LIS server failed, then LIS send a message like

   The error response to the request is an error document.  The
   following response shows an example error response.

         HTTP/1.1 200 OK
         Server: Example LIS
         Expires: Tue, 10 Jan 2006 03:49:20 GMT
         Cache-control: private
         Content-Type: application/held+xml;charset=utf-8
         Content-Length: 182

         <?xml version="1.0"?>
         <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
            code="locationUnknown">
           <message xml:lang="en">Unable to determine location
           </message>
         </error>

Here is HTTP code is 200.
lost_held_dereference now simply check HTTP code and do not check XML body.

Expected XML content check for:

1. XML HELD error message
2. check locationResponse/presence element check if HELD request geodetic or civic;
3. check locationResponse/locationUriSet/locationURIpresence if HELD request locationURI..

This check is important because PIDF-LO object may be added to the multipart body. And HELD XML error handling prevents error message addition as PDF-LO object.

[wkampich]

Thanks, actually this was a small error that affected almost every lost function. The error variable was set to 0 before return, and thus there was no error ode returned. The fix (committed to master) now returns 500 in case of error (error code/string of the response is found in pvar/err) and otherwise 200, 201, 202, or 203. 200 neither pidf-lo nor reference, 201 pidf-lo, 202 url, 203 pidf-lo and url found in the response. Please verify using the latest commit.

[wkampich]

@sergey-safarov: Just seen that it may be better to change the response codes as follows: 200 neither pidf-lo nor reference, 201 url, 202 pidf-lo, 203 pidf-lo and url found in the response - so anything >201 returns a pidf-lo and could be added to the multipart body. If you find it useful, I'll change it. Actually 200 should never occur (kept it just in case there might be other content returned in a 200 OK) - if an error message is returned in a 200 OK the return code is set to 500.

[sergey-safarov]

Generally LIS code and error message also important for error handling. Error code may be used for switch statement and a message for log description for humans.
Here examples of LIS error messages
from RFC

<?xml version="1.0"?>
  <error xmlns="urn:ietf:params:xml:ns:geopriv:held" code="locationUnknown">
    <message xml:lang="en">Unable to determine location
  </message>
</error>

my use case

<?xml version="1.0" encoding="UTF-8"?>
<urn:error xmlns:urn="urn:ietf:params:xml:ns:geopriv:held" code="generalLisError">
  <urn:message>An unspecified error occurred while handling LocationRequest.</urn:message>
</urn:error>

So I can use a switch statement like

if ($var(res) == 200 && $var(res) > 203 ) {
  switch $(varLisErrorCode) {
    case "locationUnknown":
      xlog(L_ERR, "Received LIS error response: $(varLisErrorMessage)");
      route(TRY_DEFAULT_PSAP);
    case "generalLisError":
      xlog(L_ERR, "Received unexpected LIS error response: $(varLisErrorMessage)");
      route(TRY_OTHER_LOCATION_METHOD);
    default:
  }
}

For me more preferable to define module param xavp_responce

modparam("lost", "xavp_responce", "held_responce")

If xavp_responce defined then set keys.

1. HTTP_ERROR_CODE;
2. HELD_ERROR_CODE;
3. HELD_ERROR_MESSAGE.

If returned HTTP code 200 and XML that cannot be parsed then set HELD_ERROR_CODE to badHeldResponce and HELD_ERROR_MESSAGE to Returned HELD response cannot be parsed.

[sergey-safarov]

As an option, we can set HELD_ERROR_CODE for normal HELD response and use Kamailio config like

  modparam("lost", "xavp_responce", "held_responce")
...
  lost_held_dereference("$(var(url){s.unbracket})", "emergencyDispatch", "civic geodetic", "$var(pidf)", "$var(err)");
  switch ($xavp(held_responce[0]=>HELD_ERROR_CODE)) {
    case "responceWithPresence":
      route(ADD_LOCATION_BY_VALUE);
    case "responceWithLocationUriSet":
      route(ADD_LOCATION_BY_REFERENCE);
    case "responceWithPresenceAndLocationUriSet":
      route(ADD_LOCATION_BY_VALUE);
      route(ADD_LOCATION_BY_REFERENCE);
    case "badHeldResponce":
      route(TRY_OTHER_LOCATION_METHOD);
    case "locationUnknown":
      xlog(L_ERR, "Received LIS error response: $(varLisErrorMessage)");
      route(TRY_DEFAULT_PSAP);
    case "generalLisError":
      xlog(L_ERR, "Received unexpected LIS error response: $(varLisErrorMessage)");
      route(TRY_OTHER_LOCATION_METHOD);
    default:
      xlog(L_WARNING, "Received unexpected LIS response: $xavp(held_responce[0]=>HELD_ERROR_CODE) - $xavp(held_responce[0]=>HELD_ERROR_MESSAGE)");
      route(TRY_DEFAULT_PSAP);
  }  

[wkampich]

@sergey-safarov: this sounds reasonable and would also fit well for other lost functions - let's leave the issue open and I will think of something. Further inputs are always welcome.

[henningw]

@wkampich is this issue still relevant, or maybe already solved by some additions/changes to the lost module in the last months?

[wkampich]

@henningw this is still relevant ... unfortunately I have not had time to work on it yet

[github-actions]

This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.