lost: dynamic HELD url resolving #2574
Comments
|
NAPTR support is a good idea and basically also applicable to the LoST service (which I have on my ToDo list anyway). I will have a look at it - just one question: I assume item (1) below refers to the device IP address (i.e. UE) for reverse DNS (as in https://tools.ietf.org/html/rfc7216#section-4), which may not work in any case. How about expanding the discovery procedure with a NAPTR request sent to the provider's domain (as found in From and/or P-A-I) in case (1) fails? (1) Kamailio send reverse .in-addr.arpa. or .ip6.arpa. DNS request and caller host DNS name; |
Yes, looks as it will be a good extension. Here examples of Example 2 - private IP address in Example 3 - IPv6 address in Example 4 - no domain in Think not required to make double reverse and NAPTR DNS lookups if the domain from Could you look at this example. IP address does exist here, put present caller domain. So we can skip reverse lookup and execute NAPTR. |
…tion - features: LoST redirect, dynamic HELD url resolving (#2574), LoST NAPTR, POST request to dereference loation - attributes: reponse_time (-1:emergencyDispatch, 0:emergencyRouting, >0[ms]); post_request (POST method to dereference location #2641); recursion (yes/no); location_profile (PIDF/LO profile selection: first/last/geo/civic); verbose (detailed LoST response as log INFO); geoheader_type (filter schema: any/cid/http/https); geoheader_order (first/last) - function: lost_held_dereference (specific function to dereference location using POST method); attributes are url (r), resp.-time (r), resp.-type (r), pidf (r/w) and error (r/w) - general: The extension of the module allows dynamic querying of LIS/HELD and LOST services via NAPTR lookup. In the case of LOST, a redirect response is evaluated. In case a lost_held_request (used to connect to a LIS via POST or GET) is passed with an empty string ("") for the connection parameter, then P-A-I or From header value hostnames are used for NAPTR lookup to get a corresponding service.
…tion - features: LoST redirect, dynamic HELD url resolving (kamailio#2574), LoST NAPTR, POST request to dereference loation - attributes: reponse_time (-1:emergencyDispatch, 0:emergencyRouting, >0[ms]); post_request (POST method to dereference location kamailio#2641); recursion (yes/no); location_profile (PIDF/LO profile selection: first/last/geo/civic); verbose (detailed LoST response as log INFO); geoheader_type (filter schema: any/cid/http/https); geoheader_order (first/last) - function: lost_held_dereference (specific function to dereference location using POST method); attributes are url (r), resp.-time (r), resp.-type (r), pidf (r/w) and error (r/w) - general: The extension of the module allows dynamic querying of LIS/HELD and LOST services via NAPTR lookup. In the case of LOST, a redirect response is evaluated. In case a lost_held_request (used to connect to a LIS via POST or GET) is passed with an empty string ("") for the connection parameter, then P-A-I or From header value hostnames are used for NAPTR lookup to get a corresponding service.
|
Can this be closed? I see commits referencing it were merged. |
|
yes, sure. |
…tion - features: LoST redirect, dynamic HELD url resolving (kamailio#2574), LoST NAPTR, POST request to dereference loation - attributes: reponse_time (-1:emergencyDispatch, 0:emergencyRouting, >0[ms]); post_request (POST method to dereference location kamailio#2641); recursion (yes/no); location_profile (PIDF/LO profile selection: first/last/geo/civic); verbose (detailed LoST response as log INFO); geoheader_type (filter schema: any/cid/http/https); geoheader_order (first/last) - function: lost_held_dereference (specific function to dereference location using POST method); attributes are url (r), resp.-time (r), resp.-type (r), pidf (r/w) and error (r/w) - general: The extension of the module allows dynamic querying of LIS/HELD and LOST services via NAPTR lookup. In the case of LOST, a redirect response is evaluated. In case a lost_held_request (used to connect to a LIS via POST or GET) is passed with an empty string ("") for the connection parameter, then P-A-I or From header value hostnames are used for NAPTR lookup to get a corresponding service.
Description
According to design logic HELD request need to send a carrier LIS server. Now lost module sends this request to the preconfigured server via
http_client/httpconparam.I prefer to use dynamic LIS server discovery according to rfc7216#section-4 and rfc5986#section-4.
So dynamic LIS discovery works as:
.in-addr.arpa.or.ip6.arpa.DNS request and caller host DNS name;LIS:HELDNAPTR request for a resolved caller hostname and get LIS server URI in responce.So do get working dynamic LIS discovery required to implement two DNS requests.
If any DNS request will fail, then
lost_held_queryfunction returns an error code.To define required dynamic LIS discovery I suggest use an empty string ("") or NULL value ($null) as the first ("con") function param.
This feature request for discussion with lost module author (Wolfgang Kampichler @wkampich) and other interest devs.
The ticket may be closed at any time.
The text was updated successfully, but these errors were encountered: