Failure on PBX to PBX Call over a trunk

General Help
1

I have a somewhat strange one, that has me scratching my head at the moment. I have two PBX’s, both are running FreePBX Distro 5.211-65.20, and asterisk 11.13.1. It’s very common for calls to be passed extension to extension between the two PBX’s, and in general is working well. Now I am finding calls from a given extension range are now being rejected.

Here is an example of a call path we are using:


[ext4455]---SIP--- [ALG PBX]---SIP---[DCD-PBX]---SIP---[ext8558]

A call from 4455 to 8558 will fail, with the following error:

Error from ALGPBX:


[2014-11-24 10:00:28] WARNING[9407][C-000019eb] chan_sip.c: Received response: "Forbidden" from 

'"Name Removed" <sip:[email protected]>;tag=as64c83dfd'
[2014-11-24 10:00:28] VERBOSE[10643][C-000019eb] app_dial.c:   == Everyone is busy/congested at this time (1:0/0/1)

Error on DCDPBX:


[2014-11-24 11:08:34] NOTICE[25817][C-00006b00] acl.c: SIP Peer ACL: Rejecting '
10.150.4.36' due to a failure to pass ACL '(BASELINE)'
[2014-11-24 11:08:34] NOTICE[25817][C-00006b00] chan_sip.c: Failed to authenticate device "Name Removed" <sip:[email protected]>;tag=as62d2a7f7

There is no ACL on the trunk at all, and what is really strange, is some extensions can dial across, So replace 4455 with say 4801, and then the call will pass across the PBX’s just fine.

The part that perplexes me, is that as this is two internal PBX’s, there is NO ACL on the trunks in either direction, in fact here is a sample of the conf used between the PBX’s:


type=peer
host=10.150.4.36
dtmfmode=rfc2833
qualify=yes
nat=no
canreinvite=no
insecure=port,invite
callcounter=yes
context=from-branches

The from-branches just allows group, meetme, did, and internal. I am sure I am overlooking something, but I don’t see how there is any ACL in play to affect the trunk. Also what is the BASELINE they are referring to in the log entry?

Thanks…

2

Did you ever find a solution to this problem, I have now have the same issue.

3

Nope, I even opened a paid support ticket with Schmooze to look into the issue. Using IAX allowed the call to pass, but it would then show the local info of the local PBX which would confuse people, but at least the call processed.

The end of it was basically that you can use the same extension number on the two PBX’s, and have an interoffice trunk, and if you don’t designate at interoffice, then it will just show the defined default outside number.

4

Thank you for taking the time to answer me, it looks like I am stuck with the problem.

One thing I have noticed is that a trunk from FreePBX to a Grandstream UCM does work fine but when any extension on the UCM dials to FreePBX they show the correct extension description but the outside number as the caller ID, maybe there is a clue there I don’t know.

I did try removing the intra-company settings from the outbound route but again that made no difference.

Once again thank you for the information.

Regards

Paul

5

I had another look at this because it was bugging me. I changed over one of the trunks from SIP to PJSIP and the transferred started working in one direction, you can transfer back to the SIP trunk from PJSIP. I then changed the other one and all was working, including showing the correct extension details.

So it would appear that it is the PBX sending the transfer back that fails and not the one receiving the call back?.

Unfortunately I only had one FPX13 the other is FBX12 so there are problems with it trying to register when using PJSIP therefore it may not be a fix I can leave in at the moment but as far as I can tell FBX13 to FBX13 should work fine if you use PJSIP on the trunks.

It is a pity SIP can not be fixed through.

6

With a little investigation I think I have worked this out. If you change type=peer to type=friend the calls seem OK being transferred back again.

I am just a little worried I may have made myself a security problem, all seems OK at the moment but I am still checking.

7

Maybe I was a bit ahead of myself, it only works when the calling extension is on PJSIP not chan-sip.

Back to the drawing board I think.