PSTN forwarding with Voxbeam: "403 Forbidden"

[200765 (Alberto Amori)]

FreePBX 16.0.40

I have the same configuration described in PSTN forrwarding not working

• an extension (10003)
• a SIP trunk, which is registered to a SIP provider (voipchief) to give access to the PSTN.
• an outbound route matching any dial pattern, linked to the SIP trunk

I have set the call forwarding of a DID number (provided by DIDWW) to this extension.
I have registered a SIP phone to the extension 10003, and I called the DID number.

My goal is that the PSTN number is dialed out, if the extension is not reachable.
This time I have used the voxbeam provider in the outbound trunk.
I have written the IP address of my Freepbx VPS in the allowed list in my Voxbeam account
I have used the prefix 0011103 (silver routes) in the outbound trunk.
The call is rejected with “403 Forbidden”

Here is the full logfile:

[root@freepbx ~]# tail -f /var/log/asterisk/fullTo:

What may I have done wrong?

[dobrosavljevic (Igor Dobrosavljevic)]

I haven’t looked through the log but are you trying to pass the Caller ID of the call that you are trying to forward? Is your provider blocking the call because you are not authorized to use that caller ID as your outbound caller ID?

[200765 (Alberto Amori)]

@dobrosavljevic

I haven’t looked through the log but are you trying to pass the Caller ID of the call that you are trying to forward?

Yes, I am propagating the original CID, because it is important that the recipient of the call can see who is actually calling. I would expect that a provider Voxbeam allows it. I contacted their support but so far no answer.

[dobrosavljevic (Igor Dobrosavljevic)]

@200765

I would expect that a provider Voxbeam allows it.

Why would you expect that? This is a major problem with spam calls being able to spoof Caller IDs and providers and governments have been cracking down on it. It’s very likely that your provider is blocking the call because it’s not your Caller ID to be used.

[Stewart1 (Stewart)]

My test call used the most conservative settings, Platinum route, From and P-Asserted-Identity as +4171…, no Diversion header. Did you see the 071… caller ID?

If this worked as you desire, you could try with a less expensive route.

Or, if Voxbeam proves to be unsuitable for your application, we could test with some other trunking providers.

[david55]

@200765

Yes, I am propagating the original CID

No you are not. That is the first thing I considered and I checked.

(I agree with the cautions about the difficulty of doing what you want in a post phone scam world, as you need to go through hoops, even if the provider allows it at all.)

[200765 (Alberto Amori)]

@Stewart1

Did you see the 071… caller ID?

Yes I did. This means that Voxbeam doesn’t restrict the CID.

[Stewart1 (Stewart)]

@david55

No you are not. That is the first thing I considered and I checked.

You are correct. The OP was complaing about a 403 error, so I looked at what he sent to get the 403. Testing with cleaned up data and a more expensive route, the call went through, so I thought the problem was solved. I retested using the original TIM mobile number.

I got an error in the early media about invalid number, but it failed over and started to ring. Was the TIM number shown?

[200765 (Alberto Amori)]

@Stewart1

Was the TIM number shown?

Yes it was. Your freepbx+voxbeam works but mine doesn’t.

[200765 (Alberto Amori)]

Sorry, it looks like there was a mistake in the IP address I wrote in the allowed list in my Voxbeam account, or maybe the IP has changed.
I fixed it and now it fails with a different failure; no more “forbidden”.
Here is the new log:

Call-ID: d11445c2-2a4c-45fd-a79b-b313335c8c14CSeq: 36890 OPTIONSAccept: appl...

Here are the settings of my freepbx:

[200765 (Alberto Amori)]

With the above screenshots, the information about my freepbx settings should be enough complete to understand what is wrong.
Is there any news about this topic?

[Stewart1 (Stewart)]

Sorry, I don’t have much news to report.

On my test, just calling the CH mobile from my desk phone, with Outbound CID temporarily changed to TIM mobile, a few things were different: The caller ID was +393…, a P-Asserted-Identity header was present, and the Diversion header was absent. I don’t believe that’s why your call failed, but you can easily test to confirm.

However, although your mobile eventually rang, my test didn’t work properly, and I don’t know why. Upon dialing the number, a message was played in early media, not only in a language I don’t understand, but one I couldn’t recognize. I’m pretty sure that I would recognize Swiss German, French or Italian. Possibly Romanch, since I’m calling Eastern Switzerland? The message then repeated in English, stating that the number called was invalid. Next, the overall message (mystery language + English) played again. Finally, after a few seconds of silence, your mobile started ringing.

I had assumed that after the error announcement, Voxbeam sent a 503 and my PBX failed over, but I didn’t see it in the log and the call did appear in Voxbeam’s summary CDR and was billed, so I’m assuming that either Voxbeam or their upstream did the failover, even though my experience with them up to now has been that they simply reject calls that don’t work the first time.

In your case, it appears that you set a 27 second overall timeout, presumably to prevent the call from ending up in your mobile’s voicemail. When the early media started playing, there were only 17 seconds left. I’m guessing that it took longer than that to play the messages (twice in each language) and then set up the failover call. So, on line 909 of the log the timer expired and the call was dropped.

