- VoiceOps - lists.voiceops.org

Experiences with VoIP and 100+ seat sites
by Eric.Jastak＠adp.com Feb. 2, 2012

Feb. 2, 2012

Aside from all of the many technical issues with installing the new VOIP PBX system, the biggest problem I have seen is moving from a traditional "Key System" to a "PBX" setup. With a PBX, you are completely changing the ways the customer's phone system is works (i.e., the customer's call flow is completely different with a PBX). While there are always work-arounds, most customers don't like radical change, and PBX systems have a hard time mimicking key system behavior. This causes a lot of grief with customers during (and after!) the transition. You can try to deploy shared lines to mimic key system behavior, but shared lines and VOIP don't always mix well (not all that reliable and some PBXs don't support them!). This is especially true when there are a lot of phone lines (more than 5!). So, you have to use Page/Park/Retrieve and/or Transfer functions instead. You will find that most customers are not happy with the change because it requires more "key presses" and is more difficult to remember all of the codes and/or softkey sequences. While some of this can be addressed with good training and a lot of hand-holding, ultimately, the customer will not be excited about the new phone system. Most customers simply want their old key system with the lower cost of VOIP. This is one of the reasons why SIP trunking is such a popular solution these days. They get their existing call flow with the cheaper call rates. Of course, the customer that is rapidly expanding and has requested new features is going to embrace the new PBX features and its many efficiencies... But, from my experience, most key system customers want to keep the call flow changes to a minimum, which is really hard to do when converting to a PBX. You really need to set expectations upfront, during the sales process, that they are getting a PBX and not a new key system. My two cents. EJ -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of voiceops-request at voiceops.org Sent: Wednesday, February 01, 2012 9:49 AM To: voiceops at voiceops.org Subject: VoiceOps Digest, Vol 32, Issue 2 Send VoiceOps mailing list submissions to voiceops at voiceops.org To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/voiceops or, via email, send a message with subject or body 'help' to voiceops-request at voiceops.org You can reach the person managing the list at voiceops-owner at voiceops.org When replying, please edit your Subject line so it is more specific than "Re: Contents of VoiceOps digest..." Today's Topics: 1. Re: Experiences with VoIP and 100+ seat sites (Tim Bray) 2. Re: Experiences with VoIP and 100+ seat sites (Jay Hennigan) 3. Re: Experiences with VoIP and 100+ seat sites (Carlos Alvarez) 4. Rephrased Question: 100+ seat MIGRATIONS to VoIP (Darren Schreiber) 5. Re: Experiences with VoIP and 100+ seat sites (Sean Grossman) 6. Re: Experiences with VoIP and 100+ seat sites (Alex Balashov) 7. Re: Rephrased Question: 100+ seat MIGRATIONS to VoIP (Carlos Alvarez) 8. FW: Linksys PAP2T (Scott Berkman) (Jastak, Eric) ---------------------------------------------------------------------- Message: 1 Date: Wed, 01 Feb 2012 17:08:52 +0000 From: Tim Bray <tim at kooky.org> To: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <4F2971A4.7000409 at kooky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 01/02/12 16:25, Darren Schreiber wrote: > Hi folks, > I'd love to hear some stories (good or bad) of hosted PBX VoIP > installs on 100+ seat sites (single site). Specifically if you've done > this with Broadsoft or another solidified switch. I have mixed > opinions on how this type of scenario can be successful and now I'm > being pressed by a client on a formal opinion. I figure having it > based on experience from others on a similar product is worth hearing about. > > Specifically curious about how you addressed call quality issues and > ensured bandwidth and uplink were sufficient. I help look after a site with 140 ish SIP phones on the same site. Works very well. Phones all on www.voipfone.co.uk The sums for network links are easy. Bandwidth per call * calls. Then spec the right circuit. Things people forget: 0) To plan the user experience. You can just slap a new phone on a desk and expect people to use it. You need to do training for end users. Even if you show them how to make a call. Do not tell the end users it is voip. Just `A new phone system`. 1) IP header allowance in bandwidth sums. RTP, UDP, IP, then Ethernet or ATM depending on the circuit. 2) Consider Packets per second through the router/firewall. VoIP is lots of small packets. Many firewalls have a low session count limit. a 25$ router is not going to cope with all those phones. 3) Just buy enough bandwidth 4) Protect the ethernet infrastructure. You want to be using managed switches which can - drop rogue DHCP servers - drop a port if somebody pretends to be the default gateway - cope when somebody makes a loop in the network or attaches a device which floods then lan with broadcasts 5) Put the Router in a HA setup with 2 routers and 2 WAN connections. With VRRP or CARP or similar. Or agree with the customer in writing that if the WAN fails, the phones fail. - or sell divert to mobile as part of the solution. 6) Manage all the phones on a configuration server. Lock all the phones down so people can't mess with them. 7) Don't use wifi to connect phones. 8) Avoid Active SIP ALGs. You don't want anything modding SIP packets on the router. Passive devices which detect SIP to do traffic prioritization are ok. Anything which modifies packets is bad. - Sometimes the SIP aware routers get hacked. 9) Don't use low rate codecs. 711 all the way. Or 722. 10) Primary and failover DHCP and DNS servers onsite. Tim ------------------------------ Message: 2 Date: Wed, 01 Feb 2012 09:12:05 -0800 From: Jay Hennigan <jay at west.net> To: voiceops at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <4F297265.5080505 at west.net> Content-Type: text/plain; charset=ISO-8859-1 On 2/1/12 8:25 AM, Darren Schreiber wrote: > Hi folks, > I'd love to hear some stories (good or bad) of hosted PBX VoIP installs > on 100+ seat sites (single site). Specifically if you've done this with > Broadsoft or another solidified switch. I have mixed opinions on how > this type of scenario can be successful and now I'm being pressed by a > client on a formal opinion. I figure having it based on experience from > others on a similar product is worth hearing about. We have done several with Broadsoft. > Specifically curious about how you addressed call quality issues and > ensured bandwidth and uplink were sufficient. It's pretty much the same formula as with smaller sites. As a rule, an office with lots of phones also has need for lots of data bandwidth. Some times a larger site is easier. Customers that have an office with 100+ employees understand the need for redundancy and high availability more than those with smaller offices. This allows us to provide two diverse circuits for failover and run the VoIP over one and data over the other. Only in the event of a failure of either link does QoS come into play. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ------------------------------ Message: 3 Date: Wed, 1 Feb 2012 10:33:26 -0700 From: Carlos Alvarez <carlos at televolve.com> To: Tim Bray <tim at kooky.org> Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <CAFn1dUGM0E6NHPw7Urh_CqaDAB2nP7x9YK6vcOsj3Cjx6K3H0w at mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Wed, Feb 1, 2012 at 10:08 AM, Tim Bray <tim at kooky.org> wrote: > > > 9) Don't use low rate codecs. 711 all the way. Or 722. > > > I completely disagree. Most of our customers are on g729 and nobody was able to hear the difference when we tested that versus 711. -- Carlos Alvarez TelEvolve 602-889-3003

