Can not register SIP Trunk to Service Provider

Greetings to All.

Previously we have an E1 line that is connected to FreePBX and various trunk links that are working fine for long time, but recently we have deployed new SIP line from our service provider, they have told us to directly connect a computer to the new GPON Modem that the provider deployed and configure MicroSIP Softphone software by the following parameters in order to check if the new SIP line is working:

SIP Server: ims.serviceprovider…
SIP Proxy: 10.xx.xx.xx
Username: [email protected]
Domain: ims.serviceprovider…
Password: sample_password

By configuring the above parameters to the MicroSIP softphone it works perfectly for both outbound and inbound calls and they have told us we have registered successfully, but the SIP Trunk to our service provider in FreePBX is not working and we can not register. Here is the trunk configuration in SIP Trunk

[email protected]

Register string is: [email protected]…:sample_password/+251xxxxxxxxx

The trunk is not working and I am getting this error in the log

[2024-05-01 16:39:18] ERROR[2654]: netsock2.c:303 ast_sockaddr_resolve: getaddrinfo(“”, “(null)”, ): Name or service not known
[2024-05-01 16:39:18] WARNING[2654]: acl.c:890 resolve_first: Unable to lookup ‘
[2024-05-01 16:39:18] WARNING[2654]: acl.c:1029 ast_ouraddrfor: Cannot connect to (null): Invalid argument

I try to set the proxy IP as a DNS server for the FreePBX but same error occur, and I also try to use the username as “[email protected]…” and “+251xxxxxxxxx” but not working again.

Here is a traffic flow from Wireshark

Would you have any recommendations for resolving this problem, thanks you for your time and assistance.

Chan_sip is an obsolete driver; you should normally be setting up a pjsip trunk. However, if you are running an old version of FreePBX or Asterisk and there are good reasons why you can’t upgrade, we can try to make chan_sip work. FreePBX and Asterisk versions?

In chan_sip, note that the outboundproxy parameter does not apply to the Register String. For that, you should use (for example):
[email protected]…:[email protected]:5060/+251xxxxxxxxx

Normally, the 423 should have Asterisk respond with a longer expiry, but based on the timing shown, I suspect that it wasn’t processed and you are just seeing retransmissions. What does the Asterisk log show for these attempts?

The chan_sip module itself will only go so far with outbound proxies, specifically it resolves all the involved hostnames which can be problematic so you have to work around that at times.

@ is not valid in SIP usernames. I’ve forgotten how chan_sip handles it, but I believe the only way of sending it with chan_pjsip, is correctly escaped as %40. Are you sure this is just the user name?

Thank you all for your response.

The Asterisk and FreePBX version is:
Asterisk Version: 18.16.0
FreePBX Version: 16.0.33

I set the registry string as you indicate, now the error changed to “Wrong Password”, I used the same password that I used for the MicroSIP:
Link to screenshots

And the traffic flow is:

I don’t understand why the does not appear in the From header, nor in the username field of the Authorization header, even though your first post clearly shows

However, your first post also shows port 5060 on the Asterisk side (chan_sip Bind Port set to 5060), but your latest screenshots show port 5160. For your version of FreePBX and Asterisk, 5160 is the default for chan_sip. So it appears that some things have changed. Can you please explain, and post your current settings? If we can’t resolve this quickly, we should set up a pjsip trunk.

Sure to make things easier we can set up PJSIP Trunk

My current setting is that is working in MicroSIP Softphone is:

SIP Server:
SIP Proxy: 10.xx.xx.xx
Username: [email protected]
Password: sample_password

Server Settings (The FreePBX server is directly connected to the GPON Modem that the provider deployed):

Asterisk Version: 18.16.0
FreePBX Version: 16.0.33
IP Add: 192.xx.xx.8
Gateway: 192.xx.xx.1
chan_pjsip port: 5060
chan_sip port: 5160

Based on another IMS working example, try this Register String. If it fails we will go to pjsip:

[email protected]:sample_password:[email protected]@10.XX.XX.XX:5060/+251xxxxxxxxx

Please post new sip debug output.

1 Like

Hello again, I see your previous post for another person while you indicate him to try the following parameters for PJSIP Trunk and it works

It can now send call perfectly, the problem is when I call back to the number I get the following error in the log

[2024-05-01 21:24:04] ERROR[14779][C-00000017]: pbx_functions.c:651 ast_func_read2: Function SIP_HEADER not registered
[2024-05-01 21:24:04] WARNING[14779][C-00000017]: Ext. s:3 @ from-pstn: Friendly Scanner from

And the FreePBX will respond by saying “The number you dialed is not in service…”

Confirm that the value of Contact User matches the value of DID in your Inbound Route.

Also, in Match (Permit), put the 10.xx.xx.xx address.

If no luck, post log with pjsip logger turned on.

