PJSIP Trunk, inbound calls are working but not outbound

FreePBX Providers
, ,
21

I missed to answer this: Yes, I had to turn Allow SIP Guests on.

Now I am pulling out my hair - or what is left of them. :weary:
Outbound calls are dropped after 20 seconds exactly. I did not change anything!!
I can see the following in log:

SIP/2.0 407 Proxy Authentication Required
Call-ID: [email protected]:5060
Via: SIP/2.0/UDP 10.15.61.222:5060;received=10.15.61.222;branch=z9hG4bK1bd94ddd
To: sip:du.ae;tag=648271db-64de964334563153
From: “Unknown” <sip: my user @10.15.61.222>;tag=as23e46dfd
CSeq: 102 OPTIONS
Warning: 399 sbc.du.com “IP association no match, user not registered”

Inbound are still working fine and routing as expected.

22

Depending on the provider, outbound caller ID is handled in 3 ways. Simplest is in the From header. I don’t think that will work, because you have (and presumably need)
fromuser=USERP
You can try removing that and see whether outbound calls still work. If so, caller ID might work.

Next is in the P-Asserted-Identity header. Unfortunately, you have already tried that and it didn’t help. But confirm (with pjsip logger) that you are indeed sending this header correctly.

Unfortunately, some providers require you to send both the pilot number and the desired caller ID with each call. The idea is you must declare “I’m sending [desired CLI] on behalf of [pilot number]”. There is usually a Diversion header involved, but the exact rules vary by provider. If Du is one of these, they should supply documentation as to what is needed, or at least an example of a valid INVITE. If they haven’t and you can’t find it online, I suggest opening a ticket with them.

I’m very puzzled about outbound calls dropping. If it’s for lack of RTP, there would also be no or one-way audio on these calls. The other is ACK (to their 200 OK) not being properly sent, but it’s hard to see why that would happen. A complete log of the call (including sip debug) may be useful.

Your present routing seems to be sending everything over the private network; AFAICT there is no internet access at all. You couldn’t have any external extensions, or even update the software. If this is the case, we need to sort out what routes are required.

I don’t understand why chan_sip is not recognizing the outboundproxy address for the incoming call, making it look like a ‘guest’. You could force that with a separate entry, in /etc/asterisk/sip_custom.conf, add something like:

[Du-in]
disallow=all
allow=alaw
host=10.59.108.25 (use actual address they send INVITE from)
type=friend
insecure=port,invite
context=from-pstn-toheader
canreinvite=no
qualify=no

I’d like to revisit pjsip; perhaps some of the changes you made will cause audio to work. If not, it shouldn’t be hard to troubleshoot, because we have a working example (with chan_sip) for comparison.

23

Thanks again Stewart, I will try all and send logs.

Regarding the routes, I started with simple routing for 3 IPs but noticed in the log different server responding every time I test a call therefore I ended up without internet access and full routing rules to their networks just to eliminate the chance of routing problems while testing.

But for the reference, when we asked the provider to support they sent a technician with a small Grandstream box, he put the settings and all went fine.

Anyway, I will follow your suggestions and send the updates.

24

Awesome. Please post all of the settings used for the Grandstream trunk (including settings not specific to your account). Screenshots (or even photos) will do if that’s all you can get.

25

Hi again,

I could not get screenshots from the Grandstream but I was able to see what was done:
Set IP 10.15.61.222/30, DNS 10.62.215.44 and gateway 10.15.61.221 to the SIP interface.
Then in the trunk settings:

USERNAME xxxxx
PASSWORD *****
SBC/HOSTNAME fixedimsmey.duentdxb.duvoip.fmc
DOMAIN du.ae
RFC3261
CODEC G711 (PCMA)
DTMF RFC2833
Then outbound route is set and it is working.

In my FreePBX, I tested removing fromuser which did the trick and now I can see the DID coming on the external phone; however, outbound calls are till dropped once reaching 20s exactly.

Anyway, I did return all configurations to the proper settings, I have internet now, I did more specific routes, PJSIP is now on port 5060, disabled chan_sip trunk and created a chan_pjsip trunk.

The trunk shows registered and I am able to dial in and receive calls correctly; However, outbound calls are dropped once reaching 20s again!

Trunk settings are in the following:

Username: [USERP]
Secret: ****
SIP Server: du.ae
Context: from-pstn-toheader
DTMF Mode: RFC 4733
Qualify Frequency: 0
Outbound Proxy: sip:[proxy_ip];lr;hide
From Domain: du.ae
Client URI: sip:[USERP]@du.ae:5060
Support Path: Yes
Trust RPID/PAI: Yes
Send RPID/PAI: PAI

Outbound call log is here “Rpv7gv1e”

Thank you for the time you are sparing to assist me.

26

What’s 10.59.108.25? You got normal clearing from it as the first time that address appears in the log.

