Possible Bug with CIPC and MeetMe

David Trad · ‎08-24-2009

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:

UC-520
2800 series (Tested on this one as well)

Soft Phone Client:

Cisco CIPC version 7.0.2.0

Affected Services:

MeetMe Conferencing (Adhoc is not affected by this)

Enviroment:

Call Center, all staff using the CIPC on their system
VPN client used from Remote site to Cisco system
Each CIPC is restricted to G.729r8 Codec (Bandwidth Reduction measures)

The Problem:

Conference Admin User can initiate the conference, but is unable to hang up or exit the conference on the CIPC, however the system does tare the conference down, just that the CIPC locks up and thinks it is still within the conference, no buttons respond, speaker phone can be pressed and the light goes out, but the phone keeps on ticking over as if it was still in the Conference.
Occassionaly it can be exited, however that has to be done immediatly, if another participant joins and any options are chosen such as ConfLst then the phone will not leave the conference (Again only on the phone itself, the system has cleared it).
MeetMe is setup as Participants can continue even after Admin has left, Conf clears down once all participants leave, but the soft phones continue to hang

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,

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

JOHN NIKOLATOS · ‎08-25-2009

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...

Steven Smith · ‎08-25-2009

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.

David Trad · ‎08-25-2009

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.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

David Trad · ‎08-26-2009

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.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

David Harper · ‎08-26-2009

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.

David Trad · ‎08-26-2009

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.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

David Harper · ‎08-27-2009

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.