6 9

Rephrased Question: 100+ seat MIGRATIONS to VoIP
by d＠d-man.org Feb. 2, 2012

Feb. 2, 2012

Hi all, Well, wonderful responses, thanks. I love this list. Unfortunately it appears I've not asked the right question for what I really wanted to know. If ya'all are willing to entertain me on this, I'd love some assistance. We are working with a firm who is trying to move many high-volume (think lawyers offices, doctors offices, etc.) 100+ seat offices from KEY systems (BLFs, Line keys, All-set paging, Intercom, one-touch transfer, the works) to VoIP. We are trying to advise them on how to sell into their market the most effectively, but we are running into issues where the clients expect the new system to act like the old system. This ranges from quality to feature set. I'm trying to figure out how others have handled this. Specifically, how did you monitor and ensure quality on untested / new VoIP circuits that hadn't been used for VoIP previously? What features did you just say "no, sorry, can't do via VoIP in exactly the same way"? Any? What phones did you sell them that they liked/disliked? Etc. Most of the replies I got to my other email were related to "we moved someone from Cisco UC to VoIP with no issue" which made me realize I'm asking the question incorrectly. Thanks again, Darren

8 8

Linksys PAP2T
by mh＠markholloway.com Feb. 1, 2012

Feb. 1, 2012

Has anyone encountered an issue where the PAP2T isn't honoring the registration timer in the contact header sent by an Acme Packet SD to the PAP2T? Any suggestions are appreciated.

3 3

T.38 re-invites
by Eric.Jastak＠adp.com Feb. 1, 2012

