### 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/httpcon` param. I prefer to use dynamic LIS server discovery according to [rfc7216#section-4](https://tools.ietf.org/html/rfc7216#section-4) and [rfc5986#section-4](https://tools.ietf.org/html/rfc5986#section-4). So dynamic LIS discovery works as: 1. Kamailio send reverse `.in-addr.arpa.` or `.ip6.arpa.` DNS request and caller host DNS name; 2. Kamailio send `LIS:HELD` NAPTR request for a resolved caller hostname and LIS server. 3. Kamailio send HELD request for resolved LIS address.
So do get working dynamic LIS discovery required to implement two DNS requests.
If any DNS request will fail, then `lost_held_query` function 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.
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; (2) Kamailio send LIS:HELD NAPTR request for a resolved caller hostname and LIS server. (3) Kamailio send HELD request for resolved LIS address.
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
Yes, looks as it will be a good extension. Domain from `From` header may be used only if domain not available in `P-A-I` header.
Here examples of `From` and `P-A-I` headers that we can receive **Example 1** - domain matched in `From` and `P-A-I` headers ``` From: sip:+18556667788@206.147.246.118:5060;tag=gK0e0d09a4 P-Asserted-Identity: sip:+18556667788@206.147.246.118:5060 ```
**Example 2** - private IP address in `From` header and no domain in `P-A-I` header. `P-A-I` contains tel and sip uri. ``` From: sip:+16692481432@198.226.45.84;tag=gK04090b5e P-Asserted-Identity: tel:+16692481432, sip:+16692481432@vzimstest.com ```
**Example 3** - IPv6 address in `From` header and no domain in `P-A-I` header ``` From: "9255111003"sip:9255111003@[2605:97c0:2058:3120:1::1]:50001;tag=75fdbcf61a;epid=SC597fbd P-Asserted-Identity: tel:9255111003 ``` **Example 4** - no domain in `From` and `P-A-I` headers ``` From: tel:+13559598013;tag=SDtl3t701-5f7f754a-5f89c26229204b60-Noo-lucentNGFS-000264 P-Asserted-Identity: tel:+11005534340 ```
Think not required to make double reverse and NAPTR DNS lookups if the domain from `P-A-I` or `From` headers equals to caller network IP address.
Could you look at this example. ``` P-Asserted-Identity: tel:+16692481432, sip:+16692481432@vzimstest.com ``` IP address does exist here, put present caller domain. So we can skip reverse lookup and execute NAPTR.
Can this be closed? I see commits referencing it were merged.
yes, sure.
Closed #2574.
-
Daniel-Constantin Mierla -
sergey-safarov
-
Wolfgang Kampichler