Cisco 7975 and FreePBX


Hello everyone!

Asterisk: 16.9.0
Cisco 7975G w/ SIP FW: 9.4(2) SR4-3
Phone IP: (DHCP)

I have a Cisco 7975G running the latest SIP Firmware version, and I have a xml file that is parsed ok and hands the settings to the phone, but for some reason the phone will not get past the “Registering…” phase

After several hours of playing with this I am completely out of ideas on how to fix this. There are some mentions on here form 5+ years ago about setting NAT to “Never” in freePBX somewhere, though non are clear where, and the only place I can find it is in the Asterisk SIP Settings (I am using pjSip) and toggling that does not make a difference.

I also tried using firmware 8.5(4)S with the exact same results.

Below are the logs from the phone and the XML config file.

Thanks in advance for the help.

Here are the pjSIP logs from asterisk:

Here are the logs from the phone itself:

8399: WRN 21:15:30.090798 JVM: Startup Module Loader|cip.l10n.NetworkLocaleProperty:? - Unable to process LocaleProperty 'device.settings.config.localization.networklocale'
8400: WRN 21:15:30.175801 SECD: WARN:lookupCTL: ** no CTL, assume UCM NONSECURE
8401: ERR 21:15:30.524295 JVM: ..LOCALCONNECT FAILED
8402: NOT 21:15:30.581286 JVM: SIPCC-SIP_CTRL: sip_restart: In sip_restart
8403: NOT 21:15:30.592864 JVM: set_active_ccm: ccm=PRIMARY_CCM  port=0
8404: ERR 21:15:30.593596 JVM: SIP : sip_transport_setup_cc_conn : Admin has not configured a valid cucm for cucm index=SECONDARY_CCM=1.
8405: ERR 21:15:30.594367 JVM: SIP : sip_transport_setup_cc_conn : Admin has not configured a valid cucm for cucm index=TERTIARY_CCM=2.
8406: ERR 21:15:30.595060 JVM: SIP : sip_transport_setup_cc_conn : Admin has not configured a valid cucm for cucm index=SRST_CCM=3.
8407: ERR 21:15:30.595758 JVM: sip_regmgr_setup_cc_conns: NO VALID STANDBY CALL CONTROL AVAILABLE!
8408: NOT 21:15:30.596465 JVM: SIPCC-SIP_REG: sip_sm_init: Disabling mass reg state
8409: NOT 21:15:30.615824 JVM: SIPCC-SIP_REG: ccsip_register_all_lines: Disabling mass reg state
8410: NOT 21:15:30.616876 JVM: SIPCC-UI_API: 1/0, ui_set_sip_registration_state: 0
8411: NOT 21:15:30.619856 JVM: SIPCC-CC_API: 0/0, cc_int_feature: UI -> GSM: UPD_MEDIA_CAP       
8412: NOT 21:15:30.620963 JVM: SIPCC-SIP_CTRL: sip_restart: sip.taskInited is set to true 
8413: NOT 21:15:30.621763 JVM: SIPCC-CC_API: 0/0, cc_int_fail_fallback: SIP -> GSM: FAILOVER_FALLBACK   
8414: NOT 21:15:30.625160 JVM: SIPCC-DCSM: dcsm_process_event: DCSM 0   :(DCSM_READY:FEAT:UPD_MEDIA_CAP)
8415: NOT 21:15:30.627392 JVM: SIPCC-SIP_REG_STATE: 1/51, sip_reg_sm_process_event: SIP_REG_STATE_IDLE <- E_SIP_REG_REG_REQ
8416: NOT 21:15:30.629308 JVM: ccsip_messaging: sipSPIAddContactHeader: CFGID_DEVICE_NAME = SEP64D989C242E5
8417: NOT 21:15:30.632114 JVM: SIPCC-SIP_MSG_SEND: ccsip_dump_send_msg_info: <>:REGISTE: <sip:1001@> :109 REGISTER::64d989c2-42e5000a-fd20cf24-af188fca@
8418: NOT 21:15:30.832240 JVM: Startup Module Loader|cip.sipcc.SipCcAdapter:  - cmname= cmIp= port=5060 isValid=true
8419: ERR 21:15:30.834325 JVM: Startup Module Loader|cip.sipcc.SipCcAdapter:  - addSrstToCAgentList: isSrstSecure=false
8420: NOT 21:15:30.836001 JVM: Startup Module Loader|cip.midp.midletsuite.InstallerModule:? - propertyChanged - device.callagent.messages.0 value=0
8421: NOT 21:15:30.837928 JVM: Startup Module Loader|cip.sipcc.d:  - initializeLinePlane(): Mgmt Interface is in Service now..
8422: WRN 21:15:30.839600 JVM: Startup Module Loader|DisplayTask:? -  Line 1 property added with dn 1001
8423: ERR 21:15:30.841346 JVM: Startup Module Loader|cip.props.u:? - device.settings.energywise.keywords IO error.
8424: ERR 21:15:30.899385 JVM: tftpClient dialplan.xml /usr/cache/DP158232698 550001 1
8425: NOT 21:15:30.903249 JVM: Startup Module Loader|cip.cfg.ConfigManager:? - --->ConfigManager PropertyChanged: device.callagent.callcount
8426: NOT 21:15:30.904853 JVM: Startup Module Loader|cip.cfg.ConfigManager:? - <---ConfigManager PropertyChanged: device.callagent.callcount
8427: NOT 21:15:30.906494 JVM: Startup Module Loader|cip.midp.midletsuite.InstallerModule:? - propertyChanged - device.callagent.messages.0 value=0
8428: NOT 21:15:30.907867 xxtpClient: xxtp request rcv'd from /usr/tmp/tftp, srcFile = dialplan.xml, dstFile = /usr/cache/DP158232698 max size = 550001 
8429: NOT 21:15:30.908967 ESP: server 1 =  
8430: NOT 21:15:30.922136 xxtpClient: auth server - tftpList[0] = ::ffff: 
8431: NOT 21:15:30.922768 xxtpClient: look up server - 0 
8432: WRN 21:15:30.924796 SECD: WARN:lookupCTL: ** no CTL, assume TFTP NONSECURE
8433: NOT 21:15:30.927613 xxtpClient: secVal = 0xa 
8434: NOT 21:15:30.928332 xxtpClient: ::ffff: is a NONsecure server 
8435: NOT 21:15:30.928941 xxtpClient: temp retval = SRVR_NONSECURE, keep looking 
8436: NOT 21:15:30.929489 xxtpClient: retval = 10 
8437: NOT 21:15:30.930834 xxtpClient: Secure file requested 
8438: NOT 21:15:30.931487 xxtpClient: Non secure file approved  -- dialplan.xml  
8439: NOT 21:15:30.949471 HTTPCL: downdload will be limited to 537 KB
8440: ERR 21:15:30.955011 HTTPCL: connect() failed
8441: NOT 21:15:30.964677 SYSMSG: pid 29 (/sbin/httpcl) Normal Exit, status = 102
8442: INF 21:15:30.964717           runtime = 0.020 secs

