What to look for in a SIP Trunking concept?
Trying to develop an Enterprise SIP trunking concept that allows us the flexibility to interconnect with the major PBX vendors on one side and SIP trunking providers on the other side. Looking at ACMEPACKET as the Integrator SBC box for this concept. One thought was to ask the PBX vendors and Service Provider if they have adopted the SIP Connect 1.1 standard? I'm not a voice expert so would really appreciate any comments and /or suggestions on what we need to be weary of from each party as we develop this concept, especially with regard to regulatory obligations. Thanks, -guy
SIPConnect has a lot of good ideas and rules. It describes "well behaved" SIP trunking behavior. But, unfortunately, they've moved beyond the generally-accepted Best Current Practices. For example, they now *require* service provider (SP) support for encrypted VoIP signaling. SIPConnect also requires parent/child registration; i.e., "trunk group" registration. Some platforms can now support that, and it's a great feature. But other good platforms don't support it (yet). So SIPConnect is a good piece of work, but if you get too locked in to supporting SIPConnect, you can waste money implementing requirements, and may ultimately ruin the business plan (by raising your fixed costs too high) or design an un-implementable network. But in general, the biggest danger is in pretending you can support too much. Start with a *small* set of certified, supported SIP PBX/IAD devices, and then promise success only with systems and software versions on your list. In addition, list the specific features that are supported for those devices. If you allow customers to believe you support any self-described SIP- trunking-capable system out there, you'll fail. The operations folks will spend a lot of time fighting fires, troubleshooting ringback or call transfer problems the new Avayastar 15000 with 1.5.7 (beta) software, AFTER the customer's live service has been cut-over to the new platform. It's a painful situation. mark r lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013 On Sep 16, 2009, at 2:52 PM, <Guy.Ram at t-systems.com> <Guy.Ram at t-systems.com
wrote:
Trying to develop an Enterprise SIP trunking concept that allows us the flexibility to interconnect with the major PBX vendors on one side and SIP trunking providers on the other side. Looking at ACMEPACKET as the Integrator SBC box for this concept. One thought was to ask the PBX vendors and Service Provider if they have adopted the SIP Connect 1.1 standard? I'm not a voice expert so would really appreciate any comments and /or suggestions on what we need to be weary of from each party as we develop this concept, especially with regard to regulatory obligations.
Thanks, -guy
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Here here! You've got to test everything that you want to support. Twice. On Wed, Sep 16, 2009 at 12:40 PM, Mark R Lindsey <lindsey at e-c-group.com>wrote:
SIPConnect has a lot of good ideas and rules. It describes "well behaved" SIP trunking behavior.
But, unfortunately, they've moved beyond the generally-accepted Best Current Practices. For example, they now *require* service provider (SP) support for encrypted VoIP signaling. SIPConnect also requires parent/child registration; i.e., "trunk group" registration. Some platforms can now support that, and it's a great feature. But other good platforms don't support it (yet).
So SIPConnect is a good piece of work, but if you get too locked in to supporting SIPConnect, you can waste money implementing requirements, and may ultimately ruin the business plan (by raising your fixed costs too high) or design an un-implementable network.
But in general, the biggest danger is in pretending you can support too much. Start with a *small* set of certified, supported SIP PBX/IAD devices, and then promise success only with systems and software versions on your list. In addition, list the specific features that are supported for those devices.
If you allow customers to believe you support any self-described SIP-trunking-capable system out there, you'll fail. The operations folks will spend a lot of time fighting fires, troubleshooting ringback or call transfer problems the new Avayastar 15000 with 1.5.7 (beta) software, AFTER the customer's live service has been cut-over to the new platform. It's a painful situation.
mark r lindsey at e-c-group.com http://e-c-group.com/~lindsey<http://e-c-group.com/%7Elindsey>+12293160013
On Sep 16, 2009, at 2:52 PM, <Guy.Ram at t-systems.com> < Guy.Ram at t-systems.com> wrote:
Trying to develop an Enterprise SIP trunking concept that allows us the
flexibility to interconnect with the major PBX vendors on one side and SIP trunking providers on the other side. Looking at ACMEPACKET as the Integrator SBC box for this concept. One thought was to ask the PBX vendors and Service Provider if they have adopted the SIP Connect 1.1 standard? I'm not a voice expert so would really appreciate any comments and /or suggestions on what we need to be weary of from each party as we develop this concept, especially with regard to regulatory obligations.
Thanks, -guy
_______________________________________________ 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 Wed, 16 Sep 2009, Mark R Lindsey wrote:
SIPConnect has a lot of good ideas and rules. It describes "well behaved" SIP trunking behavior.
But, unfortunately, they've moved beyond the generally-accepted Best Current Practices. For example, they now *require* service provider (SP) support for encrypted VoIP signaling. SIPConnect also requires parent/child registration; i.e., "trunk group" registration. Some platforms can now support that, and it's a great feature. But other good platforms don't support it (yet).
Can BroadWorks, support registration in broadworks to broadworks SIP trunking?
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
If it does, I think if you do this too many times the world might explode. I'm trying to think of the real answer. Broadworks (R14 or newer) is pretty flexible for setting up different device types, but I haven't spent much time on the gateway side of that. -Scott -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan Stratton Sent: Wednesday, September 16, 2009 4:48 PM To: Mark R Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] What to look for in a SIP Trunking concept? On Wed, 16 Sep 2009, Mark R Lindsey wrote:
SIPConnect has a lot of good ideas and rules. It describes "well behaved" SIP trunking behavior.
But, unfortunately, they've moved beyond the generally-accepted Best Current Practices. For example, they now *require* service provider (SP) support for encrypted VoIP signaling. SIPConnect also requires parent/child registration; i.e., "trunk group" registration. Some platforms can now support that, and
it's a great feature. But other good platforms don't support it (yet).
Can BroadWorks, support registration in broadworks to broadworks SIP trunking?
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Wed, 16 Sep 2009, Scott Berkman wrote:
If it does, I think if you do this too many times the world might explode.
Do you know how to set this up? I can't find anyone at BroadSoft who can tell me how BroadWorks can send a register. It looks like it only allows things to register to it. -Nathan
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan Stratton Sent: Wednesday, September 16, 2009 4:48 PM To: Mark R Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] What to look for in a SIP Trunking concept?
Can BroadWorks, support registration in broadworks to broadworks SIP trunking?
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
If there is an SBC in between could you not configure a surrogate registration? Come to think of it I don't know if any carrier-class softswitches that support outbound registrations. On Thu, 2009-09-17 at 15:12 -0500, Nathan Stratton wrote:
On Wed, 16 Sep 2009, Scott Berkman wrote:
If it does, I think if you do this too many times the world might explode.
Do you know how to set this up? I can't find anyone at BroadSoft who can tell me how BroadWorks can send a register. It looks like it only allows things to register to it.
-Nathan
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan Stratton Sent: Wednesday, September 16, 2009 4:48 PM To: Mark R Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] What to look for in a SIP Trunking concept?
Can BroadWorks, support registration in broadworks to broadworks SIP trunking?
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.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
I don't believe BroadSoft will perform this. I assume you are attempting to have one BroadSoft platform provide a Trunk as a Network Element to another BroadSoft platform. You may be able to use the SBC that you have between the platforms to perform surrogate registration and/or authentication for you. We have a customer with BroadSoft hooked up to a Trunk from our BroadSoft. We did it via Static connections between our Access SBC and their edge SBC as their edge device was not capable of performing surrogate registration and per-call authentication. We needed to mangle a few things on the SBCs to ensure that scenarios involving Diversions within their platform created valid messaging to our platform. I don't think BroadSoft have a BroadSoft Interop report performed against a BroadSoft. :) Cheers, Peter On 18/09/2009, at 5:42 AM, Nathan Stratton wrote:
On Wed, 16 Sep 2009, Scott Berkman wrote:
If it does, I think if you do this too many times the world might explode.
Do you know how to set this up? I can't find anyone at BroadSoft who can tell me how BroadWorks can send a register. It looks like it only allows things to register to it.
-Nathan
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org ] On Behalf Of Nathan Stratton Sent: Wednesday, September 16, 2009 4:48 PM To: Mark R Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] What to look for in a SIP Trunking concept?
Can BroadWorks, support registration in broadworks to broadworks SIP trunking?
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.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 Sep 16, 2009, at 4:47 PM, Nathan Stratton wrote:
On Wed, 16 Sep 2009, Mark R Lindsey wrote:
SIPConnect also requires parent/child registration; i.e., "trunk group" registration. Some platforms can now support that, and it's a great feature. But other good platforms don't support it (yet).
Can BroadWorks, support registration in broadworks to broadworks SIP trunking?
Yes. And using it can be a huge help to your SBC signaling load, as well. mark r lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013
participants (7)
-
anorexicpoodle＠gmail.com -
Guy.Ram＠t-systems.com -
lindsey＠e-c-group.com -
lunchhound9999＠gmail.com -
nathan＠robotics.net -
pchilds＠internode.com.au -
scott＠sberkman.net