08-24-2009 08:00 PM - last edited on 03-25-2019 10:40 PM by ciscomoderator
Hi Cisco Team,
I think i may havr discovered a bug today which will put a damper on our client, i will do my best to lay it out below.
Devices:
Soft Phone Client:
Affected Services:
Enviroment:
The Problem:
Notes: It should be noted that all users are on CIPC except 2 phones which are hard phones, these two phones are not affected by this problem only the CIPC is. Testing was carried out on two devices, UC-500 and 2800 series, both had the same problem with the CIPC not clearing the call.
Once in the conference as well, no CIPC including the Admin one can perform any functions such as remove someone or see who is in the session, all phones lock up the features but the buttons are not greyed out so you can press them.
The ephone-template is setup word for word as per the Cisco Guide, so this was ruled out early on in the picture, various other codecs were also tried but all had the same problem.
The only thing that has not been tested is an older version of the CIPC.
If configs are required please advise, and they will be provided, if any specific questions need to be asked i will do my best to answer them, before i go to TAC on this i would like to see if there are any other avenues to approach.
Cheers,
David,
08-25-2009 04:44 AM
David is the softphone local to the UC500 system or is it via the VPN.... I only ask because I has seen this behavior (not with conference) where the softphone on a slow connection just can not hang up properly and just gets "locked" on slow connections. I just want to point it out that maybe you are running into this and that your conference is set up and working correctly...
08-25-2009 07:51 AM
I would go to TAC with this. I am not sure if this is is a problem with CIPC over the VPN, data congestion or something else. The only thing I could recommend, which has already been recommended, is to try this with a CIPC local to the system and see if you get the same behavior. That would let us know if this is something with the VPN and CIPC or just CIPC.
08-25-2009 02:43 PM
Hi There,
I thank you both for your responses.
I think this might beed to be taken to TAC, the issue with the CIPC is only with MeetMe, it does however have to operate over a VPN, but i need to make sure i point out that the CIPC works as per normal when using it for every day use, as soon as it is put into a MeetMe conference it locks up and will not tare the call down locally (The System has cleared the call, and there is no signs of the CIPC still talking to the system).
I need to point out that the Softphone has not been tested on a lab system using MeetMe, my primary focus right now is to make sure i can get it to work for these staff, which is only at 12 right now but scheduled to be around the 50 remote worker mark.
I also should point out the congestion is not an issue, the client has a pretty fat data pipe which is exlusive for voice, and has a seperate pipe for data, i also have a pretty good connection as well that is not subject to high latency either.
I also need to point out that Desk Phones that are working remotly via VPN do no suffer the same problem, it is only the CIPC client that does, so this to me indicates that the problem resides in the CIPC, no matter what it should respond to the command of End Call and clear the screen, there should be no reason what so ever for it to have to lockup and then not respond to a command, even the reset command on teh CLI (Note the phone is still registered to the system, it just wont repsond).
Cheers,
David.
08-26-2009 06:06 PM
Hi All,
Just an update to the above:
We found the potential bug, the issue arises when you press teh ConfLst button to view a list of all the people in the conference, this happens in both an Ad-Hoc or MeetMe enviroment, and only on a CIPC setup.
The solution was:
1. Remove that option from the CIPC and create a different ephone-template for the CIPC
2. Put that option in for the Desk Phones and point them to their respective template as well
This has stopped so far the locking up of the CIPC in all our testing, so it is a positive step forward.
Now to find the best way to log the bug with Cisco, i would rather not go through TAC at this stage as i really do not beleive this should take up resources just yet, it is not mission critical, but it might be helpfull if the engineers are aware of this problem and if someone else can do some lab testing on this.
Cheers,
David.
08-26-2009 11:46 PM
Hi Dave,
You definitely should log a TAC case for this. The TAC can log a bug and attach your case to it. Bug reports that have TAC cases attached have a higher priority within engineering than internally found problems because clearly they are impacting people.
Cheers,
Dave.
08-26-2009 11:52 PM
Hi Dave,
You definitely should log a TAC case for this.
I hear ya :)
I am trying too, but i am trying to work out a way of doing it without upsetting the client anymore then what they have been allready, so i am completing the work around for this problem, and then i will focus on trying to resolve the problem with TAC, it gets hard when your at the front line dealing witht he cold face of customer service, i sometimes have to check my head and make sure i really dont have horns on there ;)
I promise to log a TAC case for this as soon as the opening to do so presents itself.
Cheers,
David.
08-27-2009 12:48 AM
Understand. When you are already struggling to keep the twenty or thirty or more balls in the air that you are already juggling, adding one more can be just a bit too much. ;)
Take your time with this, but given you have characterised the problem so well, it would be good to get it nailed once and for all.
Cheers,
Dave.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide