Outgoing Calls not working after service restart - fix known

Asterisk Asterisk Support
1

Hello,

I have encountered an issue with Asterisk, it seems more like a bug.

I set up a new Asterisk 13.14.1~dfsg-2 installation on Debian 9.1. Everything is working fine. Calls from outside the organisation can reach my phone number and I can call numbers outside of the organisation.

However, after a service stop/start. Outgoing calls do not work anymore and I see the following error in the sip debug:
Call from ‘’ (***.***.***.***:5060) to extension 04XXXXXXXX’ rejected because extension not found in context ‘default’

Now, I can fix this issue, by modifying the sip.conf file (add or remove an extra newline for example) and performing a sip reload. After just adding or removing a newline in the sip.conf, the outgoing calls are working again. So no configuration changes.

Any idea what could be causing this?

Here are the sip.conf and extensions.lua configuration files:

sip.conf:

[general]
defaultexpiry=1800
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
register => *******:******@siptrunk.***.***
disallow=all
allow=ulaw
allow=alaw

[trunk-external]
type=peer
host=siptrunk.***.***
context=incoming
language=fr
insecure=invite,port
fromuser=*********
username=*********
secret=*********
sendrpid=yes
nat=yes
canreinvite=no

[trunk-cucm]
type=peer
host=***.****.com
context=outgoing
canreinvite=no
qualify=yes

extensions.lua:

extensions = {
        incoming = {
                ["s"] = function()
                        app.dial("SIP/trunk-cucm/9060")
                end;
        };

        outgoing = {
                ["_X."] = function(c, e)
                        app.dial("SIP/" .. e .. "@trunk-external")
                end;
        };
}

Thanks!

2

Have you checked the Asterisk log at startup in that scenario to see if there is anything of note?

3

I don’t see anything that could indicate a context or sip configuration issue.
Here is an excerpt of the /var/log/asterisk/messages, during a stop/start:

[Aug 22 15:25:55] Asterisk 13.14.1~dfsg-2 built by buildd @ x86-grnet-01 on a x86_64 running Linux on 2017-06-02 13:20:06 UTC
[Aug 22 15:25:55] NOTICE[15422] cdr.c: CDR simple logging enabled.
[Aug 22 15:25:56] NOTICE[15422] loader.c: 315 modules will be loaded.
[Aug 22 15:25:56] NOTICE[15422] res_odbc.c: res_odbc loaded.
[Aug 22 15:25:57] WARNING[15422] res_phoneprov.c: Unable to find a valid server address or name.
[Aug 22 15:25:57] ERROR[15422] ari/config.c: No configured users for ARI
[Aug 22 15:25:57] NOTICE[15422] pbx_lua.c: Lua PBX Switch loaded.
[Aug 22 15:25:57] NOTICE[15422] res_config_ldap.c: No directory user found, anonymous binding as default.
[Aug 22 15:25:57] ERROR[15422] res_config_ldap.c: No directory URL or host found.
[Aug 22 15:25:57] ERROR[15422] res_config_ldap.c: Cannot load LDAP RealTime driver.
[Aug 22 15:25:57] NOTICE[15422] chan_skinny.c: Configuring skinny from skinny.conf
[Aug 22 15:25:57] NOTICE[15422] chan_sip.c: The 'username' field for sip peers has been deprecated in favor of the term 'defaultuser'
[Aug 22 15:25:57] WARNING[15422] sip/config_parser.c: nat=yes is deprecated, use nat=force_rport,comedia instead
[Aug 22 15:25:57] WARNING[15422] chan_sip.c: !!! PLEASE NOTE: Setting 'nat' for a peer/user that differs from the  global setting can make
[Aug 22 15:25:57] WARNING[15422] chan_sip.c: !!! the name of that peer/user discoverable by an attacker. Replies for non-existent peers/users
[Aug 22 15:25:57] WARNING[15422] chan_sip.c: !!! will be sent to a different port than replies for an existing peer/user. If at all possible,
[Aug 22 15:25:57] WARNING[15422] chan_sip.c: !!! use the global 'nat' setting and do not set 'nat' per peer/user.
[Aug 22 15:25:57] WARNING[15422] chan_sip.c: !!! (config category='trunk-ovh' global force_rport='No' peer/user force_rport='Yes')
[Aug 22 15:25:57] NOTICE[15488] chan_sip.c: Peer 'trunk-cucm' is now Reachable. (2ms / 2000ms)
[Aug 22 15:25:58] NOTICE[15422] confbridge/conf_config_parser.c: Adding default_menu menu to app_confbridge
[Aug 22 15:25:58] NOTICE[15422] cel_radius.c: Cannot load radiusclient-ng configuration file /etc/radiusclient-ng/radiusclient.conf.
[Aug 22 15:25:58] WARNING[15422] cel_pgsql.c: CEL pgsql config file missing global section.
[Aug 22 15:25:58] NOTICE[15422] cel_custom.c: No mappings found in cel_custom.conf. Not logging CEL to custom CSVs.
[Aug 22 15:25:58] NOTICE[15422] cdr_pgsql.c: cdr_pgsql configuration contains no global section, skipping module load.
[Aug 22 15:25:58] NOTICE[15422] cdr_radius.c: Cannot load radiusclient-ng configuration file /etc/radiusclient-ng/radiusclient.conf.
[Aug 22 15:25:58] NOTICE[15422] cel_tds.c: cel_tds has no global category, nothing to configure.
[Aug 22 15:25:58] WARNING[15422] cel_tds.c: cel_tds module had config problems; declining load
[Aug 22 15:25:58] NOTICE[15422] pbx_ael.c: File /etc/asterisk/extensions.ael not found; AEL declining load
[Aug 22 15:25:58] WARNING[15422] channel.c: Already have a handler for type 'Console'
[Aug 22 15:25:58] ERROR[15422] chan_oss.c: Unable to register channel type 'OSS'

Except for some warnings, I don’t see any real errors.

Do you see anything which could be problematic?

4

Nothing stands out. You might try looking at the output of the various sip commands for examining the loaded configuration before and after you do the reload to see what changes to narrow it down.

5

Specifically you may want to see if the IP address isn’t what it should be on startup.

6

Aha, that was a good idea.

After comparing the before and after state, using the sip commands, I think the issue has been found.

After a stop/start, Asterisk seems to set up a sip trunk with our secondary call manager. When the sip.conf is modified and a sip reload is performed, it initiates the sip trunk with the primary call manager this time.
The hostname which is specified in the sip.conf translates to a “loadbalanced” IP, which is probably causing issues.

7

The chan_sip module will only resolve to a single IP address, so you’re better off creating two peers each with an explicit IP address.

8

Ok, problem found.
Thank you for your help.

I’ll create two peers in the sip.conf, one for each.
I guess it will be possible for incoming calls to try one peer and if it’s not available, try the next peer?

9

If you mean placing a call from Asterisk outward to those, that’s up to you and your deployment. It can do that if you want.