SIP register fails on new server install with __sip__xmit returns error for pkt data

configuration
siptrunk
Tags: #<Tag:0x00007f702834b0d0> #<Tag:0x00007f702834aec8>

(Chris) #1

Hi,

I’ve studied the other forum posts on the topic of “__sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data” but none of those threads reaches an answer that helps me understand what could be wrong and how to trace the issue.

Production system runs Asterisk 13 with FreePBX 12 that I’m in the process of upgrading to Asterisk 16 with FreePBX 14. After doing a clean install onto CentOS with Asterisk 16+FreePBX 14 (Hosted VM Image in CaaS datacentre. We can’t install FreePBX Distro from ISO)

After installation, adding a SIP trunk with exactly same parameters for Incoming and Outgoing SIP settings, produces this error. The SIP credentials are working on the production machine, but not the new machine.

Q1: Could the SIP settings be incorrect moving it copy paste from the old machine on FreePBX 12 to FreePBX14?
Q2: How can I debug this configuration issue as the network trace below shows the packet does not go onto the network segment for SIP REGISTER?

TCPDUMP shows no packets on network trace
TCPDUMP does show register success on original production server. (Can’t attach images to post.)

SIP Settings on Asterisk 16 - New Installation:

Trunk Name: Outgoing_1
username=******
type=peer
secret=****
qualify=no
nat=yes
host=****.com
disallow=all
context=from-trunk
canreinvite=no
allow=g726

USER Context: Incoming_1
username=****
type=peer
secret=****
qualify=no
nat=yes
insecure=invite
host=****.com
disallow=all
context=from-trunk
canreinvite=no
allow=alaw,ulaw,g726

asterisk-cli output
2020-09-04 09:36:48] NOTICE[2514]: chan_sip.c:15893 sip_reregister:    -- Re-registration for  *******@********.com
REGISTER 11 headers, 0 lines
Reliably Transmitting (NAT) to 41.21.255.42:5060:
REGISTER sip:******.com SIP/2.0
Via: SIP/2.0/UDP *.*.*.*:5060;branch=z9hG4bK68a88aef;rport
Max-Forwards: 70
From: <sip:*******@********.com>;tag=as5adb97a2
To: <sip:*******@********.com>
Call-ID: 07e840ac6fcf66d676cc9fb7184d2cf3@X.X.X.X
CSeq: 102 REGISTER
Supported: replaces, timer
User-Agent: FPBX-14.0.13.34(16.13.0)
Expires: 120
Contact: <sip:XXX@X.X.X.X:5060>
Content-Length: 0


---
[2020-09-04 09:36:48] ERROR[2514]: chan_sip.c:4344 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data

Regards,
Chris


#2

That should be ok, but note that if the registration were successful, some or all incoming calls that should be going to the production machine would now be diverted to the new machine, which in many cases would be a problem.

It appears that Dimension Data?, like many cloud providers, sets up the VM on a private IP with a 1:1 NAT mapping to a dedicated public IP. Possibly, setup of this firewall on their portal is incorrect. Or, there may be a routing problem at the OS level.

At a root shell prompt, what is the output of ip route ?
Any output from ping 41.21.255.42 ?
Does SIP otherwise work, for example can you register an extension (IP phone, softphone, etc.) to the new server? If so, can you call *65 and hear the extension number?


(Chris) #3

Hi Stewart,

We have multiple open SIP numbers to use for our upgrade migration so the scenario of simultaneously REGISTERING on two machines is well spotted, and could cause issues, but in our case, the SIP trunk is disabled on production environment during our tests we conducted.

[_@10-80-112-10 ~]# ip route
default via 10.80.112.1 dev ens32
10.80.112.0/24 dev ens32 proto kernel scope link src 10.80.112.10
169.254.0.0/16 dev ens32 scope link metric 1002
[_@10-80-112-10 ~]#

ping to said IP will fail as ICMP requests are blocked by default on the destination. I can however ping all our other connected services including maps.google.com and mail.office365.com

I’m busy configuring and testing that now, so will give feedback.

What is strange is the fact that the tcpdump does not show up any SIP traffic which leads me to believe I must investigate the SIP settings closer as well as the network configuration and the chan_sip settings.

I’m just not familiar enough yet with Asterisk 16 to know how it is different compared to Asterisk 13 in terms of possible networking config for chan_sip


(Chris) #4

Hi Stewart,

Was able to register new extension and connect to the server.

Called *65 from SIP phone, but I don’t hear the extension number. Using Zoiper Premium. Call is established but no audio. Don’t know if this helps:
pbx.c:2927 pbx_extension_helper: No application 'Macro' for extension (from-internal, *65, 6)

What is strange is the following message (Don’t want to distract from the OP but I feel it could perhaps shed light. I am researching existing posts on forums)

When I try to connect from softphone, the following message pops-up and initially I could not connect to port host:5060 with following message

res_pjsip_registrar.c:1102 registrar_on_rx_request: Endpoint 'anonymous' has no configured AORs

Reconfirmed the port bindings and General SIP Settings channel driver to allow both CHAN_SIP and PJSIP and bound 5060 to SIP and 5160 to PJSIP.


#5

Bingo!

FreePBX depends heavily on macros. See comments about app_macro in


#6

When you change any of those settings, you must restart (not just reload) Asterisk.

Possibly, this was other traffic and unrelated to the softphone’s request.


#7

When you build asterisk (if you did) make sure to check app-macro in the make menuselect bit


(Chris) #8

Thanks for the suggestion. Did not spot that detail in the install part. Will do a rebuild and revert.

I take it this would then affect the SIP register part also? Why then is this not selected in menuselect bit by default if it is such a important detail for SIP registrations.


#9

Asterisk considers macro depecated and not to be used anymore, FreePBX however relies on them (which is a bit of a Yossarian :wink: ), but your recipe likely stated explicitly to add it for asterisk += 16 as you later discovered.

Don’t need a full rebuild just

make menuselect && make && make install

to add it


(Chris) #10

Following your advice and that of @dicko to build again with app_macro selected under the Applications section of
make menuselect
made the difference.

The SIP is now registering to our service provider without any hassles.

I must however investigate further on the *65 that should send back my number. I have not used this before on the older Asterisk 13 and don’t know 100% what other configuration is missing for it to work.

I consider my OP solved. Thanks for the patience.


(system) closed #11

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