8443: INF 21:15:30.964738          user cpu = 0.001228030 secs

8444: INF 21:15:30.964758        system cpu = 0.012194720 secs

8445: INF 21:15:30.964772    child user cpu = 0.000000000 secs

8446: INF 21:15:30.964787     child sys cpu = 0.000000000 secs

8447: INF 21:15:30.964808    sys interrupts = 0.000854890 secs for 22 interrupts

8448: INF 21:15:30.964832 total cpu = 0.013422750 secs ( 50% utilization )

8449: WRN 21:15:30.983327 xxtpClient: HTTP failed with code 102
8450: NOT 21:15:31.029141 TFTP: [28]:Requesting dialplan.xml from with size limit of 550001
8451: NOT 21:15:31.032485 TFTP: [28]:Finished --> rcvd 33 bytes 
8452: NOT 21:15:31.122562 JVM: SIPCC-SIP_REG_STATE: 1/51, sip_reg_sm_process_event: SIP_REG_STATE_REGISTERING <- E_SIP_REG_TMR_RETRY
8453: NOT 21:15:31.172547 xxtpClient: request server6 0 ---> :: 
8454: NOT 21:15:31.173733 ESP: server 2 = :: 
8455: NOT 21:15:31.195827 xxtpClient: request server6 0 ---> :: 
8456: NOT 21:15:31.212366 xxtpClient: request server6 1 ---> :: 
8457: NOT 21:15:31.213556 ESP: server 3 = :: 
8458: NOT 21:15:31.221283 ESP: send ADMIN, logging = 1, shell = 0, ipconfig = 1 
8459: NOT 21:15:31.236792 xxtpClient: request server6 1 ---> :: 
8460: ERR 21:15:31.247187 JVM: ..LOCALCONNECT FAILED
8461: ERR 21:15:31.250871 JVM: ..LOCALCONNECT FAILED
8462: ERR 21:15:31.254280 JVM: ..LOCALCONNECT FAILED
8463: ERR 21:15:31.257753 JVM: ..LOCALCONNECT FAILED
8464: ERR 21:15:31.262039 JVM: ..LOCALCONNECT FAILED
8465: ERR 21:15:31.265428 JVM: ..LOCALCONNECT FAILED
8466: ERR 21:15:31.268844 JVM: ..LOCALCONNECT FAILED
8467: WRN 21:15:31.287606 SECD: WARN:getTLInfoFromFile: ** phone has no TL file /flash0/sec/ctl//CTLFile.tlv
8468: WRN 21:15:31.288627 SECD: WARN:getTLInfoFromFile: ** phone has no TL file /flash0/sec/ctl//ITLFile.tlv
8469: WRN 21:15:31.293952 SECD: WARN:getTLInfoFromFile: ** phone has no TL file /flash0/sec/ctl//CTLFile.tlv
8470: WRN 21:15:31.294965 SECD: WARN:getTLInfoFromFile: ** phone has no TL file /flash0/sec/ctl//ITLFile.tlv
8471: WRN 21:15:31.300194 SECD: WARN:getTLInfoFromFile: ** phone has no TL file /flash0/sec/ctl//CTLFile.tlv
8472: WRN 21:15:31.301209 SECD: WARN:getTLInfoFromFile: ** phone has no TL file /flash0/sec/ctl//ITLFile.tlv
8473: WRN 21:15:31.306795 SECD: WARN:getTLInfoFromFile: ** phone has no TL file /flash0/sec/ctl//CTLFile.tlv
8474: WRN 21:15:31.307865 SECD: WARN:getTLInfoFromFile: ** phone has no TL file /flash0/sec/ctl//ITLFile.tlv
8475: NOT 21:15:31.319010 xxtpClient: request server 0 ---> 
8476: NOT 21:15:31.319851 ESP: server 0 = 
8477: NOT 21:15:31.342964 xxtpClient: request server 1 --->  
8478: NOT 21:15:31.344121 ESP: server 1 =  
8479: NOT 21:15:31.366526 xxtpClient: request server 0 ---> 
8480: NOT 21:15:31.382980 xxtpClient: request server6 0 ---> :: 
8481: NOT 21:15:31.384230 ESP: server 2 = :: 
8482: NOT 21:15:31.415999 xxtpClient: request server 1 --->  
8483: NOT 21:15:31.435799 xxtpClient: request server6 1 ---> :: 
8484: NOT 21:15:31.436924 ESP: server 3 = :: 
8485: NOT 21:15:31.452302 CDP-D: cdpGetPortCfg SPANTOPC CFG:11
8486: NOT 21:15:31.545590 xxtpClient: request server6 0 ---> :: 
8487: NOT 21:15:31.566701 xxtpClient: request server6 1 ---> :: 
8488: ERR 21:15:31.572030 JVM: ..LOCALCONNECT FAILED
8489: ERR 21:15:31.575496 JVM: ..LOCALCONNECT FAILED
8490: ERR 21:15:31.578890 JVM: ..LOCALCONNECT FAILED
8491: ERR 21:15:31.583192 JVM: ..LOCALCONNECT FAILED
8492: ERR 21:15:31.586529 JVM: ..LOCALCONNECT FAILED
8493: ERR 21:15:31.589907 JVM: ..LOCALCONNECT FAILED
8494: ERR 21:15:31.593390 JVM: ..LOCALCONNECT FAILED
8495: NOT 21:15:32.122323 JVM: SIPCC-SIP_REG_STATE: 1/51, sip_reg_sm_process_event: SIP_REG_STATE_REGISTERING <- E_SIP_REG_TMR_RETRY
8496: NOT 21:15:34.126417 JVM: SIPCC-SIP_REG_STATE: 1/51, sip_reg_sm_process_event: SIP_REG_STATE_REGISTERING <- E_SIP_REG_TMR_RETRY
8497: NOT 21:15:38.122252 JVM: SIPCC-SIP_REG_STATE: 1/51, sip_reg_sm_process_event: SIP_REG_STATE_REGISTERING <- E_SIP_REG_TMR_RETRY
8498: NOT 21:15:42.122298 JVM: SIPCC-SIP_REG_STATE: 1/51, sip_reg_sm_process_event: SIP_REG_STATE_REGISTERING <- E_SIP_REG_TMR_RETRY

