Incomming calls issue (some go through others not)

Hi,

We have a setup configured for some months now and everything was working fine until yesterday.

Problem: From time to time the calls fail to go through the system, it’s fine for 10 minutes then stops accepting calls and later accepts calls again

Our supplier (where the call comes from) says that they are receiving a 401 Unauthorized message but we don’t understand why the system sometimes sends that and sometimes accepts the call.

here’s the log when the call fails

[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:9409 __find_call: = Looking for  Call ID: [email protected] (Checking From) --From tag 5b1d5187 --To-tag
[2017-06-27 12:12:18] DEBUG[2170]: acl.c:957 ast_ouraddrfor: For destination '149.91.14.71', our source address is '185.52.3.150'.
[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:3910 ast_sip_ouraddrfor: Setting AST_TRANSPORT_UDP with address 185.52.3.150:5061
[2017-06-27 12:12:18] DEBUG[2170]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting '149.91.14.71:5060' into...
[2017-06-27 12:12:18] DEBUG[2170]: netsock2.c:226 ast_sockaddr_split_hostport: ...host '149.91.14.71' and port '5060'.
[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:8996 __sip_alloc: Allocating new SIP dialog for [email protected] - OPTIONS (No RTP)
[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:28642 handle_incoming: **** Received OPTIONS (3) - Command in SIP OPTIONS
[2017-06-27 12:12:18] DEBUG[2170]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting '185.52.3.150:5061' into...
[2017-06-27 12:12:18] DEBUG[2170]: netsock2.c:226 ast_sockaddr_split_hostport: ...host '185.52.3.150' and port ''.
[2017-06-27 12:12:18] DEBUG[2170]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting 'sip.sipcentric.com' into...
[2017-06-27 12:12:18] DEBUG[2170]: netsock2.c:226 ast_sockaddr_split_hostport: ...host 'sip.sipcentric.com' and port ''.
[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:3753 __sip_xmit: Trying to put 'SIP/2.0 200' onto UDP socket destined for 149.91.14.71:5060
[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:9409 __find_call: = Looking for  Call ID: [email protected] (Checking From) --From tag as3b898047 --To-tag
[2017-06-27 12:12:18] DEBUG[2170]: acl.c:957 ast_ouraddrfor: For destination '149.91.14.71', our source address is '185.52.3.150'.
[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:3910 ast_sip_ouraddrfor: Setting AST_TRANSPORT_UDP with address 185.52.3.150:5061
[2017-06-27 12:12:18] DEBUG[2170]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting '149.91.14.71' into...
[2017-06-27 12:12:18] DEBUG[2170]: netsock2.c:226 ast_sockaddr_split_hostport: ...host '149.91.14.71' and port ''.
[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:8996 __sip_alloc: Allocating new SIP dialog for [email protected] - INVITE (No RTP)
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: chan_sip.c:28642 handle_incoming: **** Received INVITE (5) - Command in SIP INVITE
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: sip/reqresp_parser.c:1711 parse_sip_options: Begin: parsing SIP "Supported: replaces, timer"
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: sip/reqresp_parser.c:1726 parse_sip_options: Found SIP option: -replaces-
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: sip/reqresp_parser.c:1734 parse_sip_options: Matched SIP option: replaces
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: sip/reqresp_parser.c:1726 parse_sip_options: Found SIP option: -timer-
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: sip/reqresp_parser.c:1734 parse_sip_options: Matched SIP option: timer
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting '149.91.14.71' into...
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: netsock2.c:226 ast_sockaddr_split_hostport: ...host '149.91.14.71' and port ''.
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting 'sip.sipcentric.com' into...
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: netsock2.c:226 ast_sockaddr_split_hostport: ...host 'sip.sipcentric.com' and port ''.
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: chan_sip.c:3753 __sip_xmit: Trying to put 'SIP/2.0 401' onto UDP socket destined for 149.91.14.71:5060
[2017-06-27 12:12:18] DEBUG[2170]: chan_sip.c:9409 __find_call: = Looking for  Call ID: [email protected] (Checking From) --From tag as3b898047 --To-tag as0b8ce564
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: chan_sip.c:28642 handle_incoming: **** Received ACK (6) - Command in SIP ACK
[2017-06-27 12:12:18] DEBUG[2170][C-0000009f]: chan_sip.c:4537 __sip_ack: Stopping retransmission on '[email protected]' of Response 102: Match Found

Any help here? How can I see a more detailed log? (like the message that our system sends to them)

Thanks in advance!

Below the setup that we have

Outgoing:
username=XXXXX
type=peer
secret=XXXXXXXX
qualify=yes
nat=yes
insecure=port,invite
host=sip.sipcentric.com
fromuser=XXXXXX
fromdomain=sip.sipcentric.com
dtmfmode=auto
canreinvite=no
authuser=XXXXXX
disallow=all
allow=ulaw&alaw

Incoming register string
XXXXX:[email protected]/DIDNUMBER

Then there’s a inbound route that matches the DIDNUMBER and sends it to a time condition

The fqdn sip.sipcentric.com resolves to two separate IP addresses. I know from recent experience that some inbound calls originate from one IP and some from the other IP. Since Asterisk authenticates inbound invites based on source IP and port, some of your calls are being treated as anonymous.

I’m not entirely sure how best to handle this situation. I know that changing the PEER Details host to IP#1 and populating the USER Details section with IP#2 will fix this. You could also replicate the trunk details for a second trunk, and set host for each trunk to the different IP address. You also want to ensure that only one trunk has a register string.

Thanks for the reply.

I’ll try to use the IP’s directly, one on the peer and other on the user details and see if this solves the issues.

In the meanwhile I was trying to configure a PJSIP trunk but was not able to match it with a incoming route, different thread here PJSIP trunk to inbound route without DID

I’ve always found that setting up separate trunks using the two IP addresses for the incoming call origination is a very simple solution to this problem. A couple of my providers have several (one has four) originating servers. I set up one trunk per server and stopped having the O/P’s problem.