[VoiceOps] What to look for in a SIP Trunking concept?

[Mark R Lindsey]

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