[VoiceOps] T.38 re-invites

Jastak, Eric Eric.Jastak at adp.com
Wed Feb 1 13:43:04 EST 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120201/abad1ea6/attachment-0001.html>

------------------------------

Message: 4
Date: Wed, 1 Feb 2012 09:37:32 -0800
From: Darren Schreiber <d at d-man.org>
To: "VoiceOps at voiceops.org" <VoiceOps at voiceops.org>
Subject: [VoiceOps] Rephrased Question: 100+ seat MIGRATIONS to VoIP
Message-ID: <CB4EB85C.48491%d at d-man.org>
Content-Type: text/plain; charset="us-ascii"

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120201/d783ea56/attachment-0001.html>

------------------------------

Message: 5
Date: Wed, 1 Feb 2012 12:37:44 -0500
From: Sean Grossman <sean.grossman at gmail.com>
To: Jay Hennigan <jay at west.net>
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites
Message-ID:
        <CAEnn9Q0y7oBqzQdp=Xcge8bzH_X62WE7seRNYeSgR-_BVwiUVw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I second most everything that Tim and Carlos have said. The PBX side is
rarely what turns a large site deployment sour - it usually comes down the
LAN/WAN and project management.

To that end, I'd add that a survey of the physical LAN should be conducted
to find any dumb switches lying under desks or areas that are not yet
occupied that could be hastily connected to the LAN in a suboptimal fashion.

Another issue that could pop up (if the phones' TFTP server is not on the
LAN) is bandwidth saturation on your upstream link when upgrading
firmware.  TFTP does not handle missing/out of order packets well and
phones can enter a continuous download/reboot loop. Avoid the temptation to
turn up the entire VoIP VLAN at once, as 100 simultaneous firmware
downloads will crush a low (<= 3Mb) link.

Please excuse any typos, spelling errors etc - mobile.

-Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120201/46881fee/attachment-0001.html>

------------------------------

Message: 6
Date: Wed, 01 Feb 2012 12:39:25 -0500
From: Alex Balashov <abalashov at evaristesys.com>
To: voiceops at voiceops.org
Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites
Message-ID: <4F2978CD.8000305 at evaristesys.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 02/01/2012 12:33 PM, Carlos Alvarez wrote:

> I completely disagree.  Most of our customers are on g729 and
> nobody was able to hear the difference when we tested that versus
> 711.

It comes across in hold music, and other things that fill up more of
the acoustic range of the good ol' 3.1 KHz bearer spectrum.

But yeah, on WiMax, that would make sense.

--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/


------------------------------

Message: 7
Date: Wed, 1 Feb 2012 10:47:32 -0700
From: Carlos Alvarez <carlos at televolve.com>
To: "VoiceOps at voiceops.org" <VoiceOps at voiceops.org>
Subject: Re: [VoiceOps] Rephrased Question: 100+ seat MIGRATIONS to
        VoIP
Message-ID:
        <CAFn1dUH3xu38PnzxbUo996ShNFfmDguJycJOyBJXSJMAUYAXdw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Wed, Feb 1, 2012 at 10:37 AM, Darren Schreiber <d at d-man.org> wrote:

>
> Specifically, how did you monitor and ensure quality on untested / new
> VoIP circuits that hadn't been used for VoIP previously?
>

So you're going to deploy on an uncontrolled, wild internet connection and
want to know how to test it?


> What features did you just say "no, sorry, can't do via VoIP in exactly
> the same way"? Any?
>

"Via VoIP" is not valid.  You can't have some key system features on a PBX
of any kind is how it should be stated.  You are getting PBX features such
as "x" but you lose key system features such as "y" in exchange.  But in
many cases you can replicate key system features.

I explain to customers that they are moving from a small-business product
called a key system to an enterprise product called a PBX.  Give them a few
reasons why that's good, and just explain that if there are missing
features we will find a way to either code them or teach them work-arounds
(the code them part is why I use Asterisk).


> What phones did you sell them that they liked/disliked?
>

Cisco SPA series are universally well received.  I haven't run into phones
they didn't like, but we excluded a lot of the junky phones ourselves in
testing.


> Etc.
>

No reason to treat it like VoIP versus everything else on the user side.
 It's just a new high-end PBX.

On the data side, you may want to re-think the "use whatever is there"
philosophy for 100+ deployments.


--
Carlos Alvarez
TelEvolve
602-889-3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120201/aba0cc7d/attachment-0001.html>

------------------------------

