Inbound calls fail somtimes (seemingly randomly)

oberite · July 15, 2018, 8:30pm

I have an issue where inbound calls from my trunk work only sometimes. There is no pattern I can discern as to what may be causing this failure. It will work for one call, only to fail the next, just to work on the third one; other times, it will work without error for several hours.

When a call fails, I see “No matching peer” in my logs, followed by returning 401 Unauthorized to my trunk provider.

My provider is Voyant, and I am using IP authentication.

Here is a log snippet of when it works:

<--- SIP read from UDP:137.192.80.33:5060 --->
INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 137.192.80.33:5060;branch=z9hG4bKqo2r1n206o9mpatbljp0.1
From: <sip:[email protected]:5060;isup-oli=62>;tag=gK0c2c5cff
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 443724 INVITE
Max-Forwards: 67
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:[email protected]:5060;transport=udp>
P-Asserted-Identity: "CNAM " <sip:[email protected]:5060>
Supported: timer,100rel,precondition
Session-Expires: 1800
Min-SE: 90
Content-Length: 364
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 77861 169058 IN IP4 137.192.80.33
s=SIP Media Capabilities
c=IN IP4 137.192.80.33
t=0 0
m=audio 25498 RTP/AVP 96 0 18 101 100
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/48000
a=fmtp:101 0-15
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:20
a=record:on
<------------->
[2018-07-15 15:25:18] VERBOSE[17369] chan_sip.c: --- (17 headers 16 lines) ---
[2018-07-15 15:25:18] VERBOSE[17369] chan_sip.c: Sending to 137.192.80.33:5060 (no NAT)
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Sending to 137.192.80.33:5060 (no NAT)
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Using INVITE request as basis request - [email protected]
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found peer 'voyant' for '+1231818XXXX' from 137.192.80.33:5060
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] netsock2.c: Using SIP RTP TOS bits 184
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] netsock2.c: Using SIP RTP CoS mark 5
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found RTP audio format 96
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found RTP audio format 0
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found RTP audio format 18
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found RTP audio format 101
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found RTP audio format 100
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found audio description format opus for ID 96
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found audio description format PCMU for ID 0
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found audio description format G729 for ID 18
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found unknown media description format telephone-event for ID 101
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Found audio description format telephone-event for ID 100
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Capabilities: us - (ulaw|alaw|gsm|g726|g722|g723|g726aal2|adpcm|slin|slin|slin|slin|slin|slin|slin|slin|slin|lpc10|g729|speex|speex|speex|ilbc|siren7|siren14|testlaw|g719|opus|jpeg|png|h261|h263|h263p|h264|mpeg4|vp8|vp9|red|t140|silk|silk|silk|silk), peer - audio=(ulaw|g729|opus)/video=(nothing)/text=(nothing), combined - (ulaw|g729|opus)
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Peer audio RTP is at port 137.192.80.33:25498
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: Looking for +1231597XXXX in from-pstn-e164-us (domain 206.189.X.X)
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] sip/route.c: sip_route_dump: route/path hop: <sip:[email protected]:5060;transport=udp>
[2018-07-15 15:25:18] VERBOSE[17369][C-00000334] chan_sip.c: 
<--- Transmitting (no NAT) to 137.192.80.33:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 137.192.80.33:5060;branch=z9hG4bKqo2r1n206o9mpatbljp0.1;received=137.192.80.33
From: <sip:[email protected]:5060;isup-oli=62>;tag=gK0c2c5cff
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 443724 INVITE
Server: FPBX-13.0.195.4(13.21.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:[email protected]:5060>
Content-Length: 0

And when it doesn’t:

<--- SIP read from UDP:137.192.80.33:5060 --->
INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 137.192.80.33:5060;branch=z9hG4bKostdol30boa06ev7lud0.1
From: <sip:[email protected]:5060;isup-oli=62>;tag=gK0c3466a1
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 529262 INVITE
Max-Forwards: 67
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:[email protected]:5060;transport=udp>
P-Asserted-Identity: "CNAM " <sip:[email protected]:5060>
Supported: timer,100rel,precondition
Session-Expires: 1800
Min-SE: 90
Content-Length: 365
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 600124 360022 IN IP4 137.192.80.33
s=SIP Media Capabilities
c=IN IP4 137.192.80.33
t=0 0
m=audio 25440 RTP/AVP 96 0 18 101 100
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/48000
a=fmtp:101 0-15
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:20
a=record:on
<------------->
[2018-07-15 15:31:43] VERBOSE[17369] chan_sip.c: --- (17 headers 16 lines) ---
[2018-07-15 15:31:43] VERBOSE[17369] chan_sip.c: Sending to 137.192.80.33:5060 (no NAT)
[2018-07-15 15:31:43] VERBOSE[17369][C-00000339] chan_sip.c: Sending to 137.192.80.33:5060 (no NAT)
[2018-07-15 15:31:43] VERBOSE[17369][C-00000339] chan_sip.c: Using INVITE request as basis request - [email protected]
[2018-07-15 15:31:43] VERBOSE[17369][C-00000339] chan_sip.c: No matching peer for '+1231818XXXX' from '137.192.80.33:5060'
[2018-07-15 15:31:43] VERBOSE[17369][C-00000339] chan_sip.c: 
<--- Reliably Transmitting (no NAT) to 137.192.80.33:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 137.192.80.33:5060;branch=z9hG4bKostdol30boa06ev7lud0.1;received=137.192.80.33
From: <sip:[email protected]:5060;isup-oli=62>;tag=gK0c3466a1
To: <sip:[email protected]:5060>;tag=as57460408
Call-ID: [email protected]
CSeq: 529262 INVITE
Server: FPBX-13.0.195.4(13.21.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="44b2217b"
Content-Length: 0

PEER Details:

type=peer
trustrpid=no
sendrpid=no
insecure=port,invite
host=X.st.sip.global
dtmfmode=rfc2833
;disallow=all
context=from-pstn-e164-us
canreinvite=no
;allow=ulaw
allow=all

I changed the allow/disallow settings thinking that the trunk may be choosing random codecs (grasping at straws), but both configurations work the same.

I have read through other posts reporting similar issues, but those seemed to happen when the provider is using more than one IP address for invites, but that isn’t the case with me.

It may be important to know that I also have a Vitelity trunk configured, which is working fine.

I would appreciate any input on this issue.

BlazeStudios · July 15, 2018, 8:40pm

What happens when the host is the actual IP instead of a domain name? Maybe there is a DNS issue happening.

oberite · July 15, 2018, 9:03pm

That’s a great idea. After checking, I saw that there are two A records for the domain.

I made the change, and calls are working for now. Due to the nature of this problem, I may not know if it is fixed for a few hours, but it seems quite likely that it is.

Thank you for the help!

oberite · July 15, 2018, 9:10pm

Unfortunately, I just had a call fail again. I have confirmed that it was initiated from the IP I explicitly put in the peer details.

lgaetz · July 15, 2018, 9:20pm

Changing host details will benefit from asterisk restarting:

fwconsole restart

oberite · July 15, 2018, 9:49pm

This seems to have worked. Thank you both.

system · July 22, 2018, 9:49pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.