And here is my XML settings file:

<?xml version="1.0" encoding="UTF-8"?>
                        <timeZone>Pacific Standard/Daylight Time</timeZone>

           <member priority="0">










        <line button="1">
           <authPassword>{8 character password}</authPassword>


At the Asterisk command prompt, type
pjsip set logger on
Do you see registration requests on the console? If so, post a request and any associated replies.

If not, run sngrep (or tcpdump) and see if any REGISTER requests are reaching the PBX. If so, they are likely being blocked by FreePBX firewall.

If the requests are not reaching the PBX, try to capture traffic at the phone to see whether anything is being sent, and to where.

#3 —> the pjSIP conversation and registration attempts.

I realized how to do this after I posted, but before you replied and realized I was looking at the sip logger. The request is getting to asterisk.

There is some mention about the phone being unauthorized, so I went and changed the secret on the extension in freePBX and then copied and pasted it into the XML to be sure they are exactly the same, I also shortened it to 7 characters, just numbers and lower case letters. Alas this made no difference.

Firewall is off, and along those lines there are no blocked ip in the asterisk -iptables fail2ban jail.


The Cisco is sending REGISTER from a ephemeral port but expecting a response on port 5060.

Try setting Force rport for the extension to No and retest. If no luck, post a new log.

Please use if possible. If you must use for some reason, confirm that Paste Expiration is set to Never. Otherwise, a future reader of this thread won’t be able to follow along.


