Double and Triple invite on signaling

I’m working with asterisk 11 and 13 and I don’t have issues, however I’m migrating from these asterisk to pjsip, asterisk 18 and Asterisk Realtime and for some reason I am getting duplicates and triplicate INVITES in the SIP packages

My infrastructure is:

Kamailio SIP → Asterisk 18 → AGI Server

When these asterisk server receive traffic, they working fine but few hours later they show this behavior.

I’ve added the kamailio hostname on asterisk /etc/hosts and I change svr_lookups = no, but I don’t have different results

Maybe I should change other values on Asterisk Realtime tables?

image

Thanks

The trying isn’t being returned within 500ms.

Thank you for you answer but it isn’t clear for me, What could be a solution? I keep investigating and I find in this table ps_aors, can I add value to these options, currently I have these fields with NULL:

default_expiration
maximum_expiration
minimum_expiration
qualify_frequency
qualify_timeout

Thanks

An AOR has is not involved in strictly an incoming INVITE handling. Do you have “identify” in realtime? Are you using hostnames? If so then the handling will be blocked until DNS resolution of that completes, if it is slow then the handling of the INVITE will be slow.

core-05*CLI> pjsip show identifiers

Identifier Names:
name not specified
header
ip
username
auth_username
anonymous

And yes I’m using hostnames, I’ve added in /etc/hosts file Kamailio hostnames, however I read to avoid dns resolution I can change svr_lookups=no but I still see the same behavior

That doesn’t avoid DNS resolution. That avoids SRV lookups. If a hostname is provided then DNS resolution will still occur. You should avoid hostnames for identify if at all possible if using realtime for this exact reason. Underneath it uses the system resolution method, so if that respects /etc/hosts and the hostname is in there then it should return quickly.

This is happening for Trying. The only time when DNS should be involved with that is if the Via header contains a domain name. Otherwise, the whole point of Trying is that it can be sent before any significant analysis of the request has been made. It’s a protocol violation to send it late. The UAS has 200ms to send it.

On the other hand, it isn’t clear where the packet capture was taken, and therefore whether Asterisk is causing the delay.

I believe it happens after endpoint identification for us, which is where DNS resolution would occur as a result of the identify being a hostname.

The capture was taken from external server, this server capture the kamailio and asterisk traffic.
I appreciate you help and so based on you explanation the solution is remove hostnames from the /etc/hosts or is there an option for the asterisk doesn’t trying to resolve the names???

If you configure an identify with an IP address, then it won’t do a DNS lookup. If you configure with a hostname, it will do a DNS looup.

It should be sending the Trying before doing a database lookup. Consulting a database is the actual example given of why you might need to send Trying.

1 Like

We could probably change it though I’m not going to invest time into doing so since in practice the impact isn’t huge and the scope is limited to specific configuration and usage. If someone else put up such a review then it’d be reviewed.

I’d like to share my ps_endpoint_id_ips table

image

I’m using match_header to identify trunks because I have a Kamailio server in the middle and I will receive the same ip for all traffic.

Is it possible to optimize using match_header because when I enabled debug I was able to see, asterisk search one by one until to find the right trunk and send the call

Thanks

No, there is no optimization possible.

jcolp

Maybe do you have another idea to resolve this issue?

Regards

I would start by reducing the moving parts to isolate the underlying cause - such as not using realtime.

Could sorcery pre-caching help here? The main catch I can see is that you will still get a long delay when the cache refresh time comes up, unless you set it very high and force a refresh on a change.

My detailed knowledge of the code predates sorcery, so I’m only going on the results of a quick documentation search.

It’s possible, and if eliminating realtime proved that realtime was the cause then going down that road could help.

I’m trying to modify asterisk source code and when I enable

So, in res_config_odbc.c file in line around 390, I added

ast_str_set(&sql, 0, "SELECT * FROM ps_endpoint_id_ips WHERE match_header=‘%s’ ", “InTrunkID: 250”);

However I need to send from res_pjsip_endpoint_identifier_ip.c file to config_odbc.c match_header value instead InTrunkID: 250.

Maybe do you have any suggestion?

P.D: Remove Realtime isn’t an option because I have around 64 asterisk servers

I don’t have any suggestion, as things are not architected to work that way.