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 Jon Clark1
Stats
Member since
09-01-2009
112
Posts
20
Helpful
2
Solutions
11-11-2019
04:15 PM
Deepak, I gave Cisco Licensing old/new mac's like you said and they sent me a new lic file. I uploaded and the warning still remained. They told me to reboot then upload again which I did just now and still the warning remains. Both Master/Slave in Full Service and everything works but the error message remains. I emailed Cisco Licensing the results and will try to post here the solution. -JC
... View more
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
10-24-2019
04:42 AM
10-24-2019
04:42 AM
Hello from October 2019. I'm having similar issue and wanted to append to this thread. I'm using 11.5.1 and the UCM backup fails if I include CDR in the backup. Using Solarwinds btw. Backup runs fine without CDR involved. Here's interesting output from the logs... Free space available: 7757620 kb Creating Ontape Backup of DB... command to execute /bin/su - informix -c "source /usr/local/cm/db/informix/local/car_ids.env; ontape -s -L 0 | /bin/gzip > /common/drf/db_drf_backup/drf_ontape_backup.gz" 2>>/common/drf/backup.log drf_ontape_backup created is of size [96213392] ESTCARDBBINSIZE = 93958 kb Calculating size of preserve folder... preserve foldersize is 132 kb Calculating size of destination1 folder... destination1 foldersize is 132 kb Calculating size of destination2 folder... destination2 foldersize is 132 kb Calculating size of destination3 folder... destination3 foldersize is 132 kb Calculating size of car folder... car foldersize is 132 kb Calculating size of carreports folder... carreports foldersize is 96 kb REQUIRED size : 94714 Kb Ontape Backup completed! Creating Tar ball /common/drf/db_drf_backup/drf_ontape_backup.gz Tar ball creation failed, unable to tar data to master agent Restarting Master/Local did nothing. Any advice?
... View more
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
10-23-2019
02:32 PM
10-23-2019
02:32 PM
Roger or anyone, Did anyone find a resolution? I'm having backups fail when the CDR/CAR is part of the backup. Backups run fine when I remove CDR/CAR from the backup. I'm using solarwinds. Below is the free space: Total Free Used Disk/active 14643056K 1518208K 12976084K (90%) Disk/inactive 14643120K 1826128K 12668228K (88%) Disk/logging 50179664K 8326272K 39263216K (83%) where do I start?
... View more
Created by
Jon Clark1
in Other Collaboration Subjects
in Other Collaboration Subjects
10-23-2019
12:12 PM
10-23-2019
12:12 PM
Not that the community was any help whatsoever (0 responses) but the problem ended up being codec mismatch. The resolution was to increase the originating region to use G711 to match the E2E region of the cube. The originating region did not have any codecs defined for the #E2E region thus defaulting to the System Default which was 8kbps. The outgoing dial peer did not have any voice class codec settings defined thus using G711 in the 183. For whatever reason CUCM gave a 200OK to using G711 but then sent a re-invite and only offered G729. (Subsequently this is after the Connect and Connect ACK took place between the CUBE and Provider. So in short, CUCM first agrees on G711, then tries to change it's mind to G729. This was too late as G711 was already negotiated thus generating the cause code 86 and cause code 111 (protocol error). Lesson learned. Codec mismatch can cause a cause code 86 and cause code 111. Nothing to do with IE's or anything on the provider side. If the CUBE does all the disconnecting (BYE to CUCM and DISCONNECT to Provider) then most likely check your region settings. I caught the goofy response of having G729 2nd in the pecking order but I never acted on it. Shame on me. I was close though! If you have any questions ask away! JC
... View more
10-22-2019
05:56 AM
**ERROR**: Ux_Status: STATUS call state mismatch with invalid cause: cause 0x61, state 0xB, peer state 0xA One engineer believes its a codec mismatch. Another engineer believes it's a Telco issue... 065076: Oct 17 15:14:04.973: %ISDN-6-DISCONNECT: Interface Serial0/1/0:22 disconnected from 5075258935 , call lasted 1 seconds 065077: Oct 17 15:14:04.974: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0146 Cause i = 0x80EF - Protocol error; unspecified 065078: Oct 17 15:14:05.019: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8 callref = 0x8146 Cause i = 0x82E16E - Message type not implemented Call State i = 0x0A 065079: Oct 17 15:14:05.019: ISDN Se0/1/0:23 **ERROR**: Ux_Status: STATUS call state mismatch with invalid cause: cause 0x61, state 0xB, peer state 0xA 065080: Oct 17 15:14:05.020: ISDN Se0/1/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x0146 Cause i = 0xC0E5 - Message not compatible with call state 065081: Oct 17 15:14:05.028: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x8146 Cause i = 0x82E408 - Invalid information element contents 065082: Oct 17 15:14:05.031: //300767/A6B0B9800000/CCAPI/cc_api_call_disconnect_done: Disposition=0, Interface=0x7FC4A44F36A0, Tag=0x0, Call Id=300767, Call Entry(Disconnect Cause=111, Voice Class Cause Code=0, Retry Count=0) 065083: Oct 17 15:14:05.031: //300767/A6B0B9800000/CCAPI/cc_api_call_disconnect_done: Anyone?
... View more
Created by
Jon Clark1
in Other Collaboration Subjects
in Other Collaboration Subjects
10-18-2019
12:41 PM
10-18-2019
12:41 PM
One interesting thing I see is just before the BYE message from VGW2 to CUCM. CUCM responds with the ACK below to VGW2. Notice the audio line is out of order Does this cause VGW2 to immediately send the BYE? c=IN IP4 (IP Address of VGW1) b=TIAS:8000 b=AS:8 t=0 0 m=audio 25934 RTP/AVP 101 18 100 (Notice the codec(g729) is 2nd. Typically the codec goes first.) a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 Right after this VGW2 sends an immediate BYE Call Trace from CUCM Below (Top portion of BYE Message omitted) User-Agent: Cisco-SIPGateway/IOS-16.6.5 Max-Forwards: 70 Timestamp: 1571343244 CSeq: 101 BYE Reason: Q.850;cause=86 (snippet from the VGW debugs) Below... the ACT from CUCM... notice the immediate call disconnected(Cause 111) after =audio 25934 RTP/AVP 101 18 100 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:100 X-NSE/8000 065031: Oct 17 15:14:04.913: //300765/A6B0B9800000/CCAPI/cc_api_call_disconnected: Cause Value=111, Interface=0x7FC49AE87EF0, Call Id=300765 065032: Oct 17 15:14:04.913: //300765/A6B0B9800000/CCAPI/cc_api_call_disconnected: Call Entry(Responsed=TRUE, Cause Value=111, Retry Count=0) 065033: Oct 17 15:14:04.913: //300767/A6B0B9800000/CCAPI/ccGenerateToneInfo: Stop Tone On Digit=FALSE, Tone=Null, Tone Direction=Sum Network, Params=0x0, Call Id=300767 065034: Oct 17 15:14:04.913: //300765/A6B0B9800000/CCAPI/ccConferenceDestroy: Conference Id=0x2193, Tag=0x0 065035: Oct 17 15:14:04.914: //300765/A6B0B9800000/CCAPI/ccConferenceDestroy:
... View more
10-18-2019
12:07 PM
Cause i = 0x82E16E - Message type not implemented Call State i = 0x0A 065015: Oct 17 15:14:04.893: ISDN Se0/1/0:23 Q931: TX -> NOTIFY pd = 8 callref = 0x0146 Notification Ind i = 0x8300 Display i = 'MY FIRST AND LAST NAME' Calling Party Number i = 0x0081, '+19999999999' Plan:Unknown, Type:Unknown ask for any info and I will provide it as best I can.
... View more
Labels:
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
10-18-2019
09:23 AM
10-18-2019
09:23 AM
Call Flow: (used my cell)PSTN caller->VGW1->CUCM->UCCX->Agent xfers to internal operator-> Internal Operator blind xfers to end user-> end user has cfwd all set to his cell phone-> SIP Trunk ->Cube/VGW2 ->H.323 PRI -> PSTN Facts Call connects for 1 second then drops If I call the end user directly the call connects fine(Call comes in and exits on VGW2 not VGW1) I collected debugs on VGW2 (can't share entire debugs - customer info) VGW2 disconnects the call (Sends BYE to CUCM and Disconnect MSG to Provider) BELOW: BYE MESSAGE FROM VGW2 TO CUCM User-Agent: Cisco-SIPGateway/IOS-16.6.5 Max-Forwards: 70 Timestamp: 1571343244 CSeq: 101 BYE Reason: Q.850;cause=86 BELOW: DISCONNECT MSG TO PRI PROVIDER 065077: Oct 17 15:14:04.974: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0146 Cause i = 0x80EF - Protocol error; unspecified (See screenshots of Translator X diagram (debugs from VGW2) attached) In comparing calls I see a reinvite coming from CUCM (INVITE 105) that swaps out the Operator's PAsserted ID and Contact with my cell info. When that gets passed to the provider it shows plan: uknown/unknown. Not sure if this is the cause. Could it be a callerID issue where callerID is provided but in an unsupported IE by the provider? A call status did get generated with a call state and no mechanism for recovery thus a drop? See below from provider after disconnect. 065078: Oct 17 15:14:05.019: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8 callref = 0x8146 Cause i = 0x82E16E - Message type not implemented Call State i = 0x0A ask for any info and I will provide it as best I can. JC
... View more
- Tags:
- ause i = 0x82E16E
- Cause i = 0x80EF - Protocol error
- cause=86
- isdn
- Reason: Q.850
- status
- unsupported IE
Labels:
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
10-12-2019
05:05 AM
10-12-2019
05:05 AM
Great trick Anthony. Below is a test where I'm guessing I used the correct cluster security password? "BAD PASSWORD: it does not contain enough DIFFERENT characters" was the result. See below. admin:set password user security Please enter the old password: ****** Please enter the new password: ****** Reenter new password to confirm: ****** WARNING: The Disaster Recovery System is dependent on this security password you are attempting to change. If you need to use any of the older backup archive to restore this system, you need to remember the older security password. To avoid this scenario, we recommend you to conduct a DRS Backup of your system/cluster immediately after this password change. Please make sure that the security password on the publisher is changed first. The security password needs to be the same on all cluster nodes, or the publisher and subscriber(s) will not communicate. After changing the security password on a cluster node, please restart that node. Continue (y/n)?Y Please wait... BAD PASSWORD: it does not contain enough DIFFERENT characters admin:
... View more
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
10-11-2019
07:52 AM
10-11-2019
07:52 AM
Thank you for this reply. Though I posted the solution I am going to use your trick! Thank you again for replying. Very grateful ! -JC
... View more
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
10-11-2019
07:49 AM
10-11-2019
07:49 AM
Turns out the customer's firewall was blocking 2 ports that disrupted cluster communication between some of the servers thus having RTMT show "Node not reachable" when it actually was via ping. Traffic on ports 8500 (Intracluster replication of system data by IPSec Cluster Manager) and 2555 (Real-time Information Services (RIS) database server) between CUCM01 and the other nodes to the new CUCM node being installed was being denied by a Firewall rule. The 2555 makes sense as it’s real time information that wasn’t being updated. So lesson learned. If you run into replication issues or show network cluster showing "unauthenticated" try checking if ports 8500 and/or ports 2555 are blocked. If they are open then try Anthony's set password user security trick to test the cluster security password on the new node.
... View more
09-19-2019
09:02 AM
Hello Deji, Deji can you answer what setting for an ip phone (CSF in this case) on prem forces a=reconly in the initial SDP to cucm for an outgoing call? All the other m lines (including other video m lines) all have a=sendrec but not this one m line. It's causing the other side to respond with all a=inactive's which gives no audio. Thanks! m=video 29804 RTP/AVP 126 97 111 c=IN IP4 10.41.72.98 b=TIAS:4000000 a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42E01F;packetization-mode=1;level-asymmetry-allowed=1;max-mbps=244800;max-fs=8161;max-rcmd-nalu-size=32000 a=imageattr:126 recv [x=[32:1:1920],y=[18:1:1080],par=1.7778,q=1.00] a=content:main a=label:11 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42E01F;packetization-mode=0;level-asymmetry-allowed=1;max-mbps=244800;max-fs=8161 a=imageattr:97 recv [x=[32:1:1920],y=[18:1:1080],par=1.7778,q=1.00] a=rtpmap:111 x-ulpfecuc/8000 a=extmap:14/sendrecv http://protocols.cisco.com/timestamp#100us a=fmtp:111 max_esel=1420;m=8;max_n=32;FEC_ORDER=FEC_SRTP a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=rtcp-fb:* nack pli a=recvonly
... View more
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
09-18-2019
01:08 PM
09-18-2019
01:08 PM
More info after looking at ICT in US... Best Effort... No MTP inserted MRGL is empty on the ICT
... View more
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
09-18-2019
12:55 PM
09-18-2019
12:55 PM
Jamie deeper info... US IP Phone->Specific Route Pattern->RL(Run on all CM Nodes not checked)-> CUCM1->ICT CUCM2(Media Termination Point not checked nor is Run on all Active CM Nodes)->DMVPN 210ms between CUCM's->ICT CHINA CUCM2(not sure what is checked. No access)->China IP Phone No audio but normal call clearing.
... View more
Created by
Jon Clark1
in IP Telephony and Phones
in IP Telephony and Phones
09-18-2019
12:22 PM
09-18-2019
12:22 PM
Jaime can you help me on the same issue? 8845 IP Phone->CUCM2 of 3 in US -> ICT over DMVPN ->China->CUCM2->IP Phone No audio but call connects fine. Note* Media Termination point required is not checked on the ICT. Run on all active nodes is not checked on the RL or the SIP Trunk. Ping Times are 210ms. I do not have access to CUCM in China. Only US. CDR from China shows two IP Addresses for destination. 1. Destination IP Address (CUCM 2 US). 2. Media Destination IP Address of US IP Phone. Helppp
... View more
11-11-2019
Deepak,I gave Cisco Licensing old/new mac's like you said and they sent
me a new lic file. I uploade...
10-24-2019
Hello from October 2019. I'm having similar issue and wanted to append
to this thread. I'm using 11....
10-23-2019
Roger or anyone,Did anyone find a resolution? I'm having backups fail
when the CDR/CAR is part of th...
10-23-2019
Not that the community was any help whatsoever (0 responses) but the
problem ended up being codec mi...
10-22-2019
**ERROR**: Ux_Status: STATUS call state mismatch with invalid cause:
cause 0x61, state 0xB, peer sta...
10-18-2019
One interesting thing I see is just before the BYE message from VGW2 to
CUCM. CUCM responds with the...
10-18-2019
Cause i = 0x82E16E - Message type not implementedCall State i = 0x0A
065015: Oct 17 15:14:04.893: IS...
10-18-2019
Call Flow: (used my cell)PSTN caller->VGW1->CUCM->UCCX->Agent xfers to
internal operator-> Internal ...
Created by
Jon Clark1
in IP Telephony and Phones
10-12-2019
10-12-2019
Great trick Anthony. Below is a test where I'm guessing I used the
correct cluster security password...
Created by
Jon Clark1
in IP Telephony and Phones
10-11-2019
10-11-2019
Thank you for this reply. Though I posted the solution I am going to use
your trick!Thank you again ...
Created by
Jon Clark1
in IP Telephony and Phones
10-11-2019
10-11-2019
Turns out the customer's firewall was blocking 2 ports that disrupted
cluster communication between ...
09-19-2019
Hello Deji,Deji can you answer what setting for an ip phone (CSF in this
case) on prem forces a=reco...
09-18-2019
More info after looking at ICT in US...Best Effort... No MTP
insertedMRGL is empty on the ICT
09-18-2019
Jamie deeper info...US IP Phone->Specific Route Pattern->RL(Run on all
CM Nodes not checked)-> CUCM1...
Public Statistics
| Date Registered | 09-01-2009 07:12 PM |
| Date Last Visited | 11-13-2019 12:39 AM |
| Total Messages Posted | 112 |
| Total Helpful Votes Received | 20 |
Helpful Votes Given To
| User | Helpful Count |
|---|---|
| 5 | |
| 10 | |
| 5 | |
| 22 | |
| 5 |
.jpg "VIP Advisor"){kind=icon}
.jpg "Hall of Fame Cisco Employee"){kind=icon}
Helpful Votes From