If it is your router, turn off SIP ALG in the router.

27

There is a problem with selecting the proper transport for the trunk. In the INVITE starting on line 343 of the paste, the Via and Contact headers, and the c attribute of the SDP all show your public (internet) IP address. They should have the address of the SBC interface.

Confirm that in Asterisk SIP Settings, chan_pjsip tab, you have two UDP transports defined, one for each NIC.

At the Asterisk command prompt, type
pjsip show transports
You should see two entries, one of which (I think) should be 10.15.61.222-udp.
Then type
pjsip show transport 10.15.61.222-udp
(use the actual name if I got it wrong)
and confirm that external_media_address and external_signaling_address are correct.
If not, in Asterisk SIP Settings, try setting External IP Address for the transport.
Finally, in the trunk settings, confirm that Transport is correctly set.

Changing anything in the above requires restarting Asterisk, after doing Submit and Apply Config.

28

10.59.108.25 is the outbound proxy IP.

The transport was set to 0.0.0.0-ALL, I set it to NO and enabled the individual transports of each NIC.
I also set the transport to 10.15.61.222-udp in the trunk settings.
external_media_address and external_signaling_address were still showing the public IP when issuing show transport command so, I set External IP Address for 10.15.61.222-udp transport to the SIP interface IP address.

After restarting (fwconsole restart) it is the same; outbound calls are dropped after 20s.

Log is here “DZbYMxTy”

29

I am puzzled because the signaling now looks correct, but I assume that you still have no audio, which would explain the drop. If you have audio in either direction, post details.

While there shouldn’t be a problem transcoding between ulaw and alaw, let’s eliminate that first. Set the codecs for both the trunk and extension to allow only alaw. Also, in Zoiper, do the same (it may be called PCMA or G.711 a-law).

Confirm that 10.59.109.78 still routes via your 10.15.61.222 interface.

Confirm that you are connecting to the same address. At a root shell prompt, type
dig fixedimsmey.duentdxb.duvoip.fmc @10.62.215.44
and post the output. This assumes that 10.62.215.44 routes via your 10.15.61.222 interface; add a route if not.

If none of the above show the trouble, the next step is to capture traffic with tcpdump to see why audio isn’t being properly sent and/or received.

30

I did set the all to use a-law then did a try. The first outbound call after Apply Config worked but the next call onward dropped at 20s! Someone inside the trunk is playing games :sweat_smile:

I posted the successful call log here “B0suAnJy”

I can see the traffic routed through 10.15.61.222 interface. In the following is the dig command output - I am using the IP anyway to avoid DNS issues:

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> fixedimsmey.duentdxb.duvoip.fmc @10.62.215.44
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12501
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;fixedimsmey.duentdxb.duvoip.fmc. IN A

;; ANSWER SECTION:
fixedimsmey.duentdxb.duvoip.fmc. 300 IN A 10.59.108.25

;; Query time: 11 msec
;; SERVER: 10.62.215.44#53(10.62.215.44)
;; WHEN: Tue Aug 22 00:13:19 +04 2023
;; MSG SIZE rcvd: 76

I will do tcpdump later today and post it.

31

Sorry, I couldn’t spot any difference in the successful paste that seemed relevant.

Since the extension’s audio should be on eth0 and the trunk’s on eth1, it would be useful to see both.
You could try initially for example
tcpdump -i any -w foo.pcap
I hope that we can distinguish which interface a packet was sent from by MAC address. If the capture is ambiguous we may need to run two simultaneous tcpdump instances, one on each interface.

You can attach a .pcap file to your post, but please note that the only type of binary attachment allowed is a .tgz file. You can tar the .pcap into a .tgz, or (since the forum doesn’t actually look at the contents of the file), you can simply rename the .pcap to a .tgz, even though it’s really still in pcap format.

32

Well, a routing issue is what I am suspecting while behavior keeps fluctuating. Incoming calls were going fine one time then not another time while outgoing keeps dropping; therefore, yesterday I set a gateway again to the SIP interface in despite of static routes which did help in stabilizing incoming calls with audio flawing but outbound calls remained the same and FreePBX is unable to get updates from the internet.

Then I sent my previous post late at night and left home to come back on duty and find everything is working, inbound and outbound, with clear audio! However, when dialing in some calls will get “The number is not in service” (This message is coming from the VSP which indicates that the line is not attached to a PBX or ONU is off) but trying again, the call will go through.

I am putting a link to download the tcpdump which includes two files; one captured during incoming call and one during outgoing. I could not point to the issue but hoping that you can to help me understanding what is going on.

https://icw.li/3hCcDJRSR

Many thanks in advance,

33

I took only a brief look / listen to the Outbound_dump.pcap file because I noticed two layers of complexity of which I was previously unaware.

