May 2010

You are currently browsing the monthly archive for May 2010.

Transfer functionality was added to sipsorcery at the start of the year. I’ve also previously blogged about using blind transfers with Tropo and other similar SIP application services using a roundabout HTTP mechanism. Now for the first time I’m able to post about one advanced SIP application service that supports blind transfers the way it should be done; using SIP REFER requests.

The service is Anveo and even though at the time of writing they are the newest SIP application service to arrive on the scene their offering is extremely polished and at least as far as my own testing over the last week very robust. The really neat feature and key innovation that Anveo has come up with is their graphical tool for building voice call flows, possibly the term IVR could be used but IVR’s are typically associated with “press 1 for sales, 2 for support…” and Anveo’s tool lets you build solutions way beyond that. The only other tool I know of that’s comparable to Anveo’s Call Flow Builder is Voxeo’s Prophecy Designer. I must admit I haven’t played around much with the Prophecy Designer as I have with Voxeo’s other offering, Tropo, but from what I have seen of it it’s much more geared towards building a traditional IVR and collecting input from callers using speech recognition grammars and DTMF. Anveo’s solution on the other hand seems more designed to do as its name suggests and build a call flow that provides a more diverse range of ways to process the call rather than just collecting input. In a lot of cases, traditional IVR’s for example, collecting input is exactly what’s required and I have no doubt Voxeo’s platform are one of if not the best in that regard.

Back to the blind transfer story. As pointed out in the blind transfers with Tropo post the desire to use blind transfers stems from not wanting to stay in complete control of the media path of the call irrespective of whether it’s for cost, quality, reliability or some other concern. It’s a powerful concept to be able to receive a call, send it off to a server somewhere to do some processing and then take the call back and perhaps send it off to a different server with different features somewhere else before eventually forwarding it to its final destination. That sort of scenario is not very easy to accomplish with most VoIP providers where they will allocate an incoming DID and if they do allow it to be forwarded to a SIP URI very rarely provide any facility to transfer the call to a different SIP URI. A simple example would be a DID provider receiving an incoming call that gets sent to an IVR provider which asks who the caller would like to speak to, once the caller has provided their choice the call goes back to the DID provider who forwards it directly to a SIP client or if the the person required is busy the call gets forwarded to a voicemail provider who takes a message and transcribes and delivers it via email. Nothing particularly fancy there except that the call involved 3 different providers, trying to accomplish that in the real World would be a challenge. However if each of the providers supported transfers, which really are a fairly fundamental concept, it would be simple. The problem is most providers don’t support transfers and if they do it’s normally an attended transfer meaning they always want to keep the call on their system, usually so they can keep charging you by the minute for simply bridging the media. Enough of that and back to Anveo who are a provider that will allow you to take your call back without having to resort to any HTTP or other trickery.

Below is the very rudimentary call flow I built in Anveo. I copied one of the existing flows and then after seeing how it worked was able to delete the unwanted items and add it the ones I wanted to test in no time. So far I’ve had to spend no time at all fighting with the interface which is a testament to a good design. The flow works by answering the call, playing some arbitrary message using the Robotalk control, then prompting the user to enter an extension and then based on that extension the call is either forwarded to a SIP URI, sent to voicemail or a blind transfer is initiated.

Anveo Call Flow Builder with SIP transfer control

Forwarding to a SIP URI is what this post is about avoiding since it introduces all the shortcomings outlined in the paragraph above. However sometimes forwarding to a SIP URI is what’s required and it’s certainly good to have the control available. However the really cool control is the transfer control.

SIP transfer control configuration

This control will send an in dialogue REFER request back to the server. The sipsorcery server can then decide that the call leg to Anveo is finished and that the call should now be sent off somewhere else. The key point is that the incoming call leg between a SIP client and sipsorcery can stay oblivious to this and therefore doesn’t need to be configured to handle the transfer. The SIP clients I have played around with usually have quirks with processing transfers, for example when my Cisco 7960 phone gets a REFER request it will place a call to the URI specified in the Refer-To header as expected but if the REFER request is for line 2 on the phone it will always place the call on line 1 which is a problem as line 1 and line 2 are connected to different servers. That sort of issue can be avoided by having the sipsorcery server handle the REFER processing and all that the client will get is a re-INVITE request to inform it where it should switch its RTP to.

