[cisco-voip] attendant console in remote SRST branch

Tue Oct 17 21:40:20 EDT 2006

Hi Kris

just to make sure - when you have a wan outage currently - do you have
no coverage for the main number at the remote site or not?

My concern is that because the attendant uses a pilot number and ac
users to cover for the main number that wehn the wan is down the pilot
number is gone and inbound calls will just not route into the site
because unless I can do something under srst to create the DN of the
main number - it will not exist really. Or am I missing something.
Where I did attendant console before at an HQ - I used as an example a
pilot of say 1000 for the main number of 431 1000 etc with ac1 user on
extension 5001 and ac2 user on 5002 as an example and then in the
huntgroup use ac1 and ac2 as members but 1000 does not appear on their
phones.

If one uses the same concept at a remote branch things will work like
you say when wan is up but when wan is down that pilot does not exist
and one also don't have that DN (the main pilot) on any phone so when
srst configures it does not know about the main number for that site
leaving us with a problem. I can live with not have the line states
etc etc while the wan is down - just need to somehow make the main
number reachable even if it is just on a single IP phone.

________________________________

From: Kris Seraphine [mailto:baryonyx5 at gmail.com]
Sent: Wed 2006-10-18 03:08
To: Erik Erasmus (E)
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] attendant console in remote SRST branch

Hi

I support a centralized cluster with 40+ remote sites; all of which
use the attendant console.  Most of the sites are under 50 phones but
a few are over 100.  The AC works pretty well over the WAN. The only
problem that we occasionaly have that I attribute to the WAN is that
the parked calls sometimes don't disappear when a call is picked up.
The only reason I attribute this to a latency issue is that I don't
see this issue with any of my other customers who use the AC on the
same LAN as the servers.  This customer currently doesn't prioritize
the AC flows but that's in the works.  

As for WAN outages, you're pretty much out of luck.   There's no way
to preserve the AC functionality when the connection to the server is
down. You can route calls to dns using alias commands but line state,
drag and drop will be gone. 

The MPLS WAN has been very reliable with maybe 6-7 outages during work
hours over the last 12 months between all the sites.  Only one outage
was extended and that was the local telco's fault.  

On 10/17/06, Erik Erasmus (E) <ErasmuE4 at telkom.co.za> wrote: 

	Hi

	I have a scenario now where a customer wants to run an HQ and
5 remote branches with a centralised call manager cluster and the
branches on srst across an MPLS IP wan. The problem is I have never
proven the viability of running the attendant console that comes with
ccm 4-1/4-2 across a wan link. Looking for practical advise on
workable solutions.

	1. Has anyone deployed this with success - how heavy is
attendant console on bandwidth (assume we can configure propper QoS) -
say 100 users in the branch

	2. My biggest concern is what happens when the branch goes
into srst mode. How does one then cover for the pilot number for the
specific site. Normally when doing it at an HQ I use the approach
where I create the ac1, ac2 users etc for attendants and the pilot dn
is the main number like xxx 1000 etc. if one now configure ac users
for the remote site/s each with their own pilot number things should
work Ok with the WAN up but not sure how to provide cover for the main
number when srst kicks in and the entire attendant solution goes down.
The branch can not afford having the main pilot number un attended
during a wan failure.

	Not using attendant console also poses a problem for a big
branch with 100 plus users with high inbound call volumes to the site.
Simply putting a 7960 down with an expansion module or two will not do
it. The attendants won't be able to effectively handle high call
volumes, no drag and drop, now line state info etc.

	Any advise will be appreciated.

	erik erasmus
	Telkom SA Ltd

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This e-mail and its contents are subject to the Telkom SA Limited
e-mail legal notice available at 
http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	_______________________________________________
	cisco-voip mailing list
	cisco-voip at puck.nether.net
	https://puck.nether.net/mailman/listinfo/cisco-voip

-- 
kris seraphine 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This e-mail and its contents are subject to the Telkom SA Limited
e-mail legal notice available at 
http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20061018/34e2f952/attachment-0001.html 