Feb. 1, 2012

Nathan, In a perfect world, the ATA (gateway) should only send T38 ReINVITEs upon "receiving" a fax call. In many cases, enabling T38 ReINVITEs in both directions can cause glare issues (e.g., on-net T38 fax calls). Unfortunately, the CPE device's ability to handle the glare condition will determine whether or not the fax call will be successfully negotiated. Some CPE devices handle it well, others don't at all. For our implementation, we shut off "outbound" T38 Re-INVITEs. This effectively avoids glare issues, especially with On-Net faxing; however, it does rely on the receiving ATA (gateway) to ALWAYS send the T38 ReINVITE. With all T38 implementations, you will need to perform a lot of testing and InterOp to ensure a reliable solution. There are design cases where enabling the T38 ReINVITE on outbound fax calls (ATAs) is required. But, that depends on the T38 termination gateway in your network (or your upstream partner's network). That is why most CPE vendors have the capability to send T38 ReINVITES for outbound fax calls. In general, you want a T38 solution that does NOT required the CPE gateway to send T38 ReINVITES for outbound fax calls. However, your testing may show that you need to send T38 ReINVITES for inbound/outbound fax calls in order for T38 to work in both directions. It is really dependent on your T38 design. My two cents, Eric -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan Anderson Sent: Wednesday, January 04, 2012 1:35 AM To: 'voiceops at voiceops.org' Subject: [VoiceOps] T.38 re-invites This might not be the most appropriate forum for such a question, but given that implementation bugs in either NOC gear or CPE gear can cause headaches for network operators, I offer this here in the hope that perhaps a fellow VoiceOp here may have run into this before and knows the answer... It is my understanding that with SIP, *either* party to a call can send another INVITE (a so-called "re-invite") at any time during an active session; this could be used to change the endpoint of a call or redirect it elsewhere, and is also commonly used to renegotiate the media in use (audio, video, image, and associated codecs) without dropping the call even while the endpoints remain the same. Does this hold true, though, for re-invites whose purpose is to switch from an RTP audio stream to a T.38 UDPTL stream? Can *either* peer send that INVITE? Or is there a rule -- spoken or unspoken -- that states that a T.38 re-invite can only be initiated by the *receiver* of the fax, and not the transmitter? I have some ATAs that appear to send out a T.38 re-invite upon detection of a fax tone regardless of whether the ATA placed the call or answered the call, and if I am understanding what I'm seeing in my packet captures, I think the fact that these ATAs do this even when they are going to play the role of the T.38 transmitter is confusing the heck out of my (Asterisk) SBC and the termination provider. But I can't find any concrete evidence to support the idea that T.38 re-invites should only be initiated by the receiver. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of voiceops-request at voiceops.org Sent: Wednesday, February 01, 2012 9:49 AM To: voiceops at voiceops.org Subject: VoiceOps Digest, Vol 32, Issue 2 Send VoiceOps mailing list submissions to voiceops at voiceops.org To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/voiceops or, via email, send a message with subject or body 'help' to voiceops-request at voiceops.org You can reach the person managing the list at voiceops-owner at voiceops.org When replying, please edit your Subject line so it is more specific than "Re: Contents of VoiceOps digest..." Today's Topics: 1. Re: Experiences with VoIP and 100+ seat sites (Tim Bray) 2. Re: Experiences with VoIP and 100+ seat sites (Jay Hennigan) 3. Re: Experiences with VoIP and 100+ seat sites (Carlos Alvarez) 4. Rephrased Question: 100+ seat MIGRATIONS to VoIP (Darren Schreiber) 5. Re: Experiences with VoIP and 100+ seat sites (Sean Grossman) 6. Re: Experiences with VoIP and 100+ seat sites (Alex Balashov) 7. Re: Rephrased Question: 100+ seat MIGRATIONS to VoIP (Carlos Alvarez) 8. FW: Linksys PAP2T (Scott Berkman) (Jastak, Eric) ---------------------------------------------------------------------- Message: 1 Date: Wed, 01 Feb 2012 17:08:52 +0000 From: Tim Bray <tim at kooky.org> To: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <4F2971A4.7000409 at kooky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 01/02/12 16:25, Darren Schreiber wrote: > Hi folks, > I'd love to hear some stories (good or bad) of hosted PBX VoIP > installs on 100+ seat sites (single site). Specifically if you've done > this with Broadsoft or another solidified switch. I have mixed > opinions on how this type of scenario can be successful and now I'm > being pressed by a client on a formal opinion. I figure having it > based on experience from others on a similar product is worth hearing about. > > Specifically curious about how you addressed call quality issues and > ensured bandwidth and uplink were sufficient. I help look after a site with 140 ish SIP phones on the same site. Works very well. Phones all on www.voipfone.co.uk The sums for network links are easy. Bandwidth per call * calls. Then spec the right circuit. Things people forget: 0) To plan the user experience. You can just slap a new phone on a desk and expect people to use it. You need to do training for end users. Even if you show them how to make a call. Do not tell the end users it is voip. Just `A new phone system`. 1) IP header allowance in bandwidth sums. RTP, UDP, IP, then Ethernet or ATM depending on the circuit. 2) Consider Packets per second through the router/firewall. VoIP is lots of small packets. Many firewalls have a low session count limit. a 25$ router is not going to cope with all those phones. 3) Just buy enough bandwidth 4) Protect the ethernet infrastructure. You want to be using managed switches which can - drop rogue DHCP servers - drop a port if somebody pretends to be the default gateway - cope when somebody makes a loop in the network or attaches a device which floods then lan with broadcasts 5) Put the Router in a HA setup with 2 routers and 2 WAN connections. With VRRP or CARP or similar. Or agree with the customer in writing that if the WAN fails, the phones fail. - or sell divert to mobile as part of the solution. 6) Manage all the phones on a configuration server. Lock all the phones down so people can't mess with them. 7) Don't use wifi to connect phones. 8) Avoid Active SIP ALGs. You don't want anything modding SIP packets on the router. Passive devices which detect SIP to do traffic prioritization are ok. Anything which modifies packets is bad. - Sometimes the SIP aware routers get hacked. 9) Don't use low rate codecs. 711 all the way. Or 722. 10) Primary and failover DHCP and DNS servers onsite. Tim ------------------------------ Message: 2 Date: Wed, 01 Feb 2012 09:12:05 -0800 From: Jay Hennigan <jay at west.net> To: voiceops at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <4F297265.5080505 at west.net> Content-Type: text/plain; charset=ISO-8859-1 On 2/1/12 8:25 AM, Darren Schreiber wrote: > Hi folks, > I'd love to hear some stories (good or bad) of hosted PBX VoIP installs > on 100+ seat sites (single site). Specifically if you've done this with > Broadsoft or another solidified switch. I have mixed opinions on how > this type of scenario can be successful and now I'm being pressed by a > client on a formal opinion. I figure having it based on experience from > others on a similar product is worth hearing about. We have done several with Broadsoft. > Specifically curious about how you addressed call quality issues and > ensured bandwidth and uplink were sufficient. It's pretty much the same formula as with smaller sites. As a rule, an office with lots of phones also has need for lots of data bandwidth. Some times a larger site is easier. Customers that have an office with 100+ employees understand the need for redundancy and high availability more than those with smaller offices. This allows us to provide two diverse circuits for failover and run the VoIP over one and data over the other. Only in the event of a failure of either link does QoS come into play. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ------------------------------ Message: 3 Date: Wed, 1 Feb 2012 10:33:26 -0700 From: Carlos Alvarez <carlos at televolve.com> To: Tim Bray <tim at kooky.org> Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <CAFn1dUGM0E6NHPw7Urh_CqaDAB2nP7x9YK6vcOsj3Cjx6K3H0w at mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Wed, Feb 1, 2012 at 10:08 AM, Tim Bray <tim at kooky.org> wrote: > > > 9) Don't use low rate codecs. 711 all the way. Or 722. > > > I completely disagree. Most of our customers are on g729 and nobody was able to hear the difference when we tested that versus 711. -- Carlos Alvarez TelEvolve 602-889-3003

