[VoiceOps] AT&T Flexible Reach

[Mark R Lindsey]

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