PJSIP Trunk, inbound calls are working but not outbound

Greetings,

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”. :slightly_frowning_face:

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.

Thank you Stewart,

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)

Full call log is in “0MA2FCWi”

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.

Yes indeed, I can see this - although the trunk status shows Registered:

[2023-08-15 20:07:46] VERBOSE[1787] res_pjsip/pjsip_options.c: Contact du.ae / sip:97148184600p @ du.ae:5060 is now Unreachable. RTT: 0.000 msec

Then these repeated attempts

[2023-08-15 20:08:48] VERBOSE[9619] res_pjsip_logger . c: <— Received SIP response (774 bytes) from UDP : 10.59.108.25 : 5060 —>
SIP / 2.0 504 Server Time-out
Call-ID: 900b58e1-9856-4562-8fe2-f8f3306c93d2
Via: SIP / 2.0 / UDP 10.15.61.222 : 5060;received=10.15.61.222;branch=z9hG4bKPjfaaa83e4-2f65-4aee-9996-ec7bd871735b;rport=5060
To: <sip : 97148184600p @ du.ae>;tag=648227c2-64dba310e4b66f2
From: <sip : 97148184600p @ du.ae>;tag=15d22fb5-a3b6-43dd-9e13-6e94bffa158d
CSeq: 41262 OPTIONS
Date: Tue, 15 Aug 2023 16:08:48 GMT
Content-Length: 228
Content-Type: application / 3gpp-ims+xml
P-Asserted-Identity: <sip : 10.59.108.25 : 5060;lr;ottag = ue_term;bidx=152625720;access-type=ADSL>

<?xml version="1.0" encoding="UTF-8"?>


restoration
PCSCF routing to the next hop failed
initial-registration

[2023-08-15 20:08:54] VERBOSE[9718] chan_sip.c: Really destroying SIP dialog ‘L2J2IGHic4hcrPQbiP04ag…’ Method: REGISTER
[2023-08-15 20:09:04] VERBOSE[9718] chan_sip.c:
<— SIP read from UDP : 192.168.0.248 : 64433 —>

But, after setting qualify to 0, the call went through but dropped after 20 sec. Log is in “yJXvjske”

pjsip logger was not on; it was probably turned off when you reset the Qualify Frequency.
Please turn it back on and paste another log.

Sorry for that.
Here it is “9yUdGerd”

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.

The media server addresses are different from the SIP server address. Confirm that the OS route includes the address range.

For the caller ID issue, look at an incoming call and use the same format and headers for outgoing.

I was trying legacy sip to see if any difference. The trunk status shows OK but when dialing; 407 Proxy Authentication Required.

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”

Trunk Settings:
Outgoing:
host=du.ae
outboundproxy=PROXY_IP
type=peer
qualify=yes
fromdomain=du.ae
fromuser=USERP
realm=du.ae
username=USERP
context=from-pstn
auth=USERP
secret=SECRET
Insecure=invite,port
dtmfmode=rfc2833
directmedia=no
canreinvite=no
disallow=all
allow=ulaw

Incoming:
[email protected]:SECRET@PROXY_IP/PILOT_DID

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 :confused:

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 :slightly_frowning_face:

I did try the same format that we are receiving on external numbers along with several different formats but no luck.

Any ideas please :pray:

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

You don’t need to be root to do this.

Hello Stewart and thank you for responding.
Sorry, I was away for a while getting some rest :sleeping:

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

Should I share another outbound call log?