Looparound Forwarded Call from Trunk unauthorized Fpbx 2.11

Scenario:

Ext 5222 on
PBX1 Cisco CUCM9.1 (10.10.10.220)
SIP Trunked to
PBX2 FreePBX 2.11 (10.10.10.71)
Ext 6203 and 6204

On PBX1 (CUCM) the ext 5222 has been set to forward all calls to ext 6204
Only one calling scenarios does not work - if a user on PBX2, such as 6203, calls ext 5222, the forwarded call goes to PBX1, an invite comes back to PBX2, but is being rejected as unauthorized.

All other scenarios do work, other PBX1 users can call 5222 and gets to 6204 just fine, even calls trunked from other locations to PBX1.

I tried a lot of stuff, allowing guest and anonymous and reinvites and such, but I can’t grasp exactly why this call is being rejected.
The trunk is “from-trunk” and the user is default (from-internal I think). The weird part is that it seems to work if I add another pbx inbetween, like if it proxies from one trunk to another inbetween it is allowed.

Here is a log with SIP Debug of the denied call routing:
As a new user I dont have right to post a link - so it has been doconstructed, I didnt see any way to attach a log file either(?) - so add the http colon slash slash in front and remove spaces:
stokkeland.net /jts/voip/?showme=le0d9uikfd90dick33ejd3

(6203 calls 5222, hits the trunk, comes back for 6204, unauthorized)

Are you configured to accept TCP connections on your various extensions?

yes I do have TCP enabled, and many/most extensions are configured to use TCP

Is that relevant in this?

Apparently :slight_smile: :-

[2015-03-02 13:42:42] VERBOSE[21839][C-00000782] chan_sip.c: Scheduling destruction of SIP dialog ‘[email protected]’ in 6400 ms (Method: INVITE)
[2015-03-02 13:42:42] VERBOSE[21839] chan_sip.c:
ÿ<— SIP read from TCP:10.10.10.220:54284 —>
ÿACK sip:[email protected]:5060 SIP/2.0
ÿVia: SIP/2.0/TCP 10.10.10.220:5060;branch=z9hG4bK15528311ec
ÿFrom: “PBX2 UserA” sip:[email protected];tag=679~ec10f85c-7bbc-4d9e-89d3-c62eca8ee3dd-30550032
ÿTo: sip:[email protected];tag=as5cb96062
ÿDate: Mon, 02 Mar 2015 18:22:26 GMT
ÿCall-ID: [email protected]
ÿMax-Forwards: 70
ÿCSeq: 101 ACK
ÿAllow-Events: presence
ÿContent-Length: 0
ÿ
ÿ<------------->
[2015-03-02 13:42:42] VERBOSE[21839] chan_sip.c: — (10 headers 0 lines) —
[2015-03-02 13:42:42] VERBOSE[1816] chan_sip.c:
ÿ<— SIP read from UDP:10.10.10.220:5060 —>
ÿSIP/2.0 401 Unauthorized
ÿVia: SIP/2.0/UDP 10.10.10.71:5060;branch=z9hG4bK4048b2fa
ÿFrom: “PBX2 UserA” sip:[email protected];tag=as4fb00073
ÿTo: sip:[email protected];tag=678~ec10f85c-7bbc-4d9e-89d3-c62eca8ee3dd-30550029
ÿDate: Mon, 02 Mar 2015 18:22:26 GMT
ÿCall-ID: [email protected]
ÿCSeq: 102 INVITE
ÿAllow-Events: presence
ÿReason: Q.850; cause=21
ÿContent-Length: 0
ÿ
ÿ<------------->
[2015-03-02 13:42:42] VERBOSE[1816] chan_sip.c: — (10 headers 0 lines) —
[2015-03-02 13:42:42] VERBOSE[1816][C-00000781] chan_sip.c: Transmitting (no NAT) to 10.10.10.220:5060:
ÿACK sip:[email protected] SIP/2.0
ÿVia: SIP/2.0/UDP 10.10.10.71:5060;branch=z9hG4bK4048b2fa
ÿMax-Forwards: 70
ÿFrom: “PBX2 UserA” sip:[email protected];tag=as4fb00073
ÿTo: sip:[email protected];tag=678~ec10f85c-7bbc-4d9e-89d3-c62eca8ee3dd-30550029
ÿContact: sip:[email protected]:5060
ÿCall-ID: [email protected]
ÿCSeq: 102 ACK
ÿUser-Agent: FPBX-2.11.0(11.7.0)
ÿContent-Length: 0
ÿ
ÿ
ÿ—
[2015-03-02 13:42:42] NOTICE[1816][C-00000781] chan_sip.c: Failed to authenticate on INVITE to ‘“PBX2 UserA” sip:[email protected];tag=as4fb00073’
[2015-03-02 13:42:42] VERBOSE[22376][C-00000781] app_dial.c: – SIP/scCUCM91-00000742 is circuit-busy

Oh… so - my FreePBX contacts cisco on UDP, the cisco is trying set up a channel back on TCP, but is unauthorized to do so… is that what you see?

if so i should be able to set Transport=udp,tcp or something probably

Probably with Cisco you should prefer TCP over UDP if it first offers it.

Well - That didnt solve it - i set transport=tcp,udp on the trunk - and logs I think now show it doing it all in TCP.

As I set up my test this morning I managed to reverse my test - so right now i have

PBX1/Cisco - Ext 5222, callfwd to 6203

PBX2/Fpbx - Ext 6203, ext 6204

Test call from 6204 to 5222 is in this new log file:
stokkeland.net/jts/voip/?showme=le0d9uikfd90beavr33ejd3

but looks like the result is about the same

I also tried setting “From-internal” on the trunk to see if it was just a context issue, but that didnt fix it.
So, it appears to be something in SIP/Asterisk where if a call fwd comes directly back at you, it is unauthorized - but if it is trunked via another hop and back it works fine… is there any advanced “minimum hop” setting or something?

I am wondering if I need to set up a vanilla asterisk to test this without freepbx to see if its asterisk itself in some fashion.

So I have figured out something here -but unsure how to solve it. I installed plain asterisk and played around a bit.

To re-list the secanario.

BX1/Cisco - Ext 5222 which callfwd set to 6203

PBX2/Fpbx - Ext 6203, ext 6204

From registered ext 6203 I call 5222, the cisco fwds on a new channel back to PBX2 for 6204

  • but asterisk rejects the call as chan_sip.c:23059 handle_response_invite: Failed to authenticate on INVITE

If I configure sip for 6204 and add insecure=invite
it now starts working

so what I dont get is how come it works if the call is from anywhere else - but if I call from my own pbx and it is fwd right back to me, it fails on that invite? but if it is trunked to another pbx before it comes right back, then it also works…

Not sure if I understand what asterisk does here

since setting insecure=invite on every extension is probably not a good idea… I keep trying to figure this out but havent had much luck.

I did find that if I in the CUCM change the trunk setting, outgoing calls, “Calling Party Selection” to anything but “Orignator” it work - that basically changes the from to the redirected number… that is not what we want though, we want the original number as caller id, but for some weird reason if this goes straight to peer and comes right back it fails - if it gets channeled via another peer before coming back it works fine - i do NOT underatand what the difference is in what asterisk is seeing?