Arc Console Problems at remote wan site

Unanswered Question
Jan 11th, 2007
User Badges:


We have a recently installed the CM 4.2 cluster in Sydney. At Melbourne we have a Cisco 3825 voice gateway SRST router registered with the Sydney CM. We have the Arc server located at Sydney. The receptions at both the sites have got the Arc client installed on their pc's. At the Sydney the reception is happy however at Melbourne : when an external call comes in on the Arc console screen the receptionist has to click on the call twice to attend to it and the when she transfers it takes more time then necessary in comparison to Sydney. It appears that some sort of signalling between the melbourne arc console and the arc server in sydney is delaying things. I have ruled out qos and networking for the moment since everything else is working fine and the call quality is good. We have put the arc signalling between Melbn and Sydney to g711 since arc does not support g729 as we have not enabled the transcoder. Has anybody encountered anything similar before and knows the fix?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
bwilmoth Wed, 01/17/2007 - 14:58
User Badges:
  • Silver, 250 points or more

The Cisco IP Phone in Cluster 1 makes a call to the Cisco IP Phone in Cluster 2. Intercluster Cisco CallManager communication takes place using the H.323 Version 2 protocol. A Cisco IOS Gatekeeper also serves for admission control.

The Cisco IP Phone can connect to the Cisco CallManager via Skinny Station protocol, and the Cisco CallManager can connect with the Cisco IOS Gatekeeper by using the H.323 Registration, Admission, and Status (RAS) protocol. The admission request message (ARQ) gets sent to the Cisco IOS Gatekeeper, which sends the admission confirmed message (ACF) after making sure the intercluster call can be made using H.323 version 2 protocol. Once this happens, the audio path gets made by using the RTP protocol between Cisco IP Phones in different clusters.


juamaya Tue, 10/02/2007 - 08:50
User Badges:

Seems you are experiencing delay when using the application.

Not sure how the Arc Console would work but I had a similar problem when used the CallManager Console.

I assume you have QoS enabled at the WAN side and the LAN is trusting CoS packets at the IP Phone port and trunk ports.

The Cisco Attendant console marks its packets. We had the console in a desktop behind the IP Phone or switch port that wasn't configured to trust the incoming DSCP/COS markings coming from the PC.

You may want to use ethereal to verify it. We found the traffic from the Console should be handled by the network just like any other IP Phone control traffic, regardless of the source.

You can use ACLs to mark the traffic at the WAN routers too.

I hope this drives you to the right direction.

VPMaharaj Tue, 10/02/2007 - 14:53
User Badges:

Thanks Juan.

QOS definitely is a prime suspect in such cases however it was setup correctly in the routing and switching domain and working ok except Packeteer.

It turned out to be a QOS config issue in the Packeteer in the end.

bennieg Wed, 10/17/2007 - 13:22
User Badges:

HI Guys

I'm pretty sure this issue is resolved now, but just want to check. Is this resolved now?

VPMaharaj Wed, 10/17/2007 - 14:53
User Badges:

Hi Bennie,

Resolved a while ago. It was not an Arc issue. Thanks for the support.


This Discussion