It has been almost a week trying to sort this out with no luck!
I have FreePBX 15 with two NICs:
eth0 : LAN, 192.168.0.253/24, GW 192.168.0.1 (internet connected).
eth1 : SIP, 10.15.61.222/30, No GW set but static routes to the VSP network.
I am using PJSIP trunk wit the following settings:
Trunk name : du.ae
Username : myusername provided by VSP
Secret : mysecret provided by VSP
SIP Server : du.ae
Context : from-trunk
Outbound Proxy : sip:10.59.108.25
From Domain : du.ae
Send RPID/PAI : Send P-Asserted-Identity header
The SIP trunk registers successfully and I can see inbound calls but outbound calls fail.
I am suspecting routing but don’t know where further to look.
I prepared a call attempt log to attach but “Sorry, new users can not upload attachments”.
Appreciate if someone could please offer a little help?
Try setting Outbound Proxy to sip:10.59.108.25\;lr\;hide
and From User to the same value you have in Username. Retest.
If no luck, at the Asterisk command prompt type pjsip set logger on
make a failing call attempt, paste the relevant section of the Asterisk log at pastebin.com and post the last eight characters of the URL.
The behavior has changed; now the call drops in few seconds and I can see the following in the log:
ERROR[24441] res_pjsip.c: Endpoint ‘du.ae’: Could not create dialog to invalid URI ‘du.ae’. Is endpoint registered and reachable?
ERROR[24441] chan_pjsip.c: Failed to create outgoing session to endpoint ‘du.ae’
NOTICE[12853][C-00000044] app_dial.c: Unable to create channel of type ‘PJSIP’ (cause 3 - No route to destination)
Very strange. On line 8 of the log, it shows the trunk becoming unreachable (no response to OPTIONS), possibly because of a configuration error, momemtary network issue, or delay exceeding the default 3-second timeout on OPTIONS. Since the trunk was unreachable at the time of the call attempt, the call was not sent.
But you show more than 2 minutes of log, and pjsip would normally retry every minute (Qualify Frequency default is 60). There is no sign of a retry attempt. Also, the log started 30 seconds before the ‘unreachable’ event, so the failed qualify event should also have been shown.
My guess is that pjsip logger was not on (note that Apply Config or other reload events turn it back off), or that a problem in the trunk settings prevented any OPTIONS request from being sent.
When you type ‘pjsip set logger on’ at the Asterisk command prompt, ‘PJSIP Logging enabled’ should be the response.
Looking at a larger section of the log, do you see the trunk becoming reachable and unreachable repeatedly? Or did it just go unreachable and stay that way? Please post a screenshot of the Advanced page of the trunk settings, and paste another log of a call attempt, if you can make one while the trunk shows reachable.
The trunk shows Registered when I issue the command pjsip show registration du.ae
I did try again and the call log is in “AmCkR4bn”
And here are the screenshots:
Two more screenshots will be added separately since it does not allow me to put more than one.
It might be trunk settings since what we did receive from the VSP is a bit confusing as we don’t see host IP/name. A proxy only.
Original settings received are:
CUSTOMER IP 10.15.61.222 (this is set as eth1 IP)
MASK 255.255.255.252
GATEWAY 10.15.61.221 (I did not set the gateway to the interface since eth0 has one and connected to the internet, instead I did static routes)
USERNAME xxxxx
PASSWORD *****
SBC/HOSTNAME fixedimsmey.duentdxb.duvoip.fmc (This did not work so VSP provided IP 10.59.108.25. Setting it as SIP server, registration gets rejected. Then from their replay to my email the VSP mentioned that the From should be [email protected] therefore I put du.ae in SIP server which did register successfully)
DOMAIN du.ae
DNS IP 10.62.215.44
PORT 5060
SIP RFC 3261
CODEC PRIORITY G711 (PCMA)
DTMF RFC2833 / G711 In Band
On line 319 of the paste, pjsip saw that the trunk was unreachable and didn’t attempt the call.
Possibly, there is no response to OPTIONS or for some reason they aren’t being sent.
There is only 6 seconds of log so it makes sense that we don’t see any.
Looking at a larger section of the log, do you see any reachable/unreachable events? Any OPTIONS requests? Any replies?
Assuming that registration is ok, you could try setting Qualify Frequency to 0, which means don’t attempt to qualify. Then, try a call which should be sent on the trunk and we can see what response, if any, we get.
Strange. On line 786 of the paste, the trunk sent a BYE indicating no error, as if the destination mobile was simply hung up. When the mobile was answered, was there good audio in both directions? Did audio stop flowing some time before the disconnect? Did the mobile show a disconnect at the time the log showed it? Do incoming calls stay connected? Possibly, the mobile initiated the disconnect because it thought something was wrong with the media. Do calls to landline numbers disconnect the same way?
No audio in both incoming and outgoing, inbound calls are also dropped after 60sec.
One more thing I noticed, in outgoing, DID number is not presented but the pilot number only! I tried different formats in the Outbound CID but always the same.
A little progress…
I am now trying the chan_sip trunk. I can make outbound call but it drop after 19sec and I can see “407 Proxy Authentication Required” for every register attempt.
For incoming, calls are reaching FreePBX but giving “No matching peer”
Some logs in “myrntiPe”
Also, for one time only, I was able to do a successful outbound call with above settings and hang up after more than 4min. then, I can’t really understand what is going on
Another progress…
With above settings, I did a restart; “fwconsole restart” and everything did work! I still did not figure out what was the issue but now only the pilot number is reflecting in outbound calls. And also for inbound calls all are landing to the inbound route of the pilot number
I did try the same format that we are receiving on external numbers along with several different formats but no luck.
You seem to have made many changes, so it is not clear about the present state. The incoming call had xxx4601 in both the URI and To header (I assume that xxx4600 is the pilot), so it’s not clear why inbound routing is not working. Also, it was sent to port 5060 and captured (but not recognized) by chan_sip. I would have expected pjsip Port to Listen On at 5060 and chan_sip Bind Port at 5160. Did you have to turn on Allow SIP Guests for incoming to work?
For outgoing (with chan_sip), try setting sendrpid=pai
and using a caller ID starting with 048
However, IMO you shouldn’t be going further down the chan_sip rat hole, because when you try to upgrade the system it will likely be gone. Does the pjsip trunk still have no audio but work otherwise? From a root shell prompt, please post the output of ip route
Hello Stewart and thank you for responding.
Sorry, I was away for a while getting some rest
Audio still not working with Chan_PJSIP and I was short in time, frustrated and exhausted therefore I swapped the ports and used Chan_SIP on port 5060 where I was able to get the trunk working as mentioned in my previous post. I would love to get chan_pjsip to work thou.
I found in one post a suggestion to use context
from-pstn-toheader
which did the trick for incoming; calls to a specific DID are now following the inbound routes and landing to designated extension.
However, outbound calls are still showing the pilot number when reaching the external destination! Of course, I added “sendrpid=pai” to chan_sip trunk outgoing configurations and already using the DID format you suggested.
ip route output is in the following:
default via 10.15.61.221 dev eth1
5.0.0.0/8 via 10.15.61.221 dev eth1
10.0.0.0/8 via 10.15.61.221 dev eth1
10.15.61.220/30 dev eth1 proto kernel scope link src 10.15.61.222
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.253
217.160.0.0/16 via 10.15.61.221 dev eth1