One is virtualization. The PBX is running in a VMware guest, is that correct? Although it appears to be using bridged networking, which is usually super reliable, there is still a possibility for trouble; it may be useful on failed calls to capture traffic on the host.

The other, which I believe is the more likely culprit, is TLS and media encryption on the extension side. Possibly, Asterisk is sometimes failing to decrypt the audio, passes nothing to the trunk, so the call drops.

Can you do some testing with Zoiper using SIP over UDP and unencrypted media? Do you have other types of extensions on the system (IP phones, other softphone or SIP apps, etc.)? Do calls between extensions ever have trouble?

Lots of possibilities here. First, I’d run sngrep and see whether anything shows up for the failed call. If nothing, does anything appear in a packet capture on the host? If also nothing, see whether the last registration had the correct Contact header and got a 200 OK response.

Please provide a description of the overall system (virtualization setup, number and types of extensions, any trunks other than the Du trunk causing trouble, etc.)

34

Thank you for your response Stewart.

Indeed, FreePBX is running as a guest VM on VMware7 host (HP ML30).
The server is hosting two VMs; FreePBX and a tiny WIN7 for remote support.
Two NICs are available; one is dedicated to SIP and connected directly to the ONU, the other is for LAN. Two vSwitches created for each.
There are 5 client computers on the LAN with Zulu UC, Zoiper is only on the remote machine for testing, and Du is the only trunk.
Internal calls are flawing perfectly since the setup was done. No issues were noticed or reported.
TLS is disabled in FreePBX for both chan_sip and chan_pjsip. Also, Zoiper is the free version where TLS is not available/disabled.

I will have to monitor and do packet capture on the host and post the update.

35

Sorry, I had assumed that the call was made from Zoiper, since all your previous testing was using it.

The call was made from Zulu on 192.168.0.239. As both the signaling and audio are encrypted, and I didn’t have the Asterisk log, there is very little I can tell about it, other than the trunk activity it invoked. Of course, since this call was successful, this lack of data may be unimportant.

If some Zulu calls fail, we can look for differences from this capture. Possibly, with the aid of logs from both Zulu and Asterisk we can figure out what went wrong, in spite of the encryption. If not, and you can’t get unencrypted calls to fail, perhaps another member can help you out, as I know nothing about Zulu.

36

Thank you for all your efforts Stewart!

Just want to ask, apart from Zulu and knowing that all my tests are done on Zoiper, do you see any issue in routing or traffic flawing that I am unable to point to?

It is working so far since yesterday but not all calls are coming in, some callers are getting “Out of service” message from the provider immediately when they call so I am trying to understand whether the trunk connectivity is not stable or a provider issue is there to log a support ticket about.

This provider is so unresponsive and not supportive therefore I am trying to be very specific to them about the issue or to sort it out without their help.

Another small detail that I forgot to mention in the beginning is that all calls are dialed to an 800 (Toll free) number and forwarded to our sip trunk number. I don’t think that this might be an issue thou.

37

Approximately what percentage of incoming calls fail? If it’s fairly high, e.g. 20% or more, you should be able to at least occasionally see a failure calling in from your own mobile and trace what happened.

If low, you could try running a continuous capture. When a failure is reported, look at what, if anything, was received about that time. See

If some failed calls occur while other calls are in progress and continue normally, unstable trunk connectivity is very unlikely.

If all failed calls occur while other calls are in progress, possibly the provider is not allowing as many concurrent calls as your contract specifies. You may be able to demonstrate this by having several associates call in from their mobiles at the same time.

Does Du provide a call log on their portal? If so, what, if anything, appears there for failed calls?

38

Hi Stewart,

Inbound calls that fail do not reach the PBX at all and are for a specific numbers all the time. It was VSP issue and they did solve it. But now, the outbound calls issue remains!

All outbound calls dropped at exactly 20s and I am suspecting NAT or routing issues here.
Currently, “Detect Network Settings” did not help; now no IP showing in external address and all networks including those in the static routes are listed under local networks.
The SIP NIC is connected directly to the ONU, no firewall at our end.

I also tried to set RTP “Reinvite Behavior” to nonat but didn’t help and I didn’t expect it to do since it is chan_sip setting.

RTP Keep Alive and RTP timeout the same.

Log is at “AU0Xf7fc”
Any hint?

39

The call was cleared from the remote side:

Reason: X.int;reasoncode=0x00000000;add-info=05CC.0001.0001
Reason: Q.850;cause=16
P-NOKIA.Traffica: S1;i="LU-1692962638325242-15630370@ftasdxb01.ims.mnc003.mcc424.3gppnetwork.org-5060-93"

The Q.850 reason is normal end of call. I don’t know how to decode the proprietary information.

40

Insufficient info. Looks no different from others you have posted (signaling is ok).

Please post a .pcap file for a failing call made from an unencrypted extension, as well as the Asterisk log (including pjsip logger). Note whether any audio heard in either direction.