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