How to define a pj_sip trunk to a Cisco ISR4321

FreePBX Endpoints
1

I’m trying to create a trunk that goes to a Cisco ISR setup as a voice gateway. The ISR is setup with no authentication, and I’ve defined the trunk as follows:

add trunk
name ISRGateway
maximum channels 1
pjsip settings general
authentication none
registration none
sip server: IP address of ISR

On saving it, this is what I get in the output for Asterisk Info


Endpoint:  ISRGateway                                        Unavailable   0 of inf
Aor:  ISRGateway                                      0
Contact:  ISRGateway/sip:172.16.160.3             5ca5187d8f Unavail         nan
Transport:  0.0.0.0-udp               udp      3     96  0.0.0.0:5060
Identify:  ISRGateway/ISRGateway
Match: 172.16.160.3/32

The idea is to use the ISR to replace my Cisco 1760 that is working however it is using chan_sip

The 1760 trunk chan sip outbound config is:
trunk name: out5032355833

host=172.16.1.6
port=5060
type=peer
insecure=port,invite
dtmfmode=rfc2833
disallow=all
allow=ulaw

The config in the ISR is pretty much a duplicate of the working config in the 1700, of which the relevant bits are:

!
voice rtp send-recv
!
voice service voip
 fax protocol pass-through g711alaw
 modem passthrough nse codec g711alaw
 sip
!
!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8 bytes 40
 codec preference 3 g723r63 bytes 96
 codec preference 4 g726r16 bytes 80
!
!

!
interface FastEthernet0/0
 ip address 172.16.1.6 255.255.255.0
 ip route-cache flow
 speed auto
 no cdp enable

voice-port 3/0
 no battery-reversal
 timing hookflash-out 50
 connection plar 5833
 description trunk 503-235-5833
 caller-id enable
!

!
!
!
dial-peer voice 1 voip
 preference 1
 destination-pattern 5833
 voice-class codec 1
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 11 pots
 preference 1
 destination-pattern .T
 port 3/0
!

!
sip-ua
 retry invite 3
 retry response 3
 retry bye 3
 retry cancel 3
 timers trying 1000
 timers expires 300000
 sip-server ipv4:172.16.1.16
!

I tried setting up a pj_sip trunk to the 1700 once before and could never make it work while chan_sip worked immediately. But that was maybe a decade ago.

Virtually every example I’ve found out there going to a Cisco gateway of any kind is chan_sip on the FreePBX side.

I almost forgot - it works for INCOMING calls from the gateway. But not outgoing.

Oh and I also forgot to mention - this is on a parallel FreePBX PBX not the same one that the chan_sip trunks are working on

Any suggestions?

2

Please provide protocol logs. (Outbound really ought to be easier to get working, than inbound, here, so we need to see how the request was rejected.)

Incidentally, in your sip.conf, insecure=invite has no effect, as you have no secret, and I don’t believe insecure=port is needed for Cisco, when using UDP; for most systems with UDP, it just reduces the security.

3

In FreePBX, Reports, System Logs shows nothing.

I think the defaults nowadays are to basically remove anything of interest in the logs. Seems like in older versions of FreePBX I would get lots of info from the Reports System Log button but in recent versions, nada

Also the insecure= stuff is all chan_sip stuff I’m trying to get this to work with chan_pjsip

The ISR has lots of debugging info, but I’m afraid for Asterisk itself to get anything usable I have to go to the command line and do a /sbin/asterisk -r since the FreePBX logs are worthless nowadays.

4

Here’s the output on the Cisco of a debug ccsip message. It’s just repeated attempts by the PBX to register:


003395: Oct 18 18:17:50.245 PDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj00a26509-6695-48c1-be22-680e3412e459
From: <sip:[email protected]>;tag=da8ab1fc-f832-41c0-a8dc-865c33e92dea
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: 3623d27a-006d-4c98-977a-7f926601ff96
CSeq: 8543 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0


003396: Oct 18 18:17:54.246 PDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj00a26509-6695-48c1-be22-680e3412e459
From: <sip:[email protected]>;tag=da8ab1fc-f832-41c0-a8dc-865c33e92dea
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: 3623d27a-006d-4c98-977a-7f926601ff96
CSeq: 8543 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0


003397: Oct 18 18:17:58.246 PDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj00a26509-6695-48c1-be22-680e3412e459
From: <sip:[email protected]>;tag=da8ab1fc-f832-41c0-a8dc-865c33e92dea
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: 3623d27a-006d-4c98-977a-7f926601ff96
CSeq: 8543 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0

