Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- :
- About kylebrogers
Stats
Member since
05-06-2010
391
Posts
37
Helpful
3
Solutions
Created by
kylebrogers
in IP Telephony and Phones
in IP Telephony and Phones
08-07-2019
12:47 PM
08-07-2019
12:47 PM
Setup: 2-server cluster CUCM 12.0.1.10000-10 Database replication is clean Phones being converted are phones that are in production but using SCCP All of the 7941s, 7942s, 7961s, and 7962s converted successfully and downloaded their configs successfully. Only 7940s and 7960s are having issues. There are no firewalls, ACLs, etc between the phones and the CUCMs. The capture/logs below are from when I tested with the Sub, which is in a different subnet but I get the same if I do this with the Pub, which is in the same subnet/VLAN as the phones I'm testing with. We have to convert all of our SCCP phones to SIP to accommodate a SIP-only recording software. These older models are on track to be replaced in the next year or so, but we still have to make them work until they get replaced I am able to successfully convert a 7940 or 7960 to SIP firmware without incident. The problem is that when it goes to request its config file from CUCM, it is told that the file is not found. I have verified both from packet captures taken on the CUCM and from trace logs of the TFTP service that this is what's happening. The phone correctly requests its configuration file and the TFTP service says the file doesn't exist. I can browse to the file using http://<CUCM IP>:6970/SIP<MAC>.cnf so I know that the file exists on the Call Manager. If I move this file to my laptop and set up a TFTP server on my laptop I can point the phone to my laptop for TFTP and the phone will successfully download the file from my laptop and register to CUCM. The issue occurs regardless of whether I set the Pub or Sub as the Option 150 target. TFTP logs show the same errors. Below are the logs that I'm seeing. Anyone have any thoughts on what is going on and why this would only affect 7940s and 7960s? 10.25.142.5 = CUCM 10.25.101.55 = PHONE 0012006820E5 = PHONE MAC Packet Capture: SEE ATTACHED SCREENSHOT TFTP Log: 00000414.000 |12:09:44.747 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf510d2c0](), server socket(74) INFO:: File Requested CTLSEP0012006820E5.tlv 00000415.000 |12:09:44.747 |SdlStat |Period: 1693s #Lines: 2 #Bytes: 315 Total Number of Buffers: 2000 Free LWM: 1998 Free LWM(total): 1938 00000416.000 |12:09:44.770 |AppInfo |INFO: TFTPEngine::sendNAK[0xf510d2c0~0~10.25.101.55~50604], File[CTLFile.tlv], Error(1) 00000417.000 |12:09:44.792 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf511ffb0](), server socket(74) INFO:: File Requested SEP0012006820E5.cnf.xml 00000418.000 |12:09:44.793 |AppInfo |CTFTPDB_DeviceVersionRecords::loadRecords(), For DeviceId[9eb830b5-f40f-30c9-3b19-8c5cc97c0393] *** commondeviceconfig Record[] Not Found *** 00000419.000 |12:09:44.806 |AppInfo |INFO: TFTPEngine::sendNAK[0xf511ffb0~1~10.25.101.55~50605], File[SEP0012006820E5.cnf.xml], Error(1) 00000420.000 |12:09:44.806 |AppInfo |CTFTPDB_DeviceVersionRecords::loadRecords(), For DeviceId[9eb830b5-f40f-30c9-3b19-8c5cc97c0393] *** commondeviceconfig Record[] Not Found *** 00000421.000 |12:09:44.808 |AppInfo |INFO: TFTPEngine::sendNAK[0xf511ffb0~1~10.25.101.55~50605], File[SEP0012006820E5.cnf.xml.sgn], Error(1) 00000422.000 |12:09:44.808 |AppInfo |INFO: TFTPEngine::sendNAK[0xf511ffb0~1~10.25.101.55~50605], File[SEP0012006820E5.cnf.xml], Error(1) 00000423.000 |12:09:44.836 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf51209b0](), server socket(74) INFO:: File Requested SIP0012006820E5.cnf 00000424.000 |12:09:44.840 |AppInfo |INFO: TFTPEngine::sendNAK[0xf51209b0~2~10.25.101.55~50606], File[SIP0012006820E5.cnf], Error(1) 00000425.000 |12:09:44.860 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf51213b0](), server socket(74) INFO:: File Requested MGC0012006820E5.cnf 00000426.000 |12:09:44.860 |AppInfo |INFO: TFTPEngine::sendNAK[0xf51213b0~3~10.25.101.55~50607], File[MGC0012006820E5.cnf], Error(1) 00000427.000 |12:09:44.880 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf5121db0](), server socket(74) INFO:: File Requested XMLDefault.cnf.xml 00000428.000 |12:09:45.053 |AppInfo |TFTPEngine::processMessage[0xf5121db0~4~10.25.101.55~50608], Unexpected Opcode[5] Expecting ACK Block[17], Socket[13] FileName[XMLDefault.cnf.xml], th_block [11] Abort... 00000429.000 |12:09:45.070 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf51227b0](), server socket(74) INFO:: File Requested SIPDefault.cnf 00000430.000 |12:09:45.075 |AppInfo |TID[d7925b70] INFO: TFTPEngine::processMessage[0xf51227b0~5~10.25.101.55~50609], Transferred[SIPDefault.cnf] Socket[13] 00000431.000 |12:09:55.628 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf51231b0](), server socket(74) INFO:: File Requested SIPDefault.cnf 00000432.000 |12:09:55.628 |SdlStat |Period: 11s #Lines: 16 #Bytes: 2468 Total Number of Buffers: 2000 Free LWM: 1998 Free LWM(total): 1938 00000433.000 |12:09:55.634 |AppInfo |TID[d7925b70] INFO: TFTPEngine::processMessage[0xf51231b0~6~10.25.101.55~49992], Transferred[SIPDefault.cnf] Socket[13] 00000434.000 |12:09:55.813 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf5123bb0](), server socket(74) INFO:: File Requested SIP0012006820E5.cnf 00000435.000 |12:09:55.813 |AppInfo |INFO: TFTPEngine::sendNAK[0xf5123bb0~7~10.25.101.55~49993], File[SIP0012006820E5.cnf], Error(1) 00000436.000 |12:09:58.032 |AppInfo | TID[d4720b70] TFTPEngine::getRequest[0xf51245b0](), server socket(74) INFO:: File Requested RINGLIST.DAT 00000437.000 |12:09:58.047 |AppInfo |TID[d7925b70] INFO: TFTPEngine::processMessage[0xf51245b0~8~10.25.101.55~50000], Transferred[RingList.DAT] Socket[13]
... View more
Created by
kylebrogers
in IP Telephony and Phones
in IP Telephony and Phones
06-18-2019
10:05 AM
06-18-2019
10:05 AM
Thank you for the reply. It's still on the SIP firmware, as it still displays SIP in the top right corner of the screen and the errors still list it as being unable to locate SIP<mac> rather than SEP<mac>. The linked doc is what I started working from (though I've had to find additional documentation because things vary wildly between firmware versions.
... View more
Created by
kylebrogers
in IP Telephony and Phones
in IP Telephony and Phones
06-18-2019
08:35 AM
06-18-2019
08:35 AM
I am attempting to convert a bunch of old 7940s and 7960s from SCCP to SIP because the recording software we want to use does not support SCCP. The 7940 I'm testing is running the following SIP firmware: App Load ID: POS3-07-5-00 (That's SIP 7.5 on Cisco's software site) Boot Load ID: PC030301 CUCM is version 12.0.1 Network status shows the CUCM Pub as the phone's TFTP server that it received from DHCP When I browse to http://<IP of Pub>:6970/SIP<MAC>.cnf I see the output of the config file (same if I add .xml to the end). The device has been built in the system as a 7940 with protocol set to SIP. There is a line attached to the phone and it shows up in the cnf file if I browse to it. In the status on the phone I get the following: E600 REG send failure: REGISTER E102 MISC Error: No time server W350 invalid proxy_backup W351 invalid proxy_emergency W310 8 Error(s) Parsing: SIPDefault.cnf W220 TFTP Error: Not Found SIP<MAC>.cnf I have factory reset the phone but that did not change anything. When the phone comes up, it looks like it has a line labeled AUTO-REG with a symbol of a phone with an X over it. I have checked the CM Server settings and neither CUCM in the cluster has auto-registration turned on.
... View more
Labels:
Created by
kylebrogers
in Network Security
in Network Security
01-30-2019
07:00 AM
01-30-2019
07:00 AM
Thank you. I still don't understand why the reboot was occurring at the start of the file transfer, but I updated via the Chassis Manager and it worked perfectly.
... View more
Created by
kylebrogers
in Network Security
in Network Security
01-29-2019
09:34 PM
01-29-2019
09:34 PM
I think thought that might be the case but couldn’t find any documentation on upgrading ASA on a 2130, Just stuff on migrating between ASA and FTD code.
... View more
Created by
kylebrogers
in Network Security
in Network Security
01-29-2019
06:33 PM
01-29-2019
06:33 PM
I have a new 2130 with ASA code (not running FTD). I have configured it and everything looks good. It is currently running version 9.8(2). When I try to copy the 9.8.3.8 image file to the flash, the moment I start the copy (before it gets past 0% copied), the ASA reboots. The checksum for the file matches what is on Cisco.com, but that doesn't really matter anyway since the issue occurs at the start of the file transfer. If I try and FTP or TFTP it, the file appears to copy over, but when the copy job "finishes", the file is never in flash. I switched from FreeFTPd to Filezilla for FTP just to try another program and the file copy completes, but the ASA throws the error "signature not valid for file <path to file>". I checked the file again with an MD5 checker and it matches the MD5 hash on Cisco.com. I can't find a way to access the USB on the chassis from the ASA to try copying from USB. Obviously the device has been rebooted several times. Anyone have any ideas?
... View more
Re: Calls through CUCM 10.5 to H323 fax...
in IP Telephony and Phones
01-08-2019
02:04 PM
01-08-2019
02:04 PM
Thanks for the pointer to TranslatorX. I was able to dig through the SDL files and find that it was claiming there was no route group in the route list. Double-checked that there was, but removed it, saved, re-added it, saved, and it started working.
Not sure if something got mucked up behind the scenes in the database or what.
... View more
Re: Calls through CUCM 10.5 to H323 fax...
in IP Telephony and Phones
01-08-2019
01:36 PM
01-08-2019
01:36 PM
Have you tossed your SDL and call log into TranslatorX to help parse the trace? You can use the checkboxes at the bottom of TranslatorX to remove SIP, SCCP and MGCP messages which can greatly reduce the number of lines you are looking at. What you are looking for is the H323 signaling packet(s) coming out of CUCM towards what it believes to be the fax gateway. Look for the IP address and port number it is attempting to use. - I haven't but that's a good idea. I'll hit that next and let you know what I find.
... View more
Re: Calls through CUCM 10.5 to H323 fax...
in IP Telephony and Phones
01-08-2019
11:04 AM
01-08-2019
11:04 AM
In the trace file, do you see CUCM attempting to send H323 signaling packets to the router? Can you share those? --- I'm not sure which traces would provide that. I have the H225 and H245 traces turned on, but all I got (outside ofthe SDL folder) was the call log. If you can tell me which traces to turn on that would provide the signaling I can definitely do that. What I'm hoping to determine from that is whether the router is generating the cause code 27 and passing it to CUCM, or if CUCM is generating it because it can't talk to the router. --- I've rebooted the CUCM cluster and the H323 fax server (there's no gateway between them) multiple times. I don't know how the fax server (which is the H323 device running in a VM) would be generating a code 27 though because Wireshark tells me that no packets are passing either way between the CUCM and the fax server. This happens with all calls, including those from a CUCM-registered phone. I discussed using the PRI gateway (also H323) and having it bypass the CUCM and everything works fine then, so I know it's an issue between CUCM and the H323 fax server. Do other calls flow through this gateway other than the faxing and if so are those working? --- The only calls that are failing are calls that are routed to the CUCM that hit Route Patterns that point that call to the H323 gateway. All calls that hit any other route pattern or phone work and all calls that route from the gateway directly to the fax server work. What does the Dialed Number Analyzer say about the call? --- That was one of the first places I went. It's saved my tail more times than I can count. But it says the call should be routed and sent to the H323 gateway. What is the output on the router of: show dialplan dialpeer <incoming dialpeer number> number <number send to router> --- Between the CUCM and fax server I don't have an intermediate device like a router. On the PRI router (prior to my making new dial peers to bypass CUCM while I figure this out), the dial peers were large blocks (such as matching 55..) because the fax numbers are interspersed with desk lines. So 55XX would all hit one dialpeer on the gateway, then go to CUCM where the specific number would either hit a Route Pattern pointed at the fax server or an extension on a phone. Since the phones work fine, the same dial peer was sending fax calls to the CUCM as well. Sorry, I know there's not much useful info there but I hope that helps explain the setup and where the issue appears to lie. I appreciate your taking time trying to help me figure out what's going on.
... View more
Created by
kylebrogers
in Network Security
in Network Security
12-13-2018
09:28 AM
12-13-2018
09:28 AM
If I create a new file or IPS policy and need to apply it to hundreds of Access Control Rules, is there a way to do this in bulk in the FMC interface or do I have to go one at a time through all the rules? I'm guessing that someone can code a way to do it but I'm looking for a way someone can do it natively through the FMC interface.
... View more
Created by
kylebrogers
in IP Telephony and Phones
in IP Telephony and Phones
06-28-2018
07:57 AM
06-28-2018
07:57 AM
Thank you for you help.
... View more
Created by
kylebrogers
in IP Telephony and Phones
in IP Telephony and Phones
06-28-2018
07:54 AM
06-28-2018
07:54 AM
So that would be an issue on the PRI side of the gateway (either the telco provider, the sender's telco, or the sender's device)? Is that correct?
... View more
Created by
kylebrogers
in IP Telephony and Phones
in IP Telephony and Phones
06-28-2018
07:45 AM
06-28-2018
07:45 AM
If I'm on the gateway between the telco and the internal fax server, how can I determine which one is causing the issue? The CRC would be run on a packet arriving either from one or the other, but I don't see a directional indicator. Here is another call that had an issue: =============== 2018-05-08 08:28:42 Local7.Debug 10.14.114.10 661435: Destination Interface=0xC24D1C64, Destination Call Id=28485, Source Call Id=28486, Xmit Function=0x351DE748 2018-05-08 08:28:42 Local7.Debug 10.14.114.10 661436: May 8 08:28:06 CDT: 0/0/0:23 745394056 fr-entered=10(ms) 2018-05-08 08:28:45 Local7.Debug 10.14.114.10 661437: 2018-05-08 08:28:45 Local7.Debug 10.14.114.10 661438: timestamp=745396686 fr-msg-tx DIS 2018-05-08 08:28:48 Local7.Debug 10.14.114.10 661439: 2018-05-08 08:28:48 Local7.Debug 10.14.114.10 661440: timestamp=745399856 fr-msg-det DCS 2018-05-08 08:28:51 Local7.Debug 10.14.114.10 661441: 2018-05-08 08:28:51 Local7.Debug 10.14.114.10 661442: timestamp=745403596 fr-msg-tx CFR 2018-05-08 08:29:13 Local7.Debug 10.14.114.10 661443: 2018-05-08 08:29:13 Local7.Debug 10.14.114.10 661444: timestamp=745425646 FR_BAD_CRC_LS_DATA 0x0 bytes 2018-05-08 08:29:13 Local7.Debug 10.14.114.10 661445: timestamp=745425646 fr-msg-tx bad crc, 0 bytes 2018-05-08 08:29:13 Local7.Debug 10.14.114.10 661446: May 8 08:28:38 CDT: //28486/77E794DAA58D/CCAPI/cc_api_call_disconnected: 2018-05-08 08:29:13 Local7.Debug 10.14.114.10 661447: Cause Value=16, Interface=0x225ECF4C, Call Id=28486 2018-05-08 08:29:13 Local7.Debug 10.14.114.10 661448: May 8 08:28:38 CDT: //28486/77E794DAA58D/CCAPI/cc_api_call_disconnected: 2018-05-08 08:29:13 Local7.Debug 10.14.114.10 661449: Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0) ======================== I see a DIS, then a DCS, then a CFR, then the CRC error. But how can I tell whether the CRC error is on data received from the carrier down the PRI or on a packet received on the network interface from the fax server?
... View more
Created by
kylebrogers
in IP Telephony and Phones
in IP Telephony and Phones
06-27-2018
03:56 PM
06-27-2018
03:56 PM
Sorry, I should have noted that in my initial posting but forgot. My first assumption was PRI issues so I checked for slips, etc but it's running clean.
... View more
06-27-2018
03:07 PM
So this all started when the customer changed fax server companies (on prem server). We had no issues with the old one. This one is having intermittent issues. Diagram: PRI --- Cisco H323 VGW -- CUCM 10.x -- VoIP-based Fax server (T.38) So it's an H323 gateway, but CUCM is involved because we're using route patterns to direct fax calls instead of dial peers. There are a lot of fax numbers and they're not contiguous so it's a lot easier to deal with them this way than to use dial peers on the gateway for the fax numbers. The issues are intermittent and inconsistent, so testing is a problem. In the end, I turned on some debugs on the gateway and pointed it to a syslog server. That way I could coordinate errors in the fax server to errors in the debugs. The output below is a call that was incomplete according to the fax server. I have pasted more below, but I believe the issue is in these lines: ==================================== 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648047: May 8 08:11:48 CDT: 0/0/0:23 744416714 fr-entered=10(ms) 2018-05-08 08:12:27 Local7.Debug 10.14.114.10 648048: 2018-05-08 08:12:27 Local7.Debug 10.14.114.10 648049: timestamp=744419342 fr-msg-tx DIS 2018-05-08 08:12:31 Local7.Debug 10.14.114.10 648050: 2018-05-08 08:12:31 Local7.Debug 10.14.114.10 648051: timestamp=744423032 FR_BAD_CRC_LS_DATA 0x0 bytes 2018-05-08 08:12:31 Local7.Debug 10.14.114.10 648052: timestamp=744423032 fr-msg-tx bad crc, 0 bytes 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648053: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648054: timestamp=744425652 fr-msg-tx DIS 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648055: May 8 08:11:58 CDT: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x25F3 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648056: Cause i = 0x8290 - Normal call clearing 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648057: May 8 08:11:58 CDT: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0xA5F3 ============================================== It looks like we're seeing CRC issues. I've checked the interface counters on the gateway for the interface that H.323 is bound to and there are no errors (aside from some unknown protocol drops) so I don't believe that the network is causing issues. Do these CRC errors in this log indicate that the gateway received a packet from the fax server but that the CRC of the data portion of the packet did not pass the CRC check? Or does it mean something else? Any thoughts on what might cause this? I've read several threads where this error is mentioned but I don't see any clear indicator of the cause. ++++++++++++ Longer Debug ++++++++++++
2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647904: May 8 08:11:45 CDT: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0xA5F6 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647905: Channel ID i = 0xA98382 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647906: Exclusive, Channel 2 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647907: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_set_called_ccm_detected: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647908: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647909: CallInfo(called ccm detected=TRUE ccmVersion 3) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647910: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_call_proceeding: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647911: Interface=0x225ECF4C, Progress Indication=NULL(0) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647912: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_set_called_ccm_detected: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647913: CallInfo(called ccm detected=TRUE ccmVersion 3) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647914: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_set_delay_xport: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647915: CallInfo(delay xport=TRUE) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647916: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_call_alert: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647917: Interface=0x225ECF4C, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647918: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_call_alert: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647919: Call Entry(Retry Count=0, Responsed=TRUE) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647920: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_set_called_ccm_detected: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647921: CallInfo(called ccm detected=TRUE ccmVersion 3) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647922: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_call_notify: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647923: Data Bitmask=0x5, Interface=0x225ECF4C, Call Id=28402 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647924: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccCallAlert: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647925: Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647926: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccCallAlert: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647927: Call Entry(Responsed=TRUE, Alert Sent=TRUE) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647928: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccGenerateToneInfo: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647929: Stop Tone On Digit=FALSE, Tone=Ring Back, 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647930: Tone Direction=Network, Params=0x0, Call Id=28401 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647931: May 8 08:11:45 CDT: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0xA5F6 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647932: Progress Ind i = 0x8188 - In-band info or appropriate now available 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647933: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_get_ssCTreRoutingNotSupported: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647934: CallInfo(ssCTreRoutingNotSupported=FALSE) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647935: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_get_ccm_detected: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647936: CallInfo(ccm detected=TRUE) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647937: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccCallNotify: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647938: Data Bitmask=0x5, Call Id=28401 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647939: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/ccIsInfoRingback: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647940: Returning dpRingBack=0 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647941: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_call_connected: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647942: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647943: Interface=0x225ECF4C, Data Bitmask=0x0, Progress Indication=NULL(0), 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647944: Connection Handle=0 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647945: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_call_connected: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647946: Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647947: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_set_called_ccm_detected: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647948: CallInfo(called ccm detected=TRUE ccmVersion 3) 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647949: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_call_notify: 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647950: Data Bitmask=0x5, Interface=0x225ECF4C, Call Id=28402 2018-05-08 08:12:20 Local7.Debug 10.14.114.10 647951: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccGenerateToneInfo: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647952: Stop Tone On Digit=FALSE, Tone=Null, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647953: Tone Direction=Network, Params=0x0, Call Id=28401 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647954: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccConferenceCreate: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647955: (confID=0xFFFFFFFF, callID1=0x6EF1, gcid=315AFE1C-51F811E8-A57878DA-6ED54208, tag=0x0) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647956: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/ccConferenceCreate: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647957: (confID=0xFFFFFFFF, callID2=0x6EF2, gcid=315AFE1C-51F811E8-A57878DA-6ED54208, tag=0x0) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647958: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccConferenceCreate: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647959: Conference Id=0xFFFFFFFF, Call Id1=28401, Call Id2=28402, Tag=0x0 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647960: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/cc_api_bridge_done: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647961: Conference Id=0x25E8, Source Interface=0xC24D1C64, Source Call Id=28401, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647962: Destination Call Id=28402, Disposition=0x0, Tag=0xFFFFFFFF 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647963: May 8 08:11:45 CDT: //28402/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647964: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647965: May 8 08:11:45 CDT: cc_api_get_xcode_stream : 4819 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647966: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_bridge_done: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647967: Conference Id=0x25E8, Source Interface=0x225ECF4C, Source Call Id=28402, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647968: Destination Call Id=28401, Disposition=0x0, Tag=0x0 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647969: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/cc_generic_bridge_done: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647970: Conference Id=0x25E8, Source Interface=0x225ECF4C, Source Call Id=28402, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647971: Destination Call Id=28401, Disposition=0x0, Tag=0x0 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647972: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccConferenceCreate: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647973: Call Entry(Conference Id=0x25E8, Destination Call Id=28402) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647974: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/ccConferenceCreate: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647975: Call Entry(Conference Id=0x25E8, Destination Call Id=28401) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647976: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccConferenceCreate: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647977: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647978: May 8 08:11:45 CDT: confID:0x25E8; callEntry1 callID1:0x6EF1, type:6; callEntry2 callID2:0x6EF2, type:1 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647979: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/cc_api_caps_ind: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647980: Destination Interface=0x225ECF4C, Destination Call Id=28402, Source Call Id=28401, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647981: Caps(Codec=0x1, Fax Rate=0x1, Fax Version:=0, Vad=0x1, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647982: Modem=0x2, Codec Bytes=20, Signal Type=3) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647983: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/cc_api_caps_ind: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647984: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647985: Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms), 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647986: Playout Max=1000(ms), Fax Nom=300(ms)) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647987: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_get_ssCTreRoutingNotSupported: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647988: CallInfo(ssCTreRoutingNotSupported=FALSE) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647989: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_get_ccm_detected: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647990: CallInfo(ccm detected=TRUE) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647991: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccCallNotify: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647992: Data Bitmask=0x5, Call Id=28401 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647993: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/cc_process_notify_bridge_done: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647994: Conference Id=0x25E8, Call Id1=28401, Call Id2=28402 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647995: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_caps_ind: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647996: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647997: Destination Interface=0xC24D1C64, Destination Call Id=28401, Source Call Id=28402, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647998: Caps(Codec=0x1, Fax Rate=0x10, Fax Version:=0, Vad=0x1, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 647999: Modem=0x0, Codec Bytes=160, Signal Type=2) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648000: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_caps_ind: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648001: Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms), 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648002: Playout Max=1000(ms), Fax Nom=300(ms)) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648003: May 8 08:11:45 CDT: //28402/315AFE1CA578/CCAPI/cc_api_caps_ack: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648004: Destination Interface=0xC24D1C64, Destination Call Id=28401, Source Call Id=28402, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648005: Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_7200(0x10), Fax Version:=0, Vad=OFF(0x1), 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648006: Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3460) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648007: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/cc_api_caps_ack: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648008: Destination Interface=0x225ECF4C, Destination Call Id=28402, Source Call Id=28401, 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648009: Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_7200(0x10), Fax Version:=0, Vad=OFF(0x1), 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648010: Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3460) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648011: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccCallConnect: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648012: Progress Indication=NULL(0), Data Bitmask=0x1 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648013: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/ccCallConnect: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648014: Call Entry(Connected=TRUE, Responsed=TRUE) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648015: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/cc_api_voice_mode_event: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648016: Call Id=28401 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648017: May 8 08:11:45 CDT: //28401/315AFE1CA578/CCAPI/cc_api_voice_mode_event: 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648018: Call Entry(Context=0x39E7AC48) 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648019: May 8 08:11:45 CDT: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8 callref = 0xA5F6 2018-05-08 08:12:21 Local7.Debug 10.14.114.10 648020: May 8 08:11:46 CDT: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x25F6 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648021: May 8 08:11:48 CDT: //28402/315AFE1CA578/CCAPI/cc_api_t38_fax_start: 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648022: Destination Interface=0xC24D1C64, Destination Call Id=28401, Source Call Id=28402, 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648023: Caps(Codec=T38Fax(0x10000), Fax Rate=FAX_RATE_7200(0x10),Fax Version:=0, Vad=OFF(0x1), 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648024: Modem=OFF(0x0), Codec Bytes=40, Signal Type=2) 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648025: May 8 08:11:48 CDT: //28402/315AFE1CA578/CCAPI/cc_api_t38_fax_start: 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648026: Destination Interface=0xC24D1C64, Destination Call Id=28401, Source Call Id=28402, 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648027: Caps(Codec=T38Fax(0x10000), Fax Rate=FAX_RATE_7200(0x10),Fax Version:=0, Vad=OFF(0x1), 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648028: Modem=OFF(0x0), Codec Bytes=40, Signal Type=2) 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648029: May 8 08:11:48 CDT: //28401/315AFE1CA578/CCAPI/cc_api_remote_codec_dnld_done: 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648030: 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648031: Destination Interface=0xC24D1C64, Destination Call Id=28401, Source Call Id=28402, Xmit Function=0x351DE748 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648032: May 8 08:11:48 CDT: //28401/xxxxxxxxxxxx/CCAPI/cc_api_local_codec_dnld_done: 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648033: (dstVdbPtr=0x225ECF4C, dstCallId=0x6EF2, srcCallId=0x6EF1) 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648034: May 8 08:11:48 CDT: //28401/315AFE1CA578/CCAPI/cc_api_local_codec_dnld_done: 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648035: (dstVdbPtr=0x225ECF4C, dstCallId=0x6EF2, srcCallId=0x6EF1) 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648036: May 8 08:11:48 CDT: //28402/315AFE1CA578/CCAPI/cc_api_local_codec_dnld_done: 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648037: Destination Interface=0x225ECF4C, Destination Call Id=28402, Source Call Id=28401 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648038: May 8 08:11:48 CDT: //28401/xxxxxxxxxxxx/CCAPI/cc_api_local_codec_dnld_done: 2018-05-08 08:12:24 Local7.Debug 10.14.114.10 648039: 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648040: (dstVdbPtr=0x225ECF4C, dstCallId=0x6EF2, srcCallId=0x6EF1) 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648041: May 8 08:11:48 CDT: //28401/315AFE1CA578/CCAPI/cc_api_local_codec_dnld_done: 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648042: (dstVdbPtr=0x225ECF4C, dstCallId=0x6EF2, srcCallId=0x6EF1) 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648043: May 8 08:11:48 CDT: //28402/315AFE1CA578/CCAPI/cc_api_local_codec_dnld_done: 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648044: Destination Interface=0x225ECF4C, Destination Call Id=28402, Source Call Id=28401 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648045: May 8 08:11:48 CDT: //28402/315AFE1CA578/CCAPI/cc_api_set_fax_mode: 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648046: Destination Interface=0x225ECF4C, Destination Call Id=28402, Source Call Id=28401 2018-05-08 08:12:25 Local7.Debug 10.14.114.10 648047: May 8 08:11:48 CDT: 0/0/0:23 744416714 fr-entered=10(ms) 2018-05-08 08:12:27 Local7.Debug 10.14.114.10 648048: 2018-05-08 08:12:27 Local7.Debug 10.14.114.10 648049: timestamp=744419342 fr-msg-tx DIS 2018-05-08 08:12:31 Local7.Debug 10.14.114.10 648050: 2018-05-08 08:12:31 Local7.Debug 10.14.114.10 648051: timestamp=744423032 FR_BAD_CRC_LS_DATA 0x0 bytes 2018-05-08 08:12:31 Local7.Debug 10.14.114.10 648052: timestamp=744423032 fr-msg-tx bad crc, 0 bytes 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648053: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648054: timestamp=744425652 fr-msg-tx DIS 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648055: May 8 08:11:58 CDT: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x25F3 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648056: Cause i = 0x8290 - Normal call clearing 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648057: May 8 08:11:58 CDT: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0xA5F3 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648058: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/cc_api_call_disconnected: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648059: Cause Value=16, Interface=0xC24D1C64, Call Id=28395 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648060: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/cc_api_call_disconnected: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648061: Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0) 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648062: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/ccConferenceDestroy: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648063: Conference Id=0x25E5, Tag=0x0 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648064: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/ccConferenceDestroy: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648065: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648066: May 8 08:11:58 CDT: confID:0x25E5; callEntry1 callID1:0x6EEB, type:6; callEntry2 callID2:0x6EEC, type:1 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648067: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/cc_api_bridge_drop_done: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648068: Conference Id=0x25E5, Source Interface=0xC24D1C64, Source Call Id=28395, 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648069: Destination Call Id=28396, Disposition=0x0, Tag=0x0 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648070: May 8 08:11:58 CDT: //28396/F4F7E776A575/CCAPI/cc_api_bridge_drop_done: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648071: Conference Id=0x25E5, Source Interface=0x225ECF4C, Source Call Id=28396, 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648072: Destination Call Id=28395, Disposition=0x0, Tag=0x0 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648073: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/cc_generic_bridge_done: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648074: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648075: Conference Id=0x25E5, Source Interface=0x225ECF4C, Source Call Id=28396, 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648076: Destination Call Id=28395, Disposition=0x0, Tag=0x0 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648077: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/ccCallDisconnect: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648078: Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16) 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648079: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/ccCallDisconnect: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648080: Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16) 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648081: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/cc_api_get_transfer_info: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648082: Transfer Number=NULL 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648083: May 8 08:11:58 CDT: //28396/F4F7E776A575/CCAPI/ccCallDisconnect: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648084: Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0) 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648085: May 8 08:11:58 CDT: //28396/F4F7E776A575/CCAPI/ccCallDisconnect: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648086: Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16) 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648087: May 8 08:11:58 CDT: //28396/F4F7E776A575/CCAPI/cc_api_get_transfer_info: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648088: Transfer Number=NULL 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648089: May 8 08:11:58 CDT: //28396/F4F7E776A575/CCAPI/cc_api_get_transfer_info: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648090: Transfer Number=NULL 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648091: May 8 08:11:58 CDT: //28396/F4F7E776A575/CCAPI/cc_api_call_disconnect_done: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648092: Disposition=0, Interface=0x225ECF4C, Tag=0x0, Call Id=28396, 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648093: Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0) 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648094: May 8 08:11:58 CDT: //28396/F4F7E776A575/CCAPI/cc_api_call_disconnect_done: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648095: Call Disconnect Event Sent 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648096: May 8 08:11:58 CDT: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648097: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648098: May 8 08:11:58 CDT: :cc_free_feature_vsa freeing 42B2E3B0 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648099: May 8 08:11:58 CDT: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648100: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648101: May 8 08:11:58 CDT: vsacount in free is 11 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648102: May 8 08:11:58 CDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x25F3 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648103: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/cc_api_call_disconnect_done: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648104: Disposition=0, Interface=0xC24D1C64, Tag=0x0, Call Id=28395, 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648105: Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0) 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648106: May 8 08:11:58 CDT: //28395/F4F7E776A575/CCAPI/cc_api_call_disconnect_done: 2018-05-08 08:12:33 Local7.Debug 10.14.114.10 648107: Call Disconnect Event Sent 2018-05-08 08:12:34 Local7.Debug 10.14.114.10 648108: May 8 08:11:58 CDT: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa: 2018-05-08 08:12:34 Local7.Debug 10.14.114.10 648109: 2018-05-08 08:12:34 Local7.Debug 10.14.114.10 648110: May 8 08:11:58 CDT: :cc_free_feature_vsa freeing 42B2DF50 2018-05-08 08:12:34 Local7.Debug 10.14.114.10 648111: May 8 08:11:58 CDT: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa: 2018-05-08 08:12:34 Local7.Debug 10.14.114.10 648112: 2018-05-08 08:12:34 Local7.Debug 10.14.114.10 648113: May 8 08:11:58 CDT: vsacount in free is 10
... View more
Labels:
Created by
kylebrogers
in IP Telephony and Phones
08-07-2019
08-07-2019
Setup:2-server clusterCUCM 12.0.1.10000-10Database replication is
cleanPhones being converted are ph...
06-18-2019
Thank you for the reply. It's still on the SIP firmware, as it still
displays SIP in the top right c...
06-18-2019
I am attempting to convert a bunch of old 7940s and 7960s from SCCP to
SIP because the recording sof...
05-15-2019
Thanks. I had already gone through that doc, but apparently I just
missed the line:"The motherboard ...
05-15-2019
I'm ordering a 4K with a NIM-2MFT-T1/E1 and a PVDM4-64 slotted into the
card. If I'm only going to u...
Created by
kylebrogers
in Network Security
01-30-2019
01-30-2019
Thank you. I still don't understand why the reboot was occurring at the
start of the file transfer, ...
Created by
kylebrogers
in Network Security
01-29-2019
01-29-2019
I think thought that might be the case but couldn’t find any
documentation on upgrading ASA on a 213...
Created by
kylebrogers
in Network Security
01-29-2019
01-29-2019
I have a new 2130 with ASA code (not running FTD). I have configured it
and everything looks good. I...
01-08-2019
Thanks for the pointer to TranslatorX. I was able to dig through the SDL
files and find that it was ...
01-08-2019
Have you tossed your SDL and call log into TranslatorX to help parse the
trace? You can use the chec...
01-08-2019
In the trace file, do you see CUCM attempting to send H323 signaling
packets to the router? Can you ...
Created by
kylebrogers
in Network Security
12-13-2018
12-13-2018
If I create a new file or IPS policy and need to apply it to hundreds of
Access Control Rules, is th...
06-28-2018
So that would be an issue on the PRI side of the gateway (either the
telco provider, the sender's te...
Public Statistics
| Date Registered | 05-06-2010 01:22 PM |
| Date Last Visited | 08-09-2019 11:43 AM |
| Total Messages Posted | 391 |
| Total Helpful Votes Received | 37 |
Helpful Votes Given To
| User | Helpful Count |
|---|---|
| 10 | |
| 5 | |
| 10 | |
| 5 | |
| 5 |
.jpg "Hall of Fame Cisco Employee"){kind=icon}
Helpful Votes From