That did it, the phone is now registered and I can move to testing it.

Got it, did not know that was a thing. I moved the original logs over there, and set it to “forever”



So this change allows the phone to register, but it causes my AnveoDirect trunk to go offline. Any idea why? Is there a work around for this?


Sorry, I have no idea how these could be related; the setting should affect just one extension. Since AD doesn’t use registration, I assume that FreePBX is sending OPTIONS and getting no response. Can you post this packet? If you turn off qualify, what happens on an outbound call attempt? What happens on incoming?


I think this might be a bug. I went into the trunk settings to check the rport setting, it was listed as on. So without changing anything I clicked save and re-applied the config, this did not fix it (didn’t think it would). Went into the Asterisk console and turned on pjsip logging. and could see the registration request being sent with no reply coming back.

So out of desperation I went back into the trunk settings, scrolled to rport setting, click “On” even though it was allready set to that, saved and applied the setting and the trunk immediately back online and is working.


If there is a bug, please post it at .

However, I don’t understand what you are saying:

Registration for what? AD does not accept registration. Do you mean that saving the trunk config caused your Cisco phone registration to fail? Or is this registration for some other extension or trunk?

In any case, Force rport should only apply to replies to incoming requests; outgoing REGISTER or OPTIONS should be unaffected. And, on my AD incoming trunks, the INVITE’s Via header has the rport tag, so ‘forcing’ it should have no effect at all.


Sorry, I am new to this, and still learning how it all works. I guess it’s not a registration, but a “SIP request” which received no response.

I just saw this over and over again:

<--- Transmitting SIP request (434 bytes) to UDP: --->
Via: SIP/2.0/UDP {myPublicIP}:5060;rport;branch=z9hG4bKPj02db24b5-c1ba-4d1f-a71d-dd93ccbcff67
From: <sip:AnveoDirect@>;tag=61b15994-cd13-420d-bdb4-13dddddc8a40
To: <>
Contact: <sip:AnveoDirect@{myPublicIP}:5060>
Call-ID: acc2ea00-e1ea-4b93-97d2-32e011b4a8d9
CSeq: 22357 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-
Content-Length:  0

With nothing coming back.


Asterisk implements the Qualify function by sending periodic OPTIONS requests. It considers the trunk to be online if it gets any response, even an error.

Assuming that you still have the FreePBX firewall disabled, my guess is that your hardware router/firewall is blocking the replies. If it has a SIP ALG, try turning that off. Otherwise, post details and someone here might know what setting is responsible. If you have a way to capture traffic on its WAN interface, that would confirm or refute whether it is to blame.


It’s probably not my opnSense firewall, and yes the freePBX firewall is off (and will remain off). This setup has worked 100% for a few months now. As soon as I toggle the rport setting to off on the extension, replies from Anveo stop reaching asterisk. Even on the off chance this is firewall related, it is still very much unexpected behavor of the setting.

I have verified that toggling the rport setting to off on an extension causes the trunk to go offline, and then turning it back on causes the trunk to come back online.You have to turn rport off on the extension and apply the settings. The trunk will go offline. Then if go the trunk settings and find the rport setting and click “on” (even though it is shown as all ready on), save the trunk settings and then apply the config and the trunk will then become available again and everything works. This is repeatable, and no other settings were changed in the process, and this is why I suspect it to be a bug.


If you can see a difference between the OPTIONS requests (or any other packets directed to the trunk) as a result of the extension rport setting, you could certainly document it as a bug.

If not, I suspect that AD (or possibly your opnSense) is seeing closely spaced requests as a result of the reload and temporarily banning your IP. Unfortunately, I could not replicate this here.


I’ll need to check that, however I do not think that is how opnSense works, the traffic to and from freePBX and AD is set to be explicitly allowed, which means it won’t matter how many requests are made, they’ll all be put through. opnSense on the other hand does not do well with UDP traffic send out on one port and returned on another, which if I am not mistaken is what the rport setting changes.

So it is very likely that whatever router you have just handles this, so the toggling the rport setting would not make a difference, or if it is opnSense then you have some sort of NAT setup that compensated for this.

(system) closed #15

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