Send VoiceOps mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Re: AT&T Flexible Reach (Mark R Lindsey)
2. Re: AT&T Flexible Reach (Peter Rad.)
3. Re: Broadsoft / 3CX SIP Trunks (PE)
4. Re: AT&T Flexible Reach (Alex Balashov)
5. Re: AT&T Flexible Reach (Mark R Lindsey)
6. Re: AT&T Flexible Reach (Alex Balashov)
7. Re: Broadsoft / 3CX SIP Trunks (PE)
----------------------------------------------------------------------
Message: 1
Date: Mon, 1 Oct 2012 11:43:23 -0400
From: Mark R Lindsey <[email protected]>
To: "Stappenbeck, Mark" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] AT&T Flexible Reach
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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.
>>> [email protected] +12293160013 http://ecg.co/lindsey
On Oct 1, 2012, at 11:13 , "Stappenbeck, Mark" <[email protected]> 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
> [email protected] | windstreambusiness.com
> o: 585.421.5508 | f: 585.421.3853
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Alex Balashov
> Sent: Monday, October 01, 2012 11:05 AM
> To: [email protected]
> 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
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
>
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
Message: 2
Date: Mon, 01 Oct 2012 17:17:27 -0400
From: "Peter Rad." <[email protected]>
To: [email protected]
Subject: Re: [VoiceOps] AT&T Flexible Reach
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
ATT people are not allowed to call another LEC. They might be thinking
that Allworx is Windstream is a LEC.
Have end user do it.
On 10/1/2012 11:13 AM, Stappenbeck, Mark 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
> [email protected] | windstreambusiness.com
> o: 585.421.5508 | f: 585.421.3853
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Alex Balashov
> Sent: Monday, October 01, 2012 11:05 AM
> To: [email protected]
> 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
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
>
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
------------------------------
Message: 3
Date: Tue, 2 Oct 2012 08:33:50 -0400
From: PE <[email protected]>
To: [email protected]
Subject: Re: [VoiceOps] Broadsoft / 3CX SIP Trunks
Message-ID:
<CAHm=saj_tslgnhb4nrsgydgoscm8sjfsjyqsckeqfswpkvk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks all. It is too early to declare victory but based on my tests it
looks like the Acme SIPConnect feature + Broadworks Alternate Trunk
Identity is going to be the solution.
On Tue, Sep 25, 2012 at 5:27 PM, PE <[email protected]> wrote:
> Greetings fellow voipsters,
>
> Have any of you done a SIP trunk integration between Broadsoft and 3CX?
> Or, more specifically, I have a customer with a 3CX device (don't ask) that
> is registered and I can send an INVITE, but their end denies the call
> (sends a 480 Temporarily Unavailable response) because it is having trouble
> routing it to the destination in the 3CX system. This is because they are
> expecting only the extension (4-digits), which I can send in the To: header
> but the SIP URI is the full, registered User ID so that the SBC knows how
> to get it to them. They are expecting only 4 digits in both the INVITE URI
> header and the To header.
>
> I know I can create a complex/convoluted header manipulation with the SBC
> but it just feels like there must be another way.
>
> Anyone know how to config the 3CX -- or even have a decent workaround --
> to support this?
>
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20121002/5539b444/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 02 Oct 2012 08:40:04 -0400
From: Alex Balashov <[email protected]>
To: Mark R Lindsey <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] AT&T Flexible Reach
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/01/2012 11:43 AM, Mark R Lindsey wrote:
> 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.
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.
--
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/
------------------------------
Message: 5
Date: Tue, 2 Oct 2012 09:19:44 -0400
From: Mark R Lindsey <[email protected]>
To: Alex Balashov <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] AT&T Flexible Reach
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Oct 2, 2012, at 08:40 , Alex Balashov <[email protected]> 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.
>>> [email protected] +12293160013 http://ecg.co/lindsey
------------------------------
Message: 6
Date: Tue, 02 Oct 2012 09:39:48 -0400
From: Alex Balashov <[email protected]>
To: Mark R Lindsey <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] AT&T Flexible Reach
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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/
------------------------------
Message: 7
Date: Tue, 2 Oct 2012 10:20:58 -0400
From: PE <[email protected]>
To: [email protected]
Subject: Re: [VoiceOps] Broadsoft / 3CX SIP Trunks
Message-ID:
<CAHm=SaK-qn40zXBz5NkzK-AwxSU_i5m2a_LUfUxd-te9OXA=2...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
**grumble**
There's an Edgemarc in the middle and it is throwing a 404 because it
doesn't know what to do with the call. I think I am now sending what the
3CX wants but unfortunately a proxy is required for this implementation.
I knew it was too soon to declare victory. Back to scratching my head.
On Tue, Oct 2, 2012 at 8:33 AM, PE <[email protected]> wrote:
> Thanks all. It is too early to declare victory but based on my tests it
> looks like the Acme SIPConnect feature + Broadworks Alternate Trunk
> Identity is going to be the solution.
>
>
>
>
>
> On Tue, Sep 25, 2012 at 5:27 PM, PE <[email protected]> wrote:
>
>> Greetings fellow voipsters,
>>
>> Have any of you done a SIP trunk integration between Broadsoft and 3CX?
>> Or, more specifically, I have a customer with a 3CX device (don't ask) that
>> is registered and I can send an INVITE, but their end denies the call
>> (sends a 480 Temporarily Unavailable response) because it is having trouble
>> routing it to the destination in the 3CX system. This is because they are
>> expecting only the extension (4-digits), which I can send in the To: header
>> but the SIP URI is the full, registered User ID so that the SBC knows how
>> to get it to them. They are expecting only 4 digits in both the INVITE URI
>> header and the To header.
>>
>> I know I can create a complex/convoluted header manipulation with the SBC
>> but it just feels like there must be another way.
>>
>> Anyone know how to config the 3CX -- or even have a decent workaround --
>> to support this?
>>
>>
>> Thanks
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20121002/879321f5/attachment.html>
------------------------------
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
End of VoiceOps Digest, Vol 40, Issue 3
***************************************