Message: 8
Date: Wed, 1 Feb 2012 11:49:32 -0600
From: "Jastak, Eric" <Eric.Jastak at adp.com>
To: "voiceops at voiceops.org" <voiceops at voiceops.org>
Subject: [VoiceOps] FW: Linksys PAP2T (Scott Berkman)
Message-ID:
        <050AD00BA3878A4F9C3A87D0D77E3C06BC4B0E24B9 at DSMAIL1HE.ds.ad.adp.com>
Content-Type: text/plain; charset="us-ascii"

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$@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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120201/2df9b74c/attachment-0001.html>

------------------------------

Message: 4
Date: Wed, 1 Feb 2012 09:41:20 -0700
From: Carlos Alvarez <carlos at televolve.com>
To: voiceops at voiceops.org
Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites
Message-ID:
        <CAFn1dUFB=ZgE-=ZzPHtYptyUPv_4MGGMNwsLHiCA=Kueu0RMoA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Since I only use Asterisk, would my experience be useful with 100-seat sites?

On Wed, Feb 1, 2012 at 9:25 AM, Darren Schreiber <d at d-man.org> 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.
>
> As much detail as you're willing would be great, on or off list.
>
> Thanks,
> Darren
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>


--
Carlos Alvarez
TelEvolve
602-889-3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120201/7f8f825b/attachment-0001.html>

------------------------------

Message: 5
Date: Wed, 1 Feb 2012 09:49:21 -0700
From: Zak Rupas <zak at simplesignal.com>
To: Carlos Alvarez <carlos at televolve.com>, voiceops at voiceops.org
Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites
Message-ID: <9f608f078e619af3a0749676f7006115 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

*I have done and my company has done 100 seat installs using Hosted phones with Broadsoft. Let me know what type of questions you have*

* *

*Thanks-*

Zak





*From:* voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
*On Behalf Of *Carlos Alvarez
*Sent:* Wednesday, February 01, 2012 9:41 AM
*To:* voiceops at voiceops.org
*Subject:* Re: [VoiceOps] Experiences with VoIP and 100+ seat sites



Since I only use Asterisk, would my experience be useful with 100-seat sites?

On Wed, Feb 1, 2012 at 9:25 AM, Darren Schreiber <d at d-man.org> 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.



As much detail as you're willing would be great, on or off list.



Thanks,

Darren




_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops





--

Carlos Alvarez

TelEvolve

602-889-3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120201/edbcb9a9/attachment-0001.html>

------------------------------

Message: 6
Date: Wed, 1 Feb 2012 09:51:46 -0700
From: Carlos Alvarez <carlos at televolve.com>
To: "VoiceOps at voiceops.org" <VoiceOps at voiceops.org>
Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites
Message-ID:
        <CAFn1dUHCTwifUJf_faiAR2pDynKkkqq5XLVLx3hPetkvTCCuyQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Wed, Feb 1, 2012 at 9:25 AM, Darren Schreiber <d at d-man.org> 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.
>

I've done a couple in this range.  I don't think 100 is a lot, and I don't think it's much of a challenge.  The "things to do" are pretty straightforward and there are lots of sources for best practices.  For example, if you do separate cabling and switches for the phones, then you can simply ignore LAN QoS (CoS) and you'll have a nice separate network for troubleshooting purposes.  This is what I do.


> Specifically curious about how you addressed call quality issues and
> ensured bandwidth and uplink were sufficient.
>

You need a circuit that either has QoS from the ISP, is direct to the VoIP carrier, or a separate circuit with guaranteed bandwidth to the carrier(s) if you want a guarantee.  That said, I've done 70+ concurrent calls over wild internet without major issues by simply selecting an ISP with excellent upstream connectivity.  I don't know your level of understanding of internet routing, so it's hard to know where to go with those details.

When we deploy to our larger local customers (which to us is 25 or more), we use a local ISP who has a city-wide WiMAX network.  They deliver a VLAN from the customer site directly to our presence in the same facilities they are in.  This takes the guessing out of it.  You can do the same with most any carrier with the right engineering.  The first question would be who is the SIP provider?

This isn't black magic.  100 phones really is pretty simple and the ability to give them very high levels of service is well set.

--
Carlos Alvarez
TelEvolve
602-889-3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120201/eb5f4e8c/attachment.html>

------------------------------

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


End of VoiceOps Digest, Vol 32, Issue 1
***************************************


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.



This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.



This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.



------------------------------

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


End of VoiceOps Digest, Vol 32, Issue 2
***************************************


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.



More information about the VoiceOps mailing list