Internal trunk to trunk call failure

FreePBX Configuration
1

Hello,

I am having very easy to replicate trunk to trunk failures between two internal trunks to our FreePBX box. I have spent hours trying to find why one SIP trunk to SIP trunk call is working and why the other SIP trunk to SIP call is failing. I did manage to find a difference in the packet capture that I do not understand. I have obfuscated the names/numbers for privacy. Please see below:

Call #1, Rejected

“8.528233”,“8.714564”,“100.101.58.3”,““Orig Cust"sip:[email protected]:5060”,“sip:[email protected]:5060”,“SIP”,“00:00:00”,“4”,“CALL SETUP”,“INVITE”
“8.696185”,“8.713447”,“10.100.0.12”,”“Term Cust #1” sip:[email protected]",“sip:4067523333%[email protected]”,“SIP”,“00:00:00”,“3”,“REJECTED”,“INVITE 404”

Call #2, Successful:

“7.597821”,“13.162922”,“100.101.58.3”,““Orig Cust"sip:[email protected]:5060”,“sip:[email protected]:5060”,“SIP”,“00:00:05”,“6”,“IN CALL”,“INVITE 200”
“7.750494”,“13.089710”,“10.100.0.12”,”“Term Cust #2” sip:[email protected]",“sip:[email protected]”,“SIP”,“00:00:05”,“8”,“IN CALL”,“INVITE 401 200”

Notice in the first failing call the string from FreePBX to Term Cust #1 (10.100.0.12 to 100103.255.3) has a much longer number string and includes a % character than the successful call #2.

I believe the rejection of the first call is coming from the term PBX not liking the extra garbage in the number spill.

Does anyone have thoughts as to what might cause the number spills to be so different as they should both be sending 10 digits?

Thanks for your time!

2

Actually, it contains a space character. %40 is the URI encoding for a space. Does this give any clues?

3

David,

That does help a bit. The big question of the day is why the space and why so many digits on the failing call. I have no idea.

I appreciate the reply!

4

Possibly your CallerID’s are not formatted exactly "name" <number>

5

Thanks for the reply!

Those two calls are being made from the same client phone and I am dialing 10 digits to both of the internal trunks and one is failing. I looked at at that earlier and considered that possibility. I have made changes to a custom.conf file to alter caller ID, but if if changes the caller ID format it should be changing it uniformly for both calls.

6

What changes did you make to what custom.conf file ? (no clairvoyants here ;-))

7

From my extensions_custom.conf file: (I think I got this from one of your posts dicko!)

[from-remote]
include => ext-did
include => from-internal

[macro-dialout-trunk-predial-hook]
exten => s,1,NoOp(Entering user defined context macro-dialout-trunk-predial-hook in extensions_custom.conf)
exten => s,n,ExecIf($[ ${LEN(${CALLERID(number)})} = 10]?Set(CALLERID(number)=+1${CALLERID(number)}))
exten => s,n,MacroExit

8

I think right now the CallerID thing is a red herring, but Identify who are

10.100.0.12
100.103.255.3 (HMM!!!)
192.168.105.242

9

dicko,

10.100.0.12 is our FPBX switch
100.101.58.3 is the orig in the test (PBX via SIP trunk)
100.103.255.3 is the failing PBX/SIP trunk
192.168.105.242 is the successful PBX trunk

Scott

10

routing table and subnets?
Network layout description?

11

dicko,

10.100.0.12/24
100.101.58.3/23
100.103.255.3/23
192.168.105.242/24

This is a mix of CGNAT and private IP space internal to our ISP. All use the lowest .1 in the subnet as the gateway. These connect via a bridge to our core routers which are connected via internal BGP. Three separate sites are used and I have SIP instruments connected to all three sites with no other known issues.

12

Given that mix, I’l leave it with you, good luck.

13

dicko,

Thanks for having a look anyway!

1 Like