### Description
According [RFC5985](https://tools.ietf.org/html/rfc5985)
The POST method is the only method REQUIRED for HELD. If a LIS
chooses to support GET or HEAD, it SHOULD consider the kind of application doing the GET.
So not all LIS servers support the GET method and only the POST method always present.
Also [rfc6753#section-3.2](https://tools.ietf.org/html/rfc6753#section-3.2)
An HTTP GET request to a HELD URI produces a HELD response as if the
following HELD request had been sent using HTTP POST:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationType exact="false"> geodetic civic </locationType> </locationRequest>
### Expected behavior Dereference Geolocation URLs using POST method with content according [rfc6753#section-3.2](https://tools.ietf.org/html/rfc6753#section-3.2)
I observed that http_client drop the HTTP request after a timeout. So will be good to let LIS know Kamailio timeout.
To do this may be used `responseTime` paramer according rfc5985#section-6.1
The "responseTime" attribute MAY be included in a location request
message. The "responseTime" attribute includes a time value indicating to the LIS how long the Device is prepared to wait for a response or a purpose for which the Device needs the location.
The time value in the "responseTime" attribute is expressed as a non-
negative integer in units of milliseconds.
So we can use request body like ```xml <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="4000"> <locationType exact="false"> geodetic civic </locationType> </locationRequest> ```
According [rfc5985](https://tools.ietf.org/html/rfc5985) `responseTime` may contain values 1. `emergencyRouting` 2. `emergencyDispatch` 3. non Negative Integer value
```xml <!-- responseTime Type --> <xs:simpleType name="responseTimeType"> xs:union xs:simpleType <xs:restriction base="xs:token"> <xs:enumeration value="emergencyRouting"/> <xs:enumeration value="emergencyDispatch"/> </xs:restriction> </xs:simpleType> xs:simpleType <xs:restriction base="xs:nonNegativeInteger"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> ```
Pinging @wkampich as he mentioned in a PR that works on extending the module and maybe some of these are on his table already.
Otherwise, you can also start implementing and make pull requests to the lost module. Or if other developers want to do it, they should make a note here. At the moment I have no spare time and no environment that would make it easier for me to approach it. Based on last online devel meeting conclusions, requests for new features that do not attract a developer to implement them will be closed after a while, a reference to this page can be collected in a wiki page, just in case someone wants to pick it up in the future.
@miconda This ticket for requirements definition not only. When I or another developer will be ready to implement then it can be reopened.
P.S. May we need some live cycle for tickets. Like "if the feature ticket not commented by somebody from Kamailio team, then automatically close with tag `not-dev-to-implement`".
`responseTime` is set via `modparam("lost", "response_time", 5000)` and should to be a value less than the `http_client` timeout value, but anyway thanks for your feedback, I'll have a look at it ... regarding POST method to dereference locationis something I've on my table as I've seen it when preparing for the upcoming ETSI NG112 Plugtests event.
Thanks @wkampich for the `response_time` modparam reference. Looks as here required support of two string values `emergencyRouting` and `emergencyDispatch`. When used these string values we can set `0` timeout value for http_client AIP call.
Can this one be closed? There was quite some development pushed to lost module.
Sure, Daniel.
Closed #2641.
-
Daniel-Constantin Mierla -
sergey-safarov
-
Wolfgang Kampichler