1 0

FW: Linksys PAP2T (Scott Berkman)
by Eric.Jastak＠adp.com Feb. 1, 2012

Feb. 1, 2012

I have had the same problem with the Cisco SPA ATAs (Linksys). I was able to get the SPA ATA to honor the ACME SBC settings, but as Scott says below, the registration values can't be more than 50% apart. On a related note... I also found was that the SPA2102 and SPA8000 ATA software re-registers "3" sec before the timer expires; for example, if the registration timer set by ACME on the ATA is set to 205 seconds, the ATA will attempt to re-register every 202 seconds. This is much different from the Cisco SPA phones, which register at 67% of the set reg timer value. The "3" sec re-registration timer is NOT a configurable value as it is set in the software. So, you will need to adjust your desired registration timer on the SBC for the ATAs to match what your Firewall UDP timers are expecting (if that is an issue for your CPE setup). Otherwise, your SIP ports will be shut-down pre-maturely. This was a problem for us. -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of voiceops-request at voiceops.org Sent: Wednesday, February 01, 2012 8:51 AM To: voiceops at voiceops.org Subject: VoiceOps Digest, Vol 32, Issue 1 Send VoiceOps mailing list submissions to voiceops at voiceops.org To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/voiceops or, via email, send a message with subject or body 'help' to voiceops-request at voiceops.org You can reach the person managing the list at voiceops-owner at voiceops.org When replying, please edit your Subject line so it is more specific than "Re: Contents of VoiceOps digest..." Today's Topics: 1. Linksys PAP2T (Mark Holloway) 2. Re: Linksys PAP2T (Scott Berkman) 3. Experiences with VoIP and 100+ seat sites (Darren Schreiber) 4. Re: Experiences with VoIP and 100+ seat sites (Carlos Alvarez) 5. Re: Experiences with VoIP and 100+ seat sites (Zak Rupas) 6. Re: Experiences with VoIP and 100+ seat sites (Carlos Alvarez) ---------------------------------------------------------------------- Message: 1 Date: Tue, 31 Jan 2012 16:05:30 -0700 From: Mark Holloway <mh at markholloway.com> To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] Linksys PAP2T Message-ID: <77FD9C82-4778-4889-A573-7810BF41B43A at markholloway.com> Content-Type: text/plain; charset=us-ascii Has anyone encountered an issue where the PAP2T isn't honoring the registration timer in the contact header sent by an Acme Packet SD to the PAP2T? Any suggestions are appreciated. ------------------------------ Message: 2 Date: Tue, 31 Jan 2012 20:31:17 -0500 From: "Scott Berkman" <scott at sberkman.net> To: "'Mark Holloway'" <mh at markholloway.com>, "'VoiceOps'" <voiceops at voiceops.org> Subject: Re: [VoiceOps] Linksys PAP2T Message-ID: <033301cce081$33f1f640$9bd5e2c0$(a)sberkman.net> Content-Type: text/plain; charset="us-ascii" What is the Acme trying to set the timer to, and how does that compare to the default registration interval in the Linksys? I think they can't be more than 50% apart (so if the Linksys is set to 3600, and the Acme suggests 30, that's too much of a difference and you'd need to lower the interval on the Linksys). There are also settings for min and max registration interval on the SIP settings page. -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Mark Holloway Sent: Tuesday, January 31, 2012 6:06 PM To: VoiceOps Subject: [VoiceOps] Linksys PAP2T Has anyone encountered an issue where the PAP2T isn't honoring the registration timer in the contact header sent by an Acme Packet SD to the PAP2T? Any suggestions are appreciated. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops ------------------------------ Message: 3 Date: Wed, 1 Feb 2012 08:25:27 -0800 From: Darren Schreiber <d at d-man.org> To: "VoiceOps at voiceops.org" <VoiceOps at voiceops.org> Subject: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <CB4EA777.482AB%d at d-man.org> Content-Type: text/plain; charset="us-ascii" Hi folks, I'd love to hear some stories (good or bad) of hosted PBX VoIP installs on 100+ seat sites (single site). Specifically if you've done this with Broadsoft or another solidified switch. I have mixed opinions on how this type of scenario can be successful and now I'm being pressed by a client on a formal opinion. I figure having it based on experience from others on a similar product is worth hearing about. Specifically curious about how you addressed call quality issues and ensured bandwidth and uplink were sufficient. As much detail as you're willing would be great, on or off list. Thanks, Darren