Thank you Stewart, the problem was the Inbound Route DID numbers are not matching, when I set the DID number to any; calls came in, but when I set to +251xxxxxxxxxx, 251xxxxxxxxxx and 0xxxxxxxxxx it did not work, when I try to set the context to “from-pstn-toheader” and “any” in Inbound Route the DID number in the CDR report shows the DID number as “+251xxxxxxxxx>” not Inbound DID is still not matching, other wise the CDR report shows the DID number as “DID: s”.

We have 10 numbers that came in from the SIP line, so I can not use “any” for the Inbound Route DID.


does not match


(not enough or too much love :slight_smile: )

The exact number that we use for the outbound calls do not match in the inbound route, when inbound call came FreePBX reply with

[2024-05-01 21:24:04] ERROR[14779][C-00000017]: pbx_functions.c:651 ast_func_read2: Function SIP_HEADER not registered
[2024-05-01 21:24:04] WARNING[14779][C-00000017]: Ext. s:3 @ from-pstn: Friendly Scanner from

But when we set the inbound route DID number blank (any) calls came in to specified destinations as intended.

In the CDR report the DID number is shown as “DID:s”, when context is changed to “from-pstn-toheader” the DID number is correctly displayed; but still the Inbound Route DID number have to be set to any in order to accept calls, as I mentioned earlier we have 10 phone numbers, so each number must have different destinations, as a result I can not use any as DID for inbound routes.

For our other E1 line that we still use; we specify the DID as 0111xxxxxx (without +251) and it perfectly works.

Any idea?


Set Context to from-pstn-toheader.
Set a temporary Inbound Route with DID number any.
Call in and look at the DID shown in the CDR.
Set an Inbound Route with DID Number exactly as it appears in the CDR (copy/paste to be sure).
Test. If you still have trouble, turn on pjsip logger, make a call that fails to route correctly, paste the Asterisk log for the call (including the incoming INVITE and Asterisk’s processing) at and post the link here.

1 Like

The problem regarding Inbound Route was; the DID number have “>” sign at the end of the DID number in the CDR report, so when I set the DID for the Inbound Route with the following pattern it start working properly:


I’d like to express my sincere gratitude to @Stewart and all those who have generously provided their time and expertise.

In the spirit of knowledge sharing, I’m would like to provide the summarized configuration details that have proven successful for me. This information may be helpful for others encountering similar challenges.

  1. In this configuration, a computer with MicroSIP softphone installed is connected directly to a GPON modem. The following details outline the successful setup for this scenario.

MicroSIP Softphone Parameters:

SIP Server:
SIP Proxy: 10.xx.xx.xx
**Username: [email protected] ***
Password: sample_password

  1. Configuration for a PJSIP trunk within FreePBX

PJSIP Trunk Configurations

Connectivity → Trunk → Add SIP (chan_pjsip) Trunk
Under General Tab
Trunk Name: PJSIP_01

Under pjsip Settings Yab → General Tab

Username: +251xxxxxxxx1
Secret: sample_password
SIP Server:
Context: from-pstn-toheader

Under pjsip Settings Yab → Advanced Tab

Outbound Proxy: sip:10.xx.xx.xx:5060;lr
From Domain:
From User: +251xxxxxxxx1
Match (Permit): 10.xx.xx.xx

I add the following parameters in the “/etc/asterisk/pjsip.auth_custom_post.conf” file

[PJSIP_01] (+type=auth)
[email protected]

For the Inbound Route I have used the following pattern for the DID Number:


Thank you everyone again.

1 Like

Sure, could you please provide the versions of FreePBX and Asterisk you’re currently using? This will help determine the best approach for resolving the issue with chan_sip.

Glad to hear that you got it working.

I believe that editing pjsip.auth_custom_post.conf should no longer be needed. Recent FreePBX added an Auth username setting for trunks, which you could set to
[email protected]
to accomplish the same thing.

Could you please show the To header that Ethiotelecom is sending? It may not be malformed, but in a format that the from-pstn-toheader code does not handle correctly. If so, reporting a bug would be useful.

I am currently using the following versions
Asterisk Version: 18.16.0
FreePBX Version: 16.0.33

When I use the register string @Steward1 recommend:

[email protected]:sample_password:[email protected]@10.XX.XX.XX:5060/+251xxxxxxxxx

SIP is registered but outbound call is not working and I get the following error in the log (sip set debug on)

[2024-05-03 21:13:20] NOTICE[9582][C-00000010]: app_dial.c:2707 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
Really destroying SIP dialog ‘[email protected]:5160’ Method: INVITE

But I can not see any log in for Inbound calls (even no traffic in Wireshark)

Thanks @Stewart1, instead of editing “/etc/asterisk/pjsip.auth_custom_post.conf” file; when I set the Auth Username parameter “[email protected]” it works perfectly. Thank you again (you made my day).

Regarding the “to header” here is the log from the server for incoming calls

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