sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
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 sipsorcery.com 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.
sys.Dial("d3a0zqwcjl9pzm4ado1nvq@sip.anveo.com:5010[tr=p]")
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.
sys.Dial("3sd3a0zqwcjl9pzm4ado1nvq@sip.anveo.com:5010[tr=c]")
The transfer dialplan:
sys.Log("blind transfer starting...")
case req.URI.User
when /^hold$/ then sys.Dial("music@iptel.org")
else sys.Dial("#{req.URI.User}@local")
end
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 applications; 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.