3 Dec
2020
3 Dec
'20
2:52 p.m.
### 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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2574
6 Dec
6 Dec
2:51 p.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2574#issuecomment-739491798
4:44 p.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2574#issuecomment-739504721
7 May
7 May
9:12 a.m.
Can this be closed? I see commits referencing it were merged.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2574#issuecomment-834096499
9:26 a.m.
yes, sure.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2574#issuecomment-834102533
9:26 a.m.
Closed #2574.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2574#event-4699667309
1296
days inactive
1451
days old
5 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
sergey-safarov
-
Wolfgang Kampichler