1 0

Rogue 800 number
by sil＠infiltrated.net Jan. 31, 2012

Jan. 31, 2012

Hey all, just wondering slash curious about something. I have a client who had their domain pseudo-typosquatted and whomever is behind it went as far as registering a toll free number with a professional sounding AutoAttendant referencing the victim company's name and the owner on a dial by name directory. There are no accents/typos in the autoattendant and dialing an extension, as we all can imagine, is likely being call forwarded or trunked elsewhere. In any event, I would like to track down what carrier is responsible for the number but have had no luck asking/enquiring/etc to my carriers (big 3-4 Level, VZ, Global, Paetec)... Any takers on tracking who owns this number? -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF

4 3

Higher than normal Latency to Verizon HSJ
by jared＠compuwizz.net Jan. 31, 2012

Jan. 31, 2012

Anyone else noticing higher than normal latency to Verizon's HSJ location? Its steady, but 100 ms higher than usual. This is coming from Ashburn and on the Verizon network. The other locations are at normal latency levels. Gotta love MPLS hiding this topology. It started at 10:00 GMT and still going. Host Loss% Last Avg Best Wrst StDev 1. rtr.rtc.vocaltransit.net 0.0% 0.4 0.2 0.1 0.8 0.1 2. 193.xe-4-0-0.er1.iad10.us.above.net 0.0% 0.6 3.3 0.6 44.7 10.0 3. xe-1-0-0.er2.iad10.us.above.net 0.0% 0.8 3.1 0.5 40.7 8.1 4. above-uu.iad10.us.above.net 0.0% 0.8 2.3 0.8 40.1 6.6 5. 0.ae1.XL4.IAD8.ALTER.NET 0.0% 0.7 6.6 0.6 86.4 18.5 6. 0.ge-6-3-0.XT2.HOU7.ALTER.NET 0.0% 137.8 141.5 135.5 203.1 12.8 7. 0.so-4-0-0.XR2.HOU7.ALTER.NET 0.0% 138.1 138.4 136.9 139.0 0.4 8. 182.at-7-0-0.HR3.HOU7.ALTER.NET 0.0% 139.2 139.7 137.9 177.5 6.3 9. 0.ge-0-0-0.PR1.HOU7.ALTER.NET 0.0% 138.9 138.6 137.9 139.1 0.3 10. <verizon endpoint> 0.0% 139.7 149.7 137.3 534.0 64.9

