There's a lot of debate about whether Certification of CPE is ever the right approach for SIP Trunking. The spectrum of sane choices includes: (a) The Bellhead Model: Service Provider chooses, tests, and blesses only certain devices, running certain software versions. (Result: All of the certified devices are unavailable or obsolete by next month.) (b) The Empirical Model: Service Provider provides a test platform allowing customers to test and verify whatever it is they have. Then the Service Provider validates the results and approves the service, or finds problems. (Result: The customer has to work hard to prove his service works, and the SP may lose the deal if the customer isn't willing. But at least the customer has working service the whole time, and the Service Provider isn't trying to lab-test on a production service.) In addition to the two sane options above, there's another option that doesn't fit into any category of functional mental health: (c) The Clean-It-Up-Later Model: Customer turns up whatever he wants, numbers are ported to the new service provider, and then and then they test and troubleshoot it when it's supposed to be live. Typically service-affecting problems are discovered during the first month. The Google evidence is that AT&T Flexible Reach is following model (a), where individual Enterprise SBCs are certified. It's becoming more common for SIP trunking that only the CPE SBC is certified, allowing the customer some freedom on the actual SIP PBX or gateway behind the Enterprise SBC. For example, Google shows claims that the Avaya Aura, Sipera E-SBC, and Net.com Enterprise SBCs are supported by AT&T Flexible REach.

...

...

mark at ecg.co +12293160013 http://ecg.co/lindsey

On Oct 1, 2012, at 11:13 , "Stappenbeck, Mark" <MStappenbeck at allworx.com> wrote:

That's been the problem. Multiple BP's trying to get that info through their AM's and SE's, across markets, haven't been able to get that info. Tried from the top down (VoIP product manager) also, no return calls.

Mark Stappenbeck Senior Manager, Business Development - Allworx | Windstream 300 Main St | East Rochester, NY 14445 mstappenbeck at allworx.com | windstreambusiness.com o: 585.421.5508 | f: 585.421.3853

-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Monday, October 01, 2012 11:05 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] AT&T Flexible Reach

On 10/01/2012 10:41 AM, Stappenbeck, Mark wrote:

...

Does anyone have any experience certifying SIP endpoints with the AT&T product?

Having a hard time finding the correct department to start the interop process with.

Stupid question, but hasn't your account manager given you clear next steps, and contacts?

-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

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

On Oct 2, 2012, at 08:40 , Alex Balashov <abalashov at evaristesys.com> wrote:

On 10/01/2012 11:43 AM, Mark R Lindsey wrote:

...

For example, Google shows claims that the Avaya Aura, Sipera E-SBC, and Net.com Enterprise SBCs are supported by AT&T Flexible REach.

That seems quite problematic for those who want to use/can't afford an SBC per se, or at least an approved SBC, for their network edge.  The big Service Providers (SPs) are requiring an SBC because customers are holding THEM accountable when the customer's PBX can't do SIP in a way that the SP's core network expects.

Here's one such scenario: you'll find PBXs that seem incapable of doing call forwarding properly. They end up originating a call from the CPE PBX to the SP with no explicit indications in the header of which user is placing the call. That is, the From header includes a PSTN user, and the Request-URI and To headers includes a PSTN user, and there's no Remote-Party-ID, nor P-Asserted-Identity, nor Diversion, nor History-Info to indicate the original SP customer to which the number was routed. The customer gets angry because the SP is blocking their calls. But the SP's system isn't setup to allow SIP trunk users to send calls with any random calling party identity in the From header. In many cases, billing, call routing, and call restrictions ("Outgoing Calling Plan"), etc, are all based on the user identified in the From header. When the customer has an SBC, this scenario can be handled, and the SP can help them make it so. E.g., perhaps they just need to add a Diversion header including one of the customer's genuine telephone numbers. Everybody ends up happy enough. But when the customer lacks an SBC, often the problem cannot be solved, without replacing the PBX, or possibly doing big upgrades. Or perhaps it could be done, if only the customer or the SP knew the magic incantation required to manipulate headers in some random SIP PBX; but for the Foobarina 2000 SIP PBX, nobody happens to know that magic spell. The customer ends up angry, and the SP may lose a customer. This puts pressure on the SIP PBX & SIP-to-TDM gateway vendors to handle SIP in a useful, meaningful way, e.g., SIPConnect. But it puts even MORE and more immediate pressure on the SP to turn up the circuit and make it work. And after a few trainwrecks deployments, the SP tries to stop the bloodshed, and starts requiring an Enterprise PBX.

...

...

mark at ecg.co +12293160013 http://ecg.co/lindsey

The configuration on our side has many options, including Diversion, to allow the most flexibility we can. We prefer to test against an actual circuit as delivered in a production environment. We run through our own test plan to determine what features are supported by the carrier/ISP, while they do the same on their side. At that point we have a configuration guide that is made available to our business partners. What happens many times is that the "lab" configuration doesn't mirror a deployed configuration, and issues arise. And LCR provides challenges a times as the new route passes through gateways that behave in different ways. Mark Stappenbeck Senior Manager, Business Development Allworx 300 Main Street East Rochester, NY 14445 585-421-5508 Office (585) 421-3853 Fax mstappenbeck at allworx.com www.allworx.com ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Tuesday, October 02, 2012 9:40 AM To: Mark R Lindsey Cc: Stappenbeck, Mark; voiceops at voiceops.org Subject: Re: [VoiceOps] AT&T Flexible Reach I was thinking more of scenarios in which there is an edge element/administrative border which can perform header manipulations, particularly adding identifying headers, but can't mangle to the same extent that an SBC (with a B2BUA internally) can. As a company specialising largely in proxies for such applications, that's something that comes up in our radar a lot. We can debate the propriety of using a proxy for such an application, but regardless, it's commonly done, for reasons of throughput and cost. The problem, as you know, is that proxies are quite circumscribed in the aspects of a SIP message they can manipulate--at least, standards-compliant proxies. In a very real sense, UAs on two sides of a proxy are interoperating with each other, rather than with the proxy. This creates both philosophical questions ("what exactly is the CPE here?") and a orthogonal, sometimes turbulent approach in relation to Bellhead expectations about how trunking works. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/