FreePBX Trunk Sipgate - Outbound CallerID always the same, does not match extension

FreePBX
1

Hey everybody,

I have a little problem with a SIP trunk.

I installed FreePBX, configured it to use a Sipgate trunk and it works like a charm. I followed the manual (see teamhelp dot sipgate dot de/hc/de/articles/115005610245-FreePBX-10-13-66 - sorry, cannot post links directly but this is an offical one from Sipgate) from Sipgate (in German, I couldn’t find a translation of it but the screenshots are mostly in English).

Everything works as expected, I can place calls and receive calls. The inbound rules apply and outbound works.
BUT: Outbound always shows the first number that I configured. No matter which extension places the call.

Let’s assume, I configured the extension like “Display Name” Test1, Test2, etc., “Outbound CID” = “Test1” <49301234567891> and “Test2” <49301234567892>, etc.
I left everything else on standard.

Then, I configured the trunk:
Trunk Name, don’t hide callerid
outbound caller id <4930123456789> (without the actual numbers at the end)
CID: Allow any CID
Maximum Channels 100
pjsip:
Username, Secret, Auth outbound, send, Sip server, SIP Server Port, context from-pstn - like depicted in the manual.
advanced:
Domain, User, … like in manual

Outbound Route:
Route Name, no Route CID, override extension no, no route password, no route type, Trunk sequence for matched routes: Trunk that I configured earlier
Dial patterns:
prepend prefix X.

I then configured the inbound routes according to the manual.

So… everything works. Except that all extensions that place an outbound call appear as 0301234567891 (example) and not 0301234567892, 0301234567893, etc. The caller ids don’t match the extensions.

What did I miss and what do I need to configure?

Thank you in advance!

2

In your example, the caller IDs match the first extension. Is that what’s happening?

3

In the trunk, try setting Send RPID/PAI to Both. If no luck, ask Sipgate in which header and in what format the caller ID should be sent (it’s normally in the From header, but their From User setting is overriding that with required authentication information.

4

Yes, as far as outgoing external calls are concerned. The caller ID (…1) that is currently assigned to extension 1 appears on the display of any landline device or cell phone that receives the call, no matter if the call was placed by extension 1 (caller id …1 assigned) or extension 2 (caller id …2 assigned) or extension 3 (caller id …3 assigned).

5

I will try that tomorrow.

6

Sounds like your carrier is not using your CID but forcing one they set maybe?

7

@Multiuser How about we see some actual examples of this happening and how calls are actually being processed in the dialplan.

asterisk -rvvvvvvvvv

Make a call from Exten 1, then make a call from Exten 2. In both calls, according to you, they will load and use Exten 1’s CallerID. Let’s see this actually happening.

Pastebin the results and post the link here.

8

That didn’t work. I may ask Sipgate then.

9

Before asking for support, check by doing
pjsip set logger on
at the Asterisk command prompt, then making a call showing incorrect caller ID.
Confirm that the desired caller ID does appear in the P-Asserted-Identity header.

10

I collected the data but will need to anonymize them. Will try to upload them tomorrow.

11

Ok, done that. The log is huge. I need some time to anonymize it. Do you need a specific part of it or the whole “conversation”?

12

Just look for the line starting INVITE sip: and showing the called number (the invite sent to the trunk, not the one from the extension). In the headers following, you should see a P-Asserted-Identity, with the desired caller ID. If you can find it, there is no need to post it to the forum.

13

I didn’t give instructions for providing a SIP debug (sip debug or pjsip logger) because that’s not what I wanted to see. What is set in the RPID/PAI/FROM headers for the CallerID is the final output. I want to see nothing but the console log of the dialplan execution, this should not be overly large in any sense and really should contain minimal IP information.

@Multiuser If your debug has SIP packet information in it (INVITEs, REGISTERs, etc) then you enabled more debugging then I requested. Please redo this with only the command I gave you. Turn the other stuff off.

14

Sorry, I disagree here. The OP indicated correct settings for extension CID, not overridden in Outbound Route and not overridden by trunk settings. While it’s conceivable that he entered something wrong in the GUI or that FreePBX generated a faulty dial plan, IMO that’s much less likely than an issue on the Sipgate side. The official help file linked by the OP shows trunk settings that don’t transmit caller ID at all, i.e. the outbound caller ID is determined solely by account settings at Sipgate. It seems very likely that a settings change at Sipgate (on their portal or via a ticket) is needed to permit user-supplied CLI to pass. However, since getting support is often a hassle, it seemed worthwhile to first confirm that the desired CLI was indeed being passed on the wire.

15

You are missing my point. I want to see what the CallerID macros are setting as the values those headers are presenting. In looking at the call log we can see the choices the dialplan made, what the VARs are being set to and that it is looking in the right spot for the information.

Looking at just the INVITE is showing the final values being sent to the provider, not how those values were set.

16

Both of you, don’t worry. I got the logs for both of you independently, one time with and one time without pjsip logger. I will post them today, probably in the afternoon.

One other guy that I asked about the issue yesterday evening and who has a bit of experience with Sipgate, hinted (like Stewart1) that it might be that Sipgate needs explicit confirmation that I set the caller ID because I could impersonate any number that way. I don’t know if that is true but I’ll try to get confirmation on that matter.

So far I want to say thank you again, to both of you, for your efforts. I’ll get back to you asap.

17

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