If you’re thinking about playing around with blind transfers you need to read the next paragraph.

Like any good saga there is a dark side to blind transfers and that’s undoubtedly got a lot to do with why there is so little support for them amongst commercial SIP providers, well that and the fact that Asterisk, the software of choice for a lot of providers, is too poorly designed to be able to correctly generate CDRs for transfers despite literally years of attempts but I digress. Back to the dangers of blind transfers, consider that I could be sitting at my desk minding my own business when I receive a SIP call over the internet that shows up on my phone as a friendly name. I answer the call and the next thing I hear is one ring and then a sultry voice informs me I’ve called the XXX hotline and am being billed $10/minute. What happened? The person or machine calling me waited until I answered and then immediately sent a REFER request with a Refer-To header containing the XXX hotline number. My phone obediently processed the REFER request and dialled the number through my VoIP provider. My VoIP provider would not see anything different about the call so happily connected it. Before I knew it I’d been pinged for a call that I didn’t want or authorise. It’s worth noting that the same problem applies to SIP 3xx redirect responses which incidentally are another thing that VoIP providers tend to block and is why the “forward when busy” of “forward all” type buttons on IP phones often don’t have the desired outcome.

As a consequence of the danger blind transfers pose sipsorcery does not accept them by default. If the sipsorcery receives a REFER request and the call leg that created the call did not have an explicit option to allow transfers then it will be rejected.

Anveo REFER request being blocked.

To allow transfers and have them passed through to the SIP device at the other end of the call use the dial string [tr=p] option as shown below. Note that while using the pass thru transfer mode is safe enough with Anveo since the call flow control specifies the transfer destination extra caution is needed when using this transfer mode where the other end of the call is untrusted, see the paragraph above about the dark side of blind transfers.


Anveo REFER request being passed through to calling SIP device

To process the blind transfer on the sipsorcery server a dial string option of [tr=c] should be used AND a new dialplan called transfer must be created. The transfer dial plan is where the Refer-To header will be sent for processing. It’s essentially the same as any other sipsorcery dialplan but the key thing to be aware of to be extra careful what destinations are allowed.


The transfer dialplan:

sys.Log("blind transfer starting...")
case req.URI.User
  when /^hold$/ then sys.Dial("")
  else sys.Dial("#{req.URI.User}@local")

Anveo REFER request processed on sipsorcery server.

To summarise the new SIP Transfer call flow control from Anveo opens up some very powerful and flexible calling scenarios for sipsorcery users but it’s absolutely essential to have a good understanding of how blind transfers work and the risks involved before rushing headlong into it. Being able to use the Anveo control is all about providing extra choices when it comes to building a voice application. At the time of writing it costs $0.08 to use the control which compares with $0.03 per minute to have a call bridged on Tropo or Cloudvox. Arguably if it’s likely to be a short call and all else is equal it may be better not to transfer the call and avoid the $0.08 but if the caller is likely to be put on hold for 5 minutes waiting for an agent then it’s a saving to do the transfer. Extra choices can only be good.

While Tropo is probably still a more powerful all round tool it’s really only suitable for programmers. Anveo’s Call Flow Builder attempts to cross the chasm to non-programmers and let them quickly build voice applicationsp; in a way it reminds me somewhat of what Frontpage did for building web sites by removing the need for people to know HTML.

Special thanks and kudos to Denis Chukhryaev, the founder of Anveo, for both agreeing to come up with a blind transfer control and churning it out in less than a week! I’ve been very impressed with the Anveo Call Flow Builder so far and fully expect to see it take off and become a big success.

A new dedicated server has now been purchased and is ready to take over the sipsorcery service from the flakey Amazon EC2 server instances. The sipsorcery DNS records will be updated in approx 8 hours at 24 May 2010 00:00 UTC. There should be minimal disruption unless anyone has hard coded in an IP address of one of the existing servers.

