IAX2 trunk not connecting

General Help
1

I have two problems that may be connected. I had an elastix and a FreePBX Distro servers that had been connected by an IAX2 Trunk. The elastix server was connected to a PRI line, and the FreePBX server connected to the PRI line through an IAX2 trunk to the FreePBX server. Both servers are running Asterisk 13.19.1

I migrated the Elastix server to FreePBX distro. Now the IAX2 trunk will not let calls through - I get a congestion message. IAX2 peers shows that the status of the IAX peer is OK on each server.On the server with the PRI, I get a lot of log entries like this:

[2018-04-27 09:33:30] VERBOSE[5878] chan_iax2.c: Timestamp: 00011ms SCall: 03705 DCall: 00000 192.168.0.253:4569
[2018-04-27 09:33:30] VERBOSE[5878] chan_iax2.c:
[2018-04-27 09:33:30] VERBOSE[5878] chan_iax2.c: Tx-Frame Retry[ No] – OSeqno: 000 ISeqno: 001 Type: IAX Subclass: PONG
[2018-04-27 09:33:30] VERBOSE[5878] chan_iax2.c: Timestamp: 00011ms SCall: 00001 DCall: 03705 192.168.0.253:4569
[2018-04-27 09:33:30] VERBOSE[5873] chan_iax2.c: Rx-Frame Retry[ No] – OSeqno: 001 ISeqno: 001 Type: IAX Subclass: ACK
[2018-04-27 09:33:30] VERBOSE[5873] chan_iax2.c: Timestamp: 00011ms SCall: 03705 DCall: 00001 192.168.0.253:4569
[2018-04-27 09:33:39] VERBOSE[5869] chan_iax2.c: Tx-Frame Retry[000] – OSeqno: 000 ISeqno: 000 Type: IAX Subclass: POKE,

followed by this:

[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: VERSION : 2
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CALLED NUMBER : zzz
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CODEC_PREFS : (ulaw|g722|alaw|gsm)
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CALLING NUMBER : xxxxxxxx
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CALLING PRESNTN : 0
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CALLING TYPEOFN : 0
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CALLING TRANSIT : 0
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CALLING NAME :
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: LANGUAGE : en
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: USERNAME : xxxxxx
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: FORMAT : 4
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: FORMAT2 : ulaw
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CAPABILITY : 4110
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CAPABILITY2 : Unknown
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: ADSICPE : 2
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: DATE TIME : 2018-04-27 09:35:28
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: CALLTOKEN : 51 bytes
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c:
[2018-04-27 09:35:40] WARNING[5874] chan_iax2.c: Too much delay in IAX2 calltoken timestamp from address 192.168.0.253:4569
[2018-04-27 09:35:40] VERBOSE[5874] chan_iax2.c: Tx-Frame Retry[ No] – OSeqno: 000 ISeqno: 002 Type: IAX Subclass: REJECT.

On the sender, I see this:

[2018-04-27 09:35:28] VERBOSE[19311][C-00000012] app_dial.c: Called IAX2/yyyyyy/zzz
[2018-04-27 09:36:00] WARNING[27063] chan_iax2.c: Max retries exceeded to host 192.168.0.250 on IAX2/yyyyyyyy-16970 (type = 6, subclass = 1, ts=31, seqno=0)
[2018-04-27 09:36:00] VERBOSE[19311][C-00000012] chan_iax2.c: Hungup ‘IAX2/yyyyyyy-16970’
[2018-04-27 09:36:00] VERBOSE[19311][C-00000012] app_dial.c: Everyone is busy/congested at this time (1:0/0/1).

Additionally, I noticed that my CDR reports on the server without the PRI have no data in the time/date field. I don’t know if this is related to my IAX problem.

I have already placed calltokenoptional=yes into my trunk definitions, but still no connection

Any other ideas out there?

I have replaced it with a SIP trunk for now, but if i could get IAX to work that would be great.

2

The two machines clocks are 12 seconds apart.

3

Dicko:

Thanks for your response. I see why you say that - because the call starts on the receiving end at :40, but was initiated on the calling end at :28. But please believe me when I tell you that i have both GUIs open in front of me to System Admin>Time Zone and am watching the server time tick. The recipient is actually around 1.5 seconds ahead of the caller.

Both servers have 0.centos.pool.ntp.org in etc/ntp/step-tickers

4

There are 12 additional leap seconds in NTP. Coincidence.

5

After a restart of the server with the PRI, it connects fine. I don’t know which of the changes that I made took effect this time, but it is working for now.

6

That’s one problem solved. I still don’t have any time or date entries in my CDR reports for the other machine. The “Call Date” field is just blank.

7

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