<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML dir=ltr><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText45007 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Hi Kris</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>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?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>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)&nbsp;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.</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Kris Seraphine 
[mailto:baryonyx5@gmail.com]<BR><B>Sent:</B> Wed 2006-10-18 03:08<BR><B>To:</B> 
Erik Erasmus (E)<BR><B>Cc:</B> cisco-voip@puck.nether.net<BR><B>Subject:</B> Re: 
[cisco-voip] attendant console in remote SRST branch<BR></FONT><BR></DIV>
<DIV>Hi<BR><BR>I support a centralized cluster with 40+ remote sites; all of 
which use the attendant console.&nbsp; Most of the sites are under 50 phones but 
a few are over 100.&nbsp; 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.&nbsp; 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.&nbsp; This 
customer currently doesn't prioritize the AC flows but that's in the 
works.&nbsp; <BR><BR>As for WAN outages, you're pretty much out of 
luck.&nbsp;&nbsp; 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. <BR><BR>The MPLS WAN has 
been very reliable with maybe 6-7 outages during work hours over the last 12 
months between all the sites.&nbsp; Only one outage was extended and that was 
the local telco's fault.&nbsp; <BR><BR>
<DIV><SPAN class=gmail_quote>On 10/17/06, <B class=gmail_sendername>Erik Erasmus 
(E)</B> &lt;<A href="mailto:ErasmuE4@telkom.co.za">ErasmuE4@telkom.co.za</A>&gt; 
wrote:</SPAN> 
<BLOCKQUOTE class=gmail_quote 
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
  <DIV>
  <DIV><FONT face=Arial color=#000000 size=2>Hi</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>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.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>1. Has anyone deployed this with success - how 
  heavy is&nbsp;attendant console&nbsp;on bandwidth (assume we can configure 
  propper QoS) - say 100 users in the branch</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>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.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>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.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Any advise will be appreciated.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>erik erasmus</FONT></DIV>
  <DIV><FONT face=Arial size=2>Telkom SA Ltd</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></DIV>
  <TABLE>
    
    <TR>
      <TD bgColor=#ffffff><FONT 
        color=#000000>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>This 
        e-mail and its contents are subject to the Telkom SA Limited<BR>e-mail 
        legal notice available at <BR><A 
        href="http://www.telkom.co.za/TelkomEMailLegalNotice.PDF" 
        target=_blank>http://www.telkom.co.za/TelkomEMailLegalNotice.PDF</A><BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR></FONT></TD></TR></TABLE><BR>_______________________________________________<BR>cisco-voip 
  mailing list<BR><A 
  href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A 
  href="https://puck.nether.net/mailman/listinfo/cisco-voip" 
  target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR></BLOCKQUOTE></DIV><BR><BR 
clear=all><BR>-- <BR>kris seraphine </DIV></BODY></HTML>

<table><tr><td bgcolor=#ffffff><font color=#000000>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
This e-mail and its contents are subject to the Telkom SA Limited<br>
e-mail legal notice available at <br>
http://www.telkom.co.za/TelkomEMailLegalNotice.PDF<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</font></td></tr></table>