QoS Information for all Calls NA

sven.hohmann · ‎10-25-2005

In my CAR reports have all calls

the QoS Information "NA".

Where are the issue off this behavior?

How can i resolve this?

jeff.hillman · ‎10-25-2005

In order for the QoS field to be populated with a value other than NA, you must first define your QoS Values. I am putting the link to Cisco's documentation that explains how to do this:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00803f526c.html#wp1032132

Hope this helps.

Jeff

sven.hohmann · ‎10-25-2005

Hi Jeff,

thanks for this informations.

The QoS values in my car are already defined with the default values.

Anyhow the QoS information in the car for all calls

are "NA".

What is the next i can do to resolve this?

Sven

jeff.hillman · ‎10-25-2005

The other piece to this is making sure the Jitter and Latency values end up in the call records. In the Service Parameters for CallManager, you need to set Call Diagnostics Enabled to True. That adds a number of fields to the call records by adding CMR records:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide09186a00802375db.html

See if that does it for you.

Jeff

sven.hohmann · ‎10-25-2005

Hi Jeff,

i doent understand what i must do with the Jitter

and Latency values.Can you discribe this.

I have set the Call Diagnostics Enabled to True.

Now i can see the QoS information in the CAR.

Please look at the attachments.Is there all o.K.?

Sven

jeff.hillman · ‎10-26-2005

The best way to tune those values is to implement the Quality Reporting Tool on the phones of those users reporting problems with their calls (choppy voice, distortion, etc). This gives them a tool to mark when a call was bad and allows you to then see details on that call. With the CMR records turned on, your call detail will now show Jitter and Latency, and you can use that information to then tune the QoS definitions. Here is the link to the CCM 4.1 guide for turning on the QRT:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/4_1/sys_ad/4_1_3/ccmfeat/fsqrt.htm

You may find that your users, depending on your infrastructure, have lower or higher tolerances for the effects of Jitter and Latency than what are defined by default in the CDR tool.

Jeff

sven.hohmann · ‎10-27-2005

Hi Jeff,

i´ve testet the QRT tool. It works.

We have calls they are bad, the user can mark this and i can see it in the CDR.

During a call our user can hear sometimes a snap sound.(only in the IPCC area)

What can i do now?

Sven

jeff.hillman · ‎10-31-2005

I haven't run into a problem with a snap sound in IPCC. When I am checking call quality issues with IPCC/CRA, I verify the JTAPI version is up to date, check the layer 1 (physical) for the IPCC server, and make sure my service packs are up to date. If the software is co-located, verify the patches are up to date and the fixes for co-location are installed.

Also, in a co-located server, I always make sure to add extra memory to the CallManager/IPCC server, as the 1 GB (now 2 GB) that the servers ship with is never really enough, esp. if you are co-located on the publisher.

Sorry this isn't more help. Beyond the above, opening a TAC case would be my next recommendation. I'd be interested in hearing what the solution is when/if TAC can figure it out.

Good luck to you!

Jeff

sven.hohmann · ‎10-31-2005

Hi Jeff,

please tell me how can i check the layer 1 (physical) for the IPCC server?

Sven

jeff.hillman · ‎11-01-2005

When I say "Check layer 1", I am referring to verifying that you have a good physical connection from your switch to the server. The things to check for are:

1) Well-made patch cable that isn't kinked, etc. Replace the patch cable to the server with one that you know is good and has been tested.

2) Check the switch port that the IPCC server is plugged in to. Make sure that there aren't any errors on the interface (a "show interface" command will show you this). If there are errors on the interface, and replacing the patch cable doesn't fix them, you may need to replace the network card in the server.

3) Check the duplex and speed settings on the switch port. Make sure (if it is set to auto on the switch) that Full-Duplex 100 (or 1000) Mbit has been negotiated. If you see the port is half-duplex, you may have to set the speed and duplex settings manually on the switch port and server.

4) If this still doesn't clear up the interface errors, you may have a bad switch port. Try moving the server to another port. Also check that environmental factors (like the patch cable to the server running directly over an air-conditioning unit or florescent light fixture) aren't affecting the connection to the server.

Any combination of the above could create issues with the traffic to the IPCC server, though most of them would probably be more obvious than just a random "snap" sound.

Jeff

sven.hohmann · ‎11-01-2005

Hi Jeff,

thanks for the informations.

Over the users they mark the bad calls i found

in the cdr/cmr that this calls have an jitter off 60.

Please look to the attachments.

Can you say somthing about this?

Regards Sven

jeff.hillman · ‎11-02-2005

It looks like the jitter is specific to the call legs from the 2 2651 routers that are hosting E1 circuits. I would start your search for the problem at those routers. Take a look at the Quality of Service setup on those routers and make sure that your voice streams are getting the priority they need. Also make sure the Layer 2 and Layer 3 networks between those gateways and the IPCC server/IP Phones have QoS techniques setup for voice traffic as well.

Below is a link to a very good Cisco document that discussed Jitter in a voice network that should give you some commands to use to test with. There is also a reference on the page to another document that addresses Delay as well.

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800945df.shtml

Hope that helps!

Jeff

sven.hohmann · ‎11-07-2005

Hi Jeff,

the issue with the snap sound in our IPCC

came from the carier off our free call number.

They resolved this problem.

However we have many calls with a jitter off 60,

but no problems with the audio stream.

We will look forward what cisco says to this.

Maybe it is normal to get an jitter in the gateways?

Thanks for your help und best regards

Sven