1 1

MetroPCS - Contact Info
by alejandro＠amerimex.com Jan. 30, 2012

Jan. 30, 2012

We are having problems with MetroPCS not delivering CallerID or sending the incorrect one when using long distance. Does anybody have a contact that we can use? Thanks, Alejandro Caipa IT Director 1007 Mansell Road Suite A Roswell GA 30076 Direct Dial: 678.832.6220 alejandro at amerimex.com www.amerimex.com

1 0

Selecting correct source on Net VX SBC
by nick＠inticon.net.au Jan. 29, 2012

Jan. 29, 2012

Morning All, We are working with a Net VX SBC that has multiple customers downstream and a single carrier upstream, to all intents and purposesthe downstream customers have services directly with the upstream carrier. The upstream carrier allocates a set of credentials which are ACL'ed to a specific point-to-point subnet for each service. In our scenario we have a set of credentials and corresponding interconnect for each downstream customer. The carrier provides a single set of signaling and media addresses across all services.. To the best of our knowledge, the SBC only supports a single routing instance, hence when traffic destined for the upstream provider is sent out, it can only follow one route. To get around this, and ensure that traffic goes out over the correct point-to-point interface, we intended to impliment a policy-based-route, assuming that the SBC would source traffic from the IP of the SIP instance regardless of what interface the traffic left the SBC on, this appears to be incorrect however and the traffic is always sourced from the IP on the interface of the default route. Interestingly at a SIP layer everything looks OK. To further complicate matters the SBC is managed by a third party. Has anyone done anything similar in the past, with Net equipment or otherwise? Any feedback much appreciated. Cheers Nick.

1 0

Looking for an IPTV source.
by matthew＠corp.crocker.com Jan. 27, 2012

Jan. 27, 2012

Howdie, I know this is the VOICE list but I'm hoping someone here has some contacts. I'm looking for a IPTV wholesaler that I can partner with to deliver IPTV services to FTTH customers. It will be something pretty small to start. Only a couple hundred houses past. I don't want to invest in a head-end. Just pick up some bandwidth and aim the set top boxes to the providers head-end. I can get a GigE into Boston pretty easily for a dedicated trunk. Please forward any contact info you may have Thanks -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760

4 4