Here here!<br><br>You've got to test everything that you want to support. <br><br>Twice.<br><br><br><br><div class="gmail_quote">On Wed, Sep 16, 2009 at 12:40 PM, Mark R Lindsey <span dir="ltr"><<a href="mailto:lindsey@e-c-group.com">lindsey@e-c-group.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">SIPConnect has a lot of good ideas and rules. It describes "well behaved" SIP trunking behavior.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
mark r <a href="mailto:lindsey@e-c-group.com" target="_blank">lindsey@e-c-group.com</a> <a href="http://e-c-group.com/%7Elindsey" target="_blank">http://e-c-group.com/~lindsey</a> +12293160013<div><div></div><div class="h5">
<br>
<br>
<br>
<br>
On Sep 16, 2009, at 2:52 PM, <<a href="mailto:Guy.Ram@t-systems.com" target="_blank">Guy.Ram@t-systems.com</a>> <<a href="mailto:Guy.Ram@t-systems.com" target="_blank">Guy.Ram@t-systems.com</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
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.<br>
<br>
Thanks,<br>
-guy<br>
<br></div></div>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote></div><br>