And here is the output when I make a call from the PSTN to the phone number on the gateway;

CUBE#sh log
Syslog logging: enabled (0 messages dropped, 2 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.



No Inactive Message Discriminator.


    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged, xml disabled,
                     filtering disabled
    Buffer logging:  level debugging, 7483 messages logged, xml disabled,
                    filtering disabled
    Exception Logging: size (4096 bytes)
    Count and timestamp logging messages: disabled
    Persistent logging: disabled

No active filter modules.

    Trap logging: level informational, 114 message lines logged
        Logging Source-Interface:       VRF Name:

Log Buffer (4096 bytes):
ephone-event
Session-ID: a759e29315e95451bc359d376a6dbc74;remote=00000000000000000000000000000000
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 683

--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 4241 3644 IN IP4 172.16.160.3
s=SIP Call
c=IN IP4 172.16.160.3
t=0 0
m=audio 8020 RTP/AVP 0 18 98 9 101 100
c=IN IP4 172.16.160.3
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:98 G726-32/8000
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=ptime:20

--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional

IAM,
GCI,97cd9921abc011f0803e81c3d05b87d7


--uniqueBoundary--

003421: Oct 18 18:20:11.748 PDT: //22/97CD9921803E/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.160.3:5060;rport=56196;received=172.16.160.3;branch=z9hG4bK141AC0
Call-ID: [email protected]
From: "[V]WIRELESS CALLER" <sip:[email protected]>;tag=76E63C2-1091
To: <sip:[email protected]>
CSeq: 101 INVITE
Server: FPBX-17.0.21(22.5.2)
Content-Length:  0


003422: Oct 18 18:20:11.772 PDT: //22/97CD9921803E/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.160.3:5060;rport=56196;received=172.16.160.3;branch=z9hG4bK141AC0
Call-ID: [email protected]
From: "[V]WIRELESS CALLER" <sip:[email protected]>;tag=76E63C2-1091
To: <sip:[email protected]>;tag=1e53dd85-ef16-4d1d-8e71-bce9db71daa4
CSeq: 101 INVITE
Server: FPBX-17.0.21(22.5.2)
Contact: <sip:172.16.160.10:5060>
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INFO, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length:   280

v=0
o=- 4241 3646 IN IP4 172.16.160.10
s=Asterisk
c=IN IP4 172.16.160.10
t=0 0
m=audio 13814 RTP/AVP 0 98 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:98 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

003423: Oct 18 18:20:11.777 PDT: //22/97CD9921803E/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:172.16.160.10:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.3:5060;branch=z9hG4bK15155
From: "[V]WIRELESS CALLER" <sip:[email protected]>;tag=76E63C2-1091
To: <sip:[email protected]>;tag=1e53dd85-ef16-4d1d-8e71-bce9db71daa4
Date: Sun, 19 Oct 2025 01:20:11 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Session-ID: a759e29315e95451bc359d376a6dbc74;remote=13497bd83242587ea6d32480268c1858
Content-Length: 0


003424: Oct 18 18:20:18.210 PDT: //22/97CD9921803E/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:172.16.160.10:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.3:5060;branch=z9hG4bK161F14
From: "[V]WIRELESS CALLER" <sip:[email protected]>;tag=76E63C2-1091
To: <sip:[email protected]>;tag=1e53dd85-ef16-4d1d-8e71-bce9db71daa4
Date: Sun, 19 Oct 2025 01:20:11 GMT
Call-ID: [email protected]
User-Agent: Cisco-SIPGateway/IOS-16.9.8
Max-Forwards: 70
Timestamp: 1760836818
CSeq: 102 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=319,OS=63800,PR=219,OR=43760,PL=0,JI=0,LA=20,DU=6
Session-ID: a759e29315e95451bc359d376a6dbc74;remote=13497bd83242587ea6d32480268c1858
Content-Length: 0


003425: Oct 18 18:20:18.213 PDT: //22/97CD9921803E/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.160.3:5060;rport=56196;received=172.16.160.3;branch=z9hG4bK161F14
Call-ID: [email protected]
From: "[V]WIRELESS CALLER" <sip:[email protected]>;tag=76E63C2-1091
To: <sip:[email protected]>;tag=1e53dd85-ef16-4d1d-8e71-bce9db71daa4
CSeq: 102 BYE
Server: FPBX-17.0.21(22.5.2)
Content-Length:  0


CUBE#

Of course, since this is testing I don’t have the inbound trunk routing setup so a call into it just gets the Alison voice saying “the number you have dialed in not in service please check the number and dial again” followed by the 9712455292 number spelled out, but that’s perfectly fine for testing.

Unfortunately, for outgoing test calling I can’t do a thing - because if I change the main outgoing line to the ISR, I get “your call cannot be completed please check the number and dial again” probably because it sees that the pjsip trunk isn’t registered. I also get no output from asterisk -r at the command line and trying to bypass it:

phony*CLI> channel originate SIP/ISR911Gateway/5039676993 application Playback hello-world
[2025-10-18 18:39:40] WARNING[721645]: channel.c:6204 request_channel: No channel type registered for 'SIP'
phony*CLI>

no joy either

5

more debugging

phony*CLI> core set verbose 4
Console verbose was OFF and is now 4.
phony*CLI> core set debug 4
Core debug was OFF and is now 4.
phony*CLI> pjsip set logger on
PJSIP Logging enabled
[2025-10-18 18:44:26] DEBUG[153128]: res_pjsip/pjsip_options.c:936 sip_options_qualify_aor: Qualifying all contacts on AOR 'ISRGateway'
[2025-10-18 18:44:26] DEBUG[153128]: res_pjsip/pjsip_options.c:865 sip_options_qualify_contact: Qualifying contact 'ISRGateway@@5ca5187d8f760a484586faa85ed92006' on AOR 'ISRGateway'
[2025-10-18 18:44:26] DEBUG[153128]: res_pjsip.c:1716 endpt_send_request: 0x7f71901e5ae0: Wrapper created
[2025-10-18 18:44:26] DEBUG[153128]: res_pjsip.c:1731 endpt_send_request: 0x7f71901e5ae0: Set timer to 3000 msec
[2025-10-18 18:44:26] DEBUG[153128]: res_pjsip/pjsip_resolver.c:475 sip_resolve: Performing SIP DNS resolution of target '172.16.160.3'
[2025-10-18 18:44:26] DEBUG[153128]: res_pjsip/pjsip_resolver.c:502 sip_resolve: Transport type for target '172.16.160.3' is 'UDP transport'
[2025-10-18 18:44:26] DEBUG[153128]: res_pjsip/pjsip_resolver.c:523 sip_resolve: Target '172.16.160.3' is an IP address, skipping resolution
<--- Transmitting SIP request (427 bytes) to UDP:172.16.160.3:5060 --->
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj6bc070fd-433f-4b85-a759-bebeff58d313
From: <sip:[email protected]>;tag=47459c62-bdb4-4578-8894-f66d597bea28
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: ae88a804-fd47-45dd-9087-f6f4ee34a5e8
CSeq: 45768 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0


<--- Transmitting SIP request (427 bytes) to UDP:172.16.160.3:5060 --->
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj6bc070fd-433f-4b85-a759-bebeff58d313
From: <sip:[email protected]>;tag=47459c62-bdb4-4578-8894-f66d597bea28
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: ae88a804-fd47-45dd-9087-f6f4ee34a5e8
CSeq: 45768 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0


<--- Transmitting SIP request (427 bytes) to UDP:172.16.160.3:5060 --->
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj6bc070fd-433f-4b85-a759-bebeff58d313
From: <sip:[email protected]>;tag=47459c62-bdb4-4578-8894-f66d597bea28
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: ae88a804-fd47-45dd-9087-f6f4ee34a5e8
CSeq: 45768 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0


[2025-10-18 18:44:29] DEBUG[1646]: res_pjsip.c:1653 send_request_timer_callback: 0x7f71901e5ae0: Internal tsx timer expired after 3000 msec
[2025-10-18 18:44:29] DEBUG[1646]: res_pjsip.c:1669 send_request_timer_callback: 0x7f71901e5ae0: Timer handled here
[2025-10-18 18:44:29] DEBUG[383801]: res_pjsip/pjsip_options.c:759 sip_options_contact_status_notify_task: Contact ISRGateway/sip:172.16.160.3 status didn't change: Unreachable, RTT: 0.000 msec
[2025-10-18 18:44:29] DEBUG[383801]: res_pjsip/pjsip_options.c:779 sip_options_contact_status_notify_task: AOR 'ISRGateway' now has 0 available contacts
[2025-10-18 18:44:29] DEBUG[1646]: res_pjsip.c:1682 send_request_timer_callback: 0x7f71901e5ae0: Callbacks executed
<--- Transmitting SIP request (427 bytes) to UDP:172.16.160.3:5060 --->
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj6bc070fd-433f-4b85-a759-bebeff58d313
From: <sip:[email protected]>;tag=47459c62-bdb4-4578-8894-f66d597bea28
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: ae88a804-fd47-45dd-9087-f6f4ee34a5e8
CSeq: 45768 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0



<--- Transmitting SIP request (427 bytes) to UDP:172.16.160.3:5060 --->
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj6bc070fd-433f-4b85-a759-bebeff58d313
From: <sip:[email protected]>;tag=47459c62-bdb4-4578-8894-f66d597bea28
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: ae88a804-fd47-45dd-9087-f6f4ee34a5e8
CSeq: 45768 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0


[2025-10-18 18:44:36] DEBUG[722964]: manager.c:7103 process_message: Running action 'Login'
[2025-10-18 18:44:36] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 1
[2025-10-18 18:44:36] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 0
[2025-10-18 18:44:36] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 0
[2025-10-18 18:44:36] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 0
<--- Transmitting SIP request (427 bytes) to UDP:172.16.160.3:5060 --->
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj6bc070fd-433f-4b85-a759-bebeff58d313
From: <sip:[email protected]>;tag=47459c62-bdb4-4578-8894-f66d597bea28
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: ae88a804-fd47-45dd-9087-f6f4ee34a5e8
CSeq: 45768 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0

<--- Transmitting SIP request (427 bytes) to UDP:172.16.160.3:5060 --->
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj6bc070fd-433f-4b85-a759-bebeff58d313
From: <sip:[email protected]>;tag=47459c62-bdb4-4578-8894-f66d597bea28
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: ae88a804-fd47-45dd-9087-f6f4ee34a5e8
CSeq: 45768 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0


[2025-10-18 18:44:42] DEBUG[723017]: manager.c:7103 process_message: Running action 'Login'

<--- Transmitting SIP request (427 bytes) to UDP:172.16.160.3:5060 --->
OPTIONS sip:172.16.160.3 SIP/2.0
Via: SIP/2.0/UDP 172.16.160.10:5060;rport;branch=z9hG4bKPj6bc070fd-433f-4b85-a759-bebeff58d313
From: <sip:[email protected]>;tag=47459c62-bdb4-4578-8894-f66d597bea28
To: <sip:172.16.160.3>
Contact: <sip:[email protected]:5060>
Call-ID: ae88a804-fd47-45dd-9087-f6f4ee34a5e8
CSeq: 45768 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.21(22.5.2)
Content-Length:  0


[2025-10-18 18:44:48] DEBUG[723020]: manager.c:7103 process_message: Running action 'Login'
[2025-10-18 18:44:48] DEBUG[723035]: manager.c:7103 process_message: Running action 'Login'
[2025-10-18 18:44:48] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 0
[2025-10-18 18:44:48] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 0
[2025-10-18 18:44:48] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 0
[2025-10-18 18:44:48] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 0
[2025-10-18 18:44:48] DEBUG[1613]: threadpool.c:536 grow: Increasing threadpool stasis/pool's size by 0
[2025-10-18 18:44:48] DEBUG[723038]: manager.c:7103 process_message: Running action 'Login'
6

It appears that the Cisco doesn’t respond to OPTIONS, so set Qualify Frequency to 0 in the trunk. After Submit and Apply Config, turn pjsip logger back on, attempt an outgoing call and post the trace.

7

Which should be reported as a bug to them, as, even if it doesn’t support OPTIONS, it is required to send a response. Even though that response would be Method Not Allowed, it is still a response, so Asterisk will treat it as contactable.

8

Well as it turned out - that wasn’t actually it. It’s something specific to the Cisco ISR4321.

I tried turning off OPTIONS and got the same problem. So then I thought heck with it, set the Cisco SIP server to port 5060, disabled the chan_sip trunks going to the Cisco 1760, and replaced them with chan_pjsip trunks with the Qualify Frequency set to 0. Those worked. Then for grins I set Qualify Frequency back to 60 - and, the trunks continued to work. With the benefit that now they show as “Available” in the Reports, Asterisk Info:

Endpoint:  5032313883P                                          Not in use    0 of inf
Aor:  5032313883P                                        0
Contact:  5032313883P/sip:172.16.1.6                 ee28828470 Avail        15.934
Transport:  0.0.0.0-udp               udp      3     96  0.0.0.0:5060
Identify:  5032313883P/5032313883P
Match: 172.16.1.6/32

Endpoint:  5032355833P                                          Not in use    0 of inf
Aor:  5032355833P                                        0
Contact:  5032355833P/sip:172.16.1.6                 ee28828470 Avail        16.202
Transport:  0.0.0.0-udp               udp      3     96  0.0.0.0:5060
Identify:  5032355833P/5032355833P
Match: 172.16.1.6/32

The pjsip trunks were created simply by Connectivity, Trunks, put in the trunk name, and channel 1 in general settings, and the SIP Server IP address in the pjsip general settings, and setting authentication and registration settings to None.

I then for fun went back and in the Trunk configuration pjsip settings general, set Authentication to Outbound and put in a username and secret, and then in the Cisco config, under sip-us, put in the same under an authentication directive. That worked fine as well.

So it’s definitely something in the IRS4321 “CUBE”

Now, I DID notice in the following post from 13 years ago:

Basic setup from freepbx to cisco 28XX as voicegateway with PRI - FreePBX / Tips and Tricks - FreePBX Community Forums

That that configuration listed:

no mgcp package-capability res-package
no mgcp package-capability fxr-package
no mgcp timer receive-rtcp
no mgcp explicit hookstate

now, he was working with a 2800 not a ISR4321 - but for a while the 2800’s there had Cisco so-called “CUBE” functionality (Cisco Unified Border Element) AKA Session Border Controller, and turning the media gateway control protocol on might be interfering in some manner with using it for ordinary SIP. The ISR4321 was, after all, positioned by Cisco as their “primo” Session Border Controller entry to the market.

It should be noted that the ISR4321 End of Sale was in 2023 and End of Support from Cisco will be in 2028. Sometime during the lifespan of that device, Cisco modified the firmware so that newer firmwares for the device now require a yearly subscription fee. There’s a LOT of ISR4321’s out there which people are NOT firmware updating to the latest firmware (even if they are on support contract with Cisco) because that turns on the subscription “call home to mommie” feature, and thus the device will cease operating in 2028 (at least, as a SBC.) even if the owner is willing to pay the yearly fee.

Which is why the wise don’t use these (as well as the 2800/1760/etc. as Internet-touching devices.

I will continue testing the ISR4321 as there should be some way of getting this working.

9

In your penultimate post, the PBX was not sending an INVITE, which I presumed was caused by qualify failure. After turning off qualify, is it sending an INVITE now? If still not, try to find out why the trunk is unavailable. If yes, post a new trace so we can see the Cisco responses, if any.

10

I’m sure it is now, to the 1760. The curiosity now is what is going on with the ISR4321. Since I now have a working setup - FreePBX 17 - pjsip - Cisco 1760 gateway - with the FreePBX trunk definition pretty much “bone stock”, (which means OPTIONS and INVITE are working normally) and duplicating that on the ISR does NOT work - I know the problem in the FreePBX-pjsip-ISR, connection is the ISR side of things, not the FreePBX side.

I suspect what you were interpreting as the ISR not responding to OPTION was actually the ISR not responding AT ALL. Which is mystifying, since the ISR seems perfectly able to initiate a SIP call. It just won’t respond to one.

11

Finally fixed it!

There were 2 changes I had to make in the ISR4321, both under the

voice service voip

configuration directive.

First, I had to remove the line:

mode border-element

What this directive actually did was modify the ISR4321 to activate so-called “CUBE” licensing. However, along with doing that, when turned on it (apparently) greatly reduces Cisco debugging output.

When I turned it off, then looked again at the SIP debugging output, I noticed among the much more copious output:

000234: Oct 20 03:08:24.230 PDT: //-1/xxxxxxxxxxxx/SIP/Error/sipSPILocateInviteDialogCCB:
 Ip Trust List Authentication failed for Incoming Request, method = OPTIONS

Apparently the so-called “Ip Trust List” thing is a new thing Cisco has added sometime between IOS 12 and IOS 16 to further strengthen security - probably to close a hole preventing people from the outside making free phone calls or something. Not a bad thing - when you know about it.

So, under the

voice service voip

I had to add:

 ip address trusted list
  ipv4 172.16.160.10

Now the trunk registered into the ISR4321 normally, and I was able to make outbound and inbound calls through it.

Allegedly, supposedly, I can turn back on the mode border-element line - but without really knowing all of the implications of what exactly it does - I’m not really willing to mess around with it.

Apparently not many Cisco people even understand what that line does as witness to this line of questioning:

CUBE: mode border element what really do? - Cisco Community

Something tells me that people who configure these CUBE devices for a living depend a horribly lot on pre-canned templates, or TAC support (that also probably uses pre-canned templates) to get devices configured and working.

As a further note to this - the ip address trusted list is a newer addition - virtually every example out there for connecting FreePBX or Asterisk to one of these devices as either a POTS or SIP gateway lacks this addition - since those examples predate Cisco IOS 15