If the above is insufficient for you to troubleshoot, I could do another test where I record the audio and a detailed trace.

[200765 (Alberto Amori)]

In the meantime I have received a feedback from Voxbeam support and…

@Stewart1

The caller ID was +393…, a P-Asserted-Identity header was present, and the Diversion header was absent

…These 3 points are exactly the same that they suggested me to fix.

But:

• I am not able to find the way to prepend the “+” to the caller id in the PSTN forwarding, if the “+” is not present in the CID that I am receiving from the original call. How can I add it?

• The “Send RPID” is already set to “Send P-Asserted-Identity” in the advanced settings of the extension. Why the P-Asserted-Identity is not sent?

• In Asterisk advanced settings the “Generate Diversion Headers” field is already set to “NO”. Why the Diversion Headers is sent?

Is there a way to fix these 3 points with the GUI of Freepbx of should I hack the conf files of Asterisk?

[200765 (Alberto Amori)]

@200765

• I am not able to find the way to prepend the “+” to the caller id in the PSTN forwarding, if the “+” is not present in the CID that I am receiving from the original call. How can I add it?
• The “Send RPID” is already set to “Send P-Asserted-Identity” in the advanced settings of the extension. Why the P-Asserted-Identity is not sent?
• In Asterisk advanced settings the “Generate Diversion Headers” field is already set to “NO”. Why the Diversion Headers is sent?

Just a gentle reminder to the Freepbx community: I wonder if there is a solution for these 3 points. In particulars the points 2 and 3 looks like a bug of Freepbx (or I missed some setting that I have not mentioned)

[david55]

I assume 2 and 3 apply to the extension, not to the trunks that it calls.

[200765 (Alberto Amori)]

@david55

I assume 2 and 3 apply to the extension, not to the trunks that it calls.

Concerning point 2:

@200765

The “Send RPID” is already set to “Send P-Asserted-Identity” in the advanced settings of the extension.

If there is another place where the P-Asserted identity must be set, please let me know.

About the point 3. I haven’t found any field in the PJSIP Extension, to enable or disable the diversion header. The only place I found is in the global “Advanced Settings” menu, where it is set to “NO”. So I wonder if I should edit manually the onf file of the extension, do disable it.

Just wondering why Freepbx does the opposite of what I ask it to do

[Stewart1 (Stewart)]

@200765

I am not able to find the way to prepend the “+” to the caller id in the PSTN forwarding, if the “+” is not present in the CID that I am receiving from the original call. How can I add it?

You could send the Inbound Route through a Set CallerID app, setting CallerID Number to
+${CALLERID(num)}
(oversimplified, but would work for the specific example you gave).

An alternative is setting a custom Context for the incoming trunk. Look at from-pstn-e164-us (in extensions.conf) for the concept.

@200765

The “Send RPID” is already set to “Send P-Asserted-Identity” in the advanced settings of the extension. Why the P-Asserted-Identity is not sent?

You need to set it for the Trunk used for the outbound leg.

@200765

In Asterisk advanced settings the “Generate Diversion Headers” field is already set to “NO”. Why the Diversion Headers is sent?

DIDWW is setting it, IMO inappropriately. Try leaving it in. If you still have trouble, you’ll need a predial hook to remove it.

[200765 (Alberto Amori)]

@Stewart1

You could send the Inbound Route through a Set CallerID app, setting CallerID Number to
+${CALLERID(num)}

Which is the conf file to write this? extensions_custom.conf? Or extensions_override_custom.conf?

---

Edit: I wrote instructions to do what I need in the extensions_override_custom.conf, and then I tried to put them into the extensions_override_freepbx.conf. Here is my code (the instructions are aimed to work only for extension 10003):

[from-internal-custom]
exten => 10003,1,Set(CALLERID(num)=${IF($["${CALLERID(num):0:1}" != "+" && "${CALLERID(num):0:2}" != "00"]?+${CALLERID(num)}:${IF($["${CALLERID(num):0:2}" = "00"]?+${CALLERID(num):2}:${CALLERID(num)})})})
same => n,ExecIf($[${SIP_HEADER(P-Asserted-Identity)} = ]?Set(PJSIP_HEADER(add,P-Asserted-Identity)=${CALLERID(num)}))
same => n,SIPRemoveHeader(Diversion)

Then in the GUI of the extension, in advanced settings, I changed the context field from “from-pstn” to “from-internal-custom”. I restarted the fwconsole and saved the configuration from the GUI.
In the console, I could verify that the from-internal context is correctly updated (with command “dialplan show from-internal-custom”).
Unfortunately these instructions are never executed. It seems that the from-internal-custom context is never activated. What am I doing wrong?

---

Edit 2: I have created an entry in caller id module setting the caller id equal to +${CALLERID(num).
I have tried setting it both for the extension and for the inbound route, but it doesn’t work. In the full logfile the caller id is everywhere without “+”.

Really puzzled.