<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8"><BASE href=x-msg://30/>
<META content="MSHTML 6.00.2900.3627" name=GENERATOR></HEAD>
<BODY style="WORD-WRAP: break-word; webkit-nbsp-mode: space; webkit-line-break: after-white-space">
<DIV>We are testing a centralized SIP trunk design with CUBE and so far it seems to work well for basic inbound and outbound calling. We have over 1000 locations that range in size from 4 analog lines to multiple PRIs.Couple of questions about your SIP deployments:</DIV>
<DIV> </DIV>
<DIV>Are you using SIP Trunk to support Fax? There does not seems to be a good way to ensure G711 is used for both inbound and outbound fax calls.</DIV>
<DIV> </DIV>
<DIV>How are you handling 911 calls? With a centralized design I think CER would be required.since users have been known to pickup their phones and relocate without letting anyone know.</DIV>
<DIV> </DIV>
<DIV>Of course both 911 and FAX could be served using separate analog lines or a PRI but that kind of defeats the purpose.</DIV>
<DIV> </DIV>
<DIV>Steve</DIV>
<DIV><BR><BR>>>> Mark Holloway <mh@markholloway.com> 11/23/2009 7:20 PM >>><BR>SIP Trunking works great when designed and deployed correctly. </DIV>
<DIV>
<DIV><BR>
<DIV>
<DIV>On Nov 23, 2009, at 12:39 PM, Lelio Fulgenzi wrote:</DIV><BR class=Apple-interchange-newline>
<BLOCKQUOTE type="cite"><SPAN class=Apple-style-span style="WORD-SPACING: 0px; FONT: medium Helvetica; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0px">
<DIV>
<DIV style="FONT-SIZE: 10pt; COLOR: rgb(0,0,0); FONT-FAMILY: Verdana">Every day, I think to myself, man, SIP isn't all it's cracked up to be......<BR><BR>OK, not _every_ day, but when I read posts like this I do.<BR><BR>Seems like there will be some "re-edumacating" necessary when moving to SIP.<BR><BR><BR>---<BR>Lelio Fulgenzi, B.A.<BR>Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<BR>(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<BR>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<BR>"Bad grammar makes me [sic]" - Tshirt<BR><BR><BR>----- Original Message -----<BR>From: "Chris Ward (chrward)" <<A style="COLOR: blue; TEXT-DECORATION: underline" href="mailto:chrward@cisco.com">chrward@cisco.com</A>><BR>To: "Ted Nugent" <<A style="COLOR: blue; TEXT-DECORATION: underline" href="mailto:tednugent73@gmail.com">tednugent73@gmail.com</A>>, "Cisco VoIPoE List" <<A style="COLOR: blue; TEXT-DECORATION: underline" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Sent: Monday, November 23, 2009 2:21:05 PM GMT -05:00 US/Canada Eastern<BR>Subject: Re: [cisco-voip] SIP Trunk Redundancy<BR><BR>
<DIV class=Section1>
<DIV style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"><SPAN style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125); FONT-FAMILY: Calibri, sans-serif">You would need to look at the traces to verify, but it may just be the time it takes to failover. You probably need to mess with the SIP profiles and timers to get the trunks to failover in a timely manner. I think by default it may take 15+ seconds (depends on # of retires and time between retries) for a SIP trunk call to failover to the next member of a route group.</SPAN></DIV>
<P class=MsoNormal style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"><SPAN style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125); FONT-FAMILY: Calibri, sans-serif"></SPAN> </P>
<DIV style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"><SPAN style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125); FONT-FAMILY: Calibri, sans-serif">-Chris</SPAN></DIV>
<P class=MsoNormal style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"><SPAN style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125); FONT-FAMILY: Calibri, sans-serif"></SPAN> </P>
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<DIV style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma, sans-serif">From:</SPAN></B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma, sans-serif"><SPAN class=Apple-converted-space> </SPAN><A style="COLOR: blue; TEXT-DECORATION: underline" href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><SPAN class=Apple-converted-space> </SPAN>[mailto:cisco-voip-bounces@puck.nether.net]<SPAN class=Apple-converted-space> </SPAN><B>On Behalf Of<SPAN class=Apple-converted-space> </SPAN></B>Ted Nugent<BR><B>Sent:</B><SPAN class=Apple-converted-space> </SPAN>Monday, November 23, 2009 2:14 PM<BR><B>To:</B><SPAN class=Apple-converted-space> </SPAN>Cisco VoIPoE List<BR><B>Subject:</B><SPAN class=Apple-converted-space> </SPAN>[cisco-voip] SIP Trunk Redundancy</SPAN></DIV></DIV>
<P class=MsoNormal style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"> </P>
<DIV style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"><SPAN class=apple-style-span>I'm working with a client that has 3 sites where the PRIs were replaced by SIP trunks. Everything appears to be running fine with the exception of outbound trunk redundancy. The appear to have just removed the PRIs from the existing RGs and replaced them with the SIP trunks. The problem is that if a SIP trunk goes down its not rerouting to the next trunk, they are just getting dead air. I'm assuming that this is similar to the issue seen with H323 trunks and why a gatekeeper would be needed for this but what are the options for SIP? I can probably get by with using Locations CAC for FO if the trunks fills but not sure about if it actually goes down and CUCM can determine that. CUCM 7.12 and no CUBE.</SPAN></DIV>
<DIV>
<DIV>
<P class=MsoNormal style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"> </P></DIV>
<DIV>
<DIV style="FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: 'Times New Roman', serif"><BR><BR><SPAN class=apple-style-span></SPAN></DIV></DIV></DIV></DIV><BR>_______________________________________________ cisco-voip mailing list<SPAN class=Apple-converted-space> </SPAN><A style="COLOR: blue; TEXT-DECORATION: underline" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><SPAN class=Apple-converted-space> </SPAN><A style="COLOR: blue; TEXT-DECORATION: underline" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A></DIV>_______________________________________________<BR>cisco-voip mailing list<BR><A style="COLOR: blue; TEXT-DECORATION: underline" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A style="COLOR: blue; TEXT-DECORATION: underline" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></DIV></DIV><pre>************************************
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information.
There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
************************************
</pre></BODY></HTML>