locked
Speech Server, SIP Trunking, and ITSP RRS feed

  • Question

  •  

    I had a customer a while back that was writing a disaster response application and he asked if there was an alternative to leasing a set number of phone lines for this speech server application which would sit and wait for a disaster for the phone lines to be used.  They wanted to have enough phone lines to handle the spike that would normally happen (lets say maybe a spike of 50 to 75 concurrent calls, some inbound and some outbound) when a disaster occurs but then that using would go down to zero until the next disaster.

     

    Ideally, what they wanted was a provider that they could point Speech Server at (make the provider a SIP peer) and let the provider take care of see that they got the level of service they paid for (let say it was an SLA of 75 phone lines).

     

    Then I heard about SIP trunking and ITSP and that sounded a lot like what they were looking for.  Am I on track in my thinking?  Can this guy use the ITSP in the way I described above?  Would it be cheeper than leasing all those lines?

     

    I realize there are issues related to reliability of this approach since it is going over the internet and I would expect it would be TLS for security but if they had a dedicated Internet connection to the ITSP (they could even make this redundent) it sounds as if it would be reliable enough.

     

    If this is possible, would every ITSP provide this type of service?

     

    Tuesday, November 13, 2007 2:47 AM

All replies

  • The problem you might run in to with this approach is that sip terminators tend to demand a certain amount of usage per port allocated, or they cut your number of available ports.  I have had to deal with this issue because my application tends to "spike" instead of evenly distributing calls over time.  Gafachi has been very strict with their policy.  If I don't maintain a certain number of minutes per port they cut me down and I end up getting busy's if I got over the limit.

     

    iCall has not complained about usage like this, and their rates are good, but I think their call quality is not quite as good. 

     

    Not to mention the fact that sip terminators usually do not communicate over TCP, which MSS requires, and also do not implement REFER for supervised transfers.

     

    Some companies, like XO, won't even let you sign up for an account unless you can promise significant volume (somewhere in the neighborhood of a million minutes per month).

     

     

     

    Wednesday, November 14, 2007 5:17 PM
  • Eric,

     

    Thanks for the reply.  You mentioned that some sip terminators don't do TCP, is your app a speech app?  What sip terminiators are you aware of that would be able to support speech apps?

     

    Also, if I created a scheduled job that's goal was to send "fake" traffic across the terminator to keep the stats up so you could have enough ports to handle a spike.  Would that work?  What that increase the cost charged by the terminiator?

     

    thanks

    Russ

    Monday, November 19, 2007 3:55 PM
  • Yes, it's a speech app.  We do interactive outbound customer service calls.

     

    There are several sip terminators out there.  We have integrated with Gafachi, iCall and Bandwidth.com.  XO communications is another.

     

    With the exception of iCall they all only do sip over UDP.  The last time I checked none of them handle REFER correctly, which is needed for supervised transfers.

     

    I ended up writing my own B2BUA (a sip proxy that bridges audio) to handle the UDP-TCP conversion and do transfers.

     

    I'm not sure how you would send fake traffic.  You need to be connecting real calls and transmitting audio to trigger billing and volume quotas, as far as I know.

     

    I think for your application, the hardware route is probably more appropriate.  The added expense pays for more reliability, and you don't have to worry about the terminators flaking out on you.

    Monday, November 19, 2007 4:04 PM
  • I'm not sure where the emergencies will occur but you need to consider their location. If the intent is for the applications to respond to local emergencies you need to make sure that you will have local connectivity.

     

    As a member of ARES (http://www.arrl.org/FandES/field/pscm/sec1-ch1.html) I can tell you that local Internet and phone services are one of the first things to go in a major emergency. There are no easy solutions to this but there are some ways around this. I just wanted you to consider and discuss this with the client and the provider that you choose.

     

    Tuesday, November 20, 2007 8:06 PM