The new sipsorcery deployment consists of a single dedicated server and the IP address is

Even though the new deployment is going back to a single server deployment I do anticipate that it will be significantly more reliable than the existing dual Amazon EC2 virtual server deployment. As discussed in numerous previous posts the EC2 virtual Windows instances are particularly flakey and on average fail 2 to 3 times per week. Before moving to Amazon’s EC2 the precursor to sipsorcery, the mysipswitch service, was hosted on a single dedicated server which did not suffer a single operating system failure in well over a year.

In the event that there is a failure the sipsorcery service can be installed and configured from a new Windows server in approximately 30 minutes. The new hosting provider has a 100% service level agreement on hardware and network and grants 100 minutes of credit for every 1 minute of downtime. That doesn’t mean failures won’t happen but it means they are going to be doing everything they can to avoid any outages and should the sipsorcery dedicated server fail it will be repaired or an alternative server will be provided very quickly.

The sipsorcery web site has been moved to a new host and DNS updated. The old site which is hosted on the Windows Azure cloud is still running but I will be shutting it down in a day or two once the DNS entry has had time to fully propagate. In addition the sipsorcery Silverlight client has been updated to Silverlight version 4 which means unless you’ve already updated the Silverlight plugin you will get prompted to do so next time you visit the sipsorcery web site. The update should be completely painless and take less than a minute.

These two changes are not related to yesterday’s IP address dramas or the future move to a new host for the sipsorcery SIP servers. They are related to some work I have been doing on a new product for sipsorcery and also the relatively high running costs of Windows Azure.

Apart from the Silverlight update there should be no impact to people from these two changes.

Update: The issue with the new account confirmations page failing has now been fixed.

Update: After allocating the new IP addresses I could not get the server on to consistently acquire a database connection. I tried rebooting it several times, swapping the IP address to the alternative server, waiting for over an hour but all to no avail. In the end I ditched the IP address and allocated a new one which is so far working fine. Just another quirk of EC2 I guess. The IP addresses for sip1 and sip2 shown below have changed from what was originally posted.

Thirty minutes ago I attempted the straight forward operation of swapping the IP addresses on sip1 and sip2 so as to do an operating system and software upgrade on sip1 (sip1 is by far the busier of the two servers). Unfortunately I clicked the “Release IP address” button instead of the “Disassociate IP address” button in the ElasticFox tool and I lost the two static IP addresses that the sip1 and sip2 servers were using. I was instictively staying away from the button with the big red X on it but in this case that was the correct button. The consequence of the malfunction by me is that the IP addresses of sip1 and sip2 will now be different. I’ve updated DNS and the since the A and SRV records were all set with timeouts of 1 hour they should have already started to propagate. At 1000, about half the normal number, device registrations are back and calls are going through.

The new IP addresses for anyone that needs to hard code them into their ATA or provider settings are: and both resolve to sip1.


Many thanks to the nearly 50 people who donated what they could towards the proposed new hosting trial. The amount rasied was USD $825 which unfortunately didn’t quite get to the amount of USD $1169.89 needed for the first month’s installment so it won’t be possible to proceed with the original proposal in full.

Since the donations started another development has meant that the current sipsorcery hosting arrangements need to be halted at the end of this month. Consequently it’s now my intention to use the donations to purchase a single dedicated server with an alternative host and run the sipsorcery service from it. The donations total should cover the set up cost and the first two months and if a little more trickles in even the first three months. I am working on a plan to move the service to a self sustaining footing but for at least the next few months the donations will be critical.

The plan would be to over time incorporate the F5 load balancing and second server into the hosting arrangements, as funding permits, and enhance the the service and hopefully get to the magical five nines reliability. For the interim I’m confident that running the service from a single dedicated server will actually be a substantial improvement on the current situation from the current Amazon virtual servers which are now at a point where they are going down so often I’ve given up even keeping a log of them.

This new arrangement is a deviation from the original proposal for donations so if anyone would like a refund please email me at and I will be happy to oblige. I would ask that refund requests are made within the next week by Sunday the 23rd of May otherwise the money will have been committed.