sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
I’ve created a short guide on how SIP manages audio streams and the sorts of things that go wrong when those streams traverse NATs. The full guide can be read at SIP and Audio Guide.
To complement the guide I’ve whipped together a diagnostics tool.
SIPSorcery RTP Diagnostics Tool
In an attempt to help people diagnose RTP audio issues I have created a new tool that provides some simple diagnostic messages about receiving and transmitting RTP packets from a SIP device. The purpose of the tool is twofold:
To use the tool take the following steps:
The tool is very rudimentary at this point but if it proves useful I will be likely to expend more effort to polish and enhance it. If you do have any feedback or feature requests please do send me an email at aaron@sipsorcery.com.
The Simple Wizard is the new way to create SIP Sorcery dial plans. It’s designed for people with fairly straight forward call handling requirements with one or two steps per call.
This post is an overview of how to get started with the Simple Wizard and includes a guide for the some common steps that are likely to be undertaken with it.
Step 1: Create a new Simple Wizard dial plan
The dial plan option is only available in the Silverlight portal. Once logged in select the dial plans menu option and then the Add button. A dialogue box will appear with the different dial plan options available. Select Simple Wizard, choose a name and then click Add.
Create a new Simple Wizard dial plan
Once the dial plan is created the Simple Wizard screen will appear and you are ready for step 2.
New Simple Wizard dial plan ready for rule creation
Step 2: Create speed dials for outgoing calls
A common requirement for outgoing call rules is to create some speed dials for frequently called destinations. The Simple Wizard allows any format desired for speed dials but a common way to create them is to use a * prefix, for example *100, *101 etc. For this example we will create 4 speed dials for calling family member’s mobile numbers.
The screenshot below illustrates the creation of the first speed dial. The crucial point is to leave the Destination Match type as Exact. An exact match is as the name suggests one that matches the called number exactly without applying any substitutions, wild cards etc.
Create a new speed dial
Once all the speed dials have been entered they will be displayed in the outgoing rules grid and are immediately ready for use (remember to update the Outgoing Dial Plan on the SIP account you want to use with the dial plan).
Outgoing rules grid with speed dials
Step 3: Create outgoing call rules for international routing
Once your speed dials are set up the next thing is to create some rules for processing calls to the traditional telephone network or PSTN. For PSTN calls it’s common to use different providers for calls to different international destinations. For this example we will set up rules for 3 international prefixes.
The difference between setting up the international calling rules and the speed dial rules is that the Destination Match type used is now Prefix. Again as the name suggest a prefix match is only concerned about the start of the dialled number. Prefix matches can also use pattern substitution to represent commonly required number patterns.
New rule for international calls to Ireland
Once all the international rules are entered they to will appear in the outgoing rules grid and are available for immediate use.
International rules grid view
Step 4: More sophisticated outgoing call rules
The exact and prefix match rules and the default Dial command used in the above examples are just the start when it comes to creating outgoing call rules. More powerful matches can be created using the Regex destination match type, it allows full regular expressions to be utilised.
The DialAdvanced command also allows multiple stage forwards and different options to be set on the forward(s) used to process the outgoing call. The DialAdvanced command can use the same powerful dial string options that are used in the Ruby dial plans.
Step 5: Incoming rules
After the outgoing rules are successfully configured the next step is to take a look at the incoming rules. It’s not actually necessary to use a dial plan for incoming call processing with SIP Sorcery. By default all incoming calls will be forwarded to all registered bindings on the main SIP account. However if different behaviour is required such as forwarding an incoming call on one provider to a different provider or to multiple SIP devices then an incoming dial plan is required.
For this example we’ll set up two incoming dial plan rules.
Currently an extra step is required to be able to distinguish calls by provider.
Once the providers are correctly configured then to distinguish them in a Simple Wizard dial plan is as simple as selecting the corresponding SIP account in the drop down menu.
Incoming rule for calls to provider1
Once the rules have been created they will be displayed in the incoming rules grid and are available for immediate use.
Incoming rules grid
Step 6: Forward unanswered incoming calls to voicemail
The final step is to forward any unanswered incoming calls to voicemail. To achieve this it is as easy as creating a new incoming call rule that applies to Any SIP account rather than to a specific one as the rules in the last step did.
Since the SIP Sorcery service does not provide a voicemail service anyone wanting to use one will need to create an account with a 3rd party SIP provider. The instructions on how to set up a free voicemail account with Callcentric can be found in a SIP Sorcery Recipe.
Once you have a voicemail account set up the incoming call rule will be something like the one below.
Incoming voicemail rule
As with outgoing rules there are many more things that can be done with incoming call rules such as setting a time window that they should apply and filtering based on the caller ID.
There’s been a bit of buzz around the VoIP ecosystem lately with the news that Voxalot are closing down their service from the 31 Dec 2011. I’ve put together a guide for all Voxalot users considering SIPSorcery as a replacement service. I’d strongly encourage any existing Voxalot users to check the guide out and here at SIPSorcery we are hungry for your business.
One feature of SIPSorcery that some Voxalot and other users have mentioned as being a problem is the need to construct dial plans in Ruby script. To those of us that have a programming bent the ability to use Ruby scripts allows the creation of almost infinitely powerful and flexible dial plans but understandably for those without a programming bent that just want a few speed dials or custom rules it can all be a bit daunting. Voxalot provides a much more limited way to express dial plans but also a simpler way at least up until now.
I’ve been working for a while on new dial plan wizards for SIPSorcery and the latest one which I’ve baptised the “Simple Wizard” is my attempt to combine the power of the SIPSorcery Ruby dial plans with a much simpler wizard like interface. The new wizard is in the final stages of development and I hope to release it later this month but given that Voxalot users are currently weighing up their options I thought I’d give a preview. In the sections below I’ve included a screenshot of the Voxalot way of doing things and compared it to the SIPSorcery Simple Wizard way of doing things.
Add Speed Dial
List Speed Dials
Add Smart Dial Rule
List Smart Dial Rules
As well as being able to use the Simple Wizard to construct dial plans for outgoing calls it will also be possible to construct incoming dial plan rules. For incoming rules the pattern gets applied to the From header. The incoming rules can be applied to an individual SIPSorcery SIP account or all SIP accounts.
There is a lot more detail to come with the Simple Wizard but for Voxalot users considering their options I’m confident that it will make building SIPSorcery dial plans simpler and more flexible than the various Voxalot screens.
Recently I had a request from a user on how to get redirect processing working with their SIPSorcery dial plan. Redirects are when the destination of a call responds with a specific type of response, appropriately called a redirect response, that indicates that the called destination is unavailable and that the caller should instead try and call an alternative destination. The alternative destination is specified in one of the SIP headers on the redirect response. The most common scenario for redirects is the do not disturb (DND) or call forward buttons on IP phones. IP phones typically allow a user to press the DND button, enter a call forwarding destination and then have the phone redirect all that calls to that destination.
Redirect responses are potentially very dangerous if appropriate precautions are not taken. The reason being that the alternative destination specified in the response could be anything including a premium rate number in some far away country. For that reason redirects are disabled by default within SIPSorcery dial plans and it is only if they are explicitly enabled using a dial string option that they will be acted on.
After a redirect response is accepted the next question is how to process it? A well as blocking undesirable numbers the alternative destination could be a safe PSTN number and the caller will want to make a decision about which of their providers to use for the call. This presented a bit of a quandary for a while as a dial plan would potentially need to contain the same call processing logic in multiple locations, once in the main dial plan and then everywhere a redirect response was being accepted. The solution to that problem was to allow a new second instance of a dial plan to be executed for a redirect response. However while that approach provided for the most flexibility it was also a bit complicated so a simpler approach that did allow the redirect response to be processed within the same dial plan instance was also implemented. The two different approaches are outlined below.
Approach 1 – Inline redirect processing
This is the simplest of the two approaches and allows redirect responses to be processed inline within the currently executing dial plan. It also does not require a redirect option to be set in a dial string since specific dial plan logic is required to employ it. An example of this approach is shown below.
if sys.Dial("myaccount@sipsorcery").to_s == "Redirect" then
sys.Log("Redirect was requested to #{sys.RedirectURI.ToString()}.")
sys.Dial("#{sys.RedirectURI.User}@someprovider")
end
In the example the key point is that the sys.Dial method will return a result of “Redirect” if one of the call legs within it receives a redirect response. At the same time the alternative destination will be set in sys.RedirectURI (which is a SIP URI object the same as req.URI).
Approach 2 – New dial plan instance redirect processing
The second approach causes a new instance of the current dial plan to be executed for the redirect destination. Some additional variables are set in the new dial plan execution which are sys.Redirect, sys.RedirectURI and sys.RedirectResponse. The sys.Redirect property is a boolean that gets set to true for a dial plan instance initiated by a redirect, sys.RedirectURI property holds the alternative destination set in the redirect response and sys.RedirectResponse holds the full response.
if sys.Out
sys.Log("Out call")
sys.Dial("someuser@local[rm=n]")
elsif sys.Redirect
sys.Log("Redirect call")
case sys.RedirectURI.User
when / ^ 300$ / then sys.Dial("#{sys.RedirectURI.User}@someprovider")
else sys.Log("Sorry, redirect destination not permitted")
end
else
sys.Log("In call")
end
In the example above the dial plan has separate logic for In, Out and Redirect calls. The rm=n dial string option translates as redirect mode should be processed with a new dial plan.
I had a query today about programmatic access to SIPSorcery CDRs. In fact access has been available for a couple of years via the provisioning service. I have posted some previous samples about accessing the provisioning web service but not a specific one using Ruby and SIPSorcery CDRs so here it is.
require 'httpclient'
puts "sipsorcery get CDRs sample"
provisioningURL = "https://www.sipsorcery.com/provisioning.svc/rest/"
myUsername = "yourusername"
myPassword = "yourpassword"
client = HTTPClient.new
client.ssl_config.set_trust_ca('ca.pem')
resp = client.get_content("#{provisioningURL}customer/login?username=#{myUsername}&password=#{myPassword}")
authID = resp.delete('"')
puts "authID=#{authID}"
resp = client.get_content("#{provisioningURL}getcdrscount", nil, "authID" => authID)
puts "get CDRs count response=#{resp}"
resp = client.get_content("#{provisioningURL}getcdrs?offset=0&count=3", nil, "authID" => authID)
puts "get CDRs response=#{resp}"
client.get_content("#{provisioningURL}customer/logout", nil, "authID" => authID)
puts "finished"
For the sample to work you will need to download the certificate authority for the SSL certificate used on the SIPSorcery site and copy it into the same directory you run the Ruby script from. The certificate authority file is needed because openssl, which Ruby uses, doesn’t recognise the signing authority as valid even though in my case I had the whole certificate authority chain installed in my trusted certificates store. If anyone knows a way to get openssl to recognise the www.sipsorcery.com SSL certificate without having to resort to using ssl_config.set_trust_ca option I’d be very interested to know.
I’ve just added a new dial plan option to the SIP Sorcery Silverlight client. The dial plan option is another non-script wizard type and in this case the idea has been to make it as simple as absolutely possible, hence the name.
The Simple Wizard dial plan allows a set of rules to be specified to be applied to outgoing calls, incoming call rules will follow in the future. The creation of the rules should be straight forward for anyone familiar with SIP Sorcery dial strings. In the simplest case a dial string can just be the name of a provider. There is some help information for the Simple Wizard at Simple Wizard Help.
Simple Dial Plan Wizard Screenshot
Mike Telis (aka Magician Mike – in keeping with the sorcery theme) whipped up a Tropo ruby script to act as a call announcement handler to work in conjunction with an incoming call to sipsorcery. Since sipsorcery does not do any media handling at all it’s necessary to use a different platform such as Tropo to do things like call announcement. Mike originally sent me the script in Jun 2010 after which I duly forgot to post about it until a recent subtle reminder.
The way the call announcement works is that a new call arrives at sipsorcery and is forwarded directly to a Tropo application that is configured with the call announcement ruby script. Straight forward so far. Now it gets a little bit tricky. The call announcement script initiates a call from Tropo back to a configurable sipsorcery account. When the call from Tropo back to sipsorcery is answered an announcement is played which informs the callee that there is a pending call for them and they can press 1 to accept or 2 to reject. Hopefully you’re still with me. If the callee presses 2 the original call gets rejected and the caller will hear an engaged tone or whatever their phone or provider does for a rejection. If the callee presses 1 then some magic is done between Tropo and sipsorcery so that the original call leg and the leg between the callee (who just pressed 1) are transferred together and they can chat away. The magic in this case is an attended transfer but since Tropo doesn’t support attended transfers it’s initiated by a HTTP request from Tropo to sipsorcery. I won’t go into the details of that as it all happens under the hood in Mike’s call announcement script.
For anyone feeling brace enough to try it out the steps are:
1. Create a new Tropo application using Mike’s call announcement script which can be found on github. At the top of the script you will need to enter your sipsorcery username, the sipsorcery SIP account you want Tropo to announce the call to and your name to play to callers. You’ll see those parameters clearly labelled,
2. In your sipsorcery configuration forward whichever incoming provider or SIP account you want to get call announcements on to the Tropo application. When you create a Tropo application you’ll see a Phone numbers section under which there is a SIP Voice number which is the one to use.
That should be it. There’s a few things that could go wrong but the great thing about sipsorcery and Tropo is that they both provide a console so you can see exactly what’s going on. If you do get stuck and the console messages don’t make any sense feel free to post on the sipsorcery forums.
It’s been a while, at least 5 years, but I’ve eventually ended up back in the bottomless pit of frustration that is javascript. Actually it’s not that bad these days thanks to jquery although it’s still far from what I’d call pleasurable. It wasn’t an entirely voluntary decision for me, my day job requires me to get down and dirty with a web application and that means javascript and jquery.
Anyway I have whipped up a quick little sample to query the SIP Sorcery provisioning service to retireve a list of SIP accounts using jquery. It might be useful to someone and as with the previous samples if there is any interest I’m happy to flesh out the remainder of the REST interface to make it usable.
<html>
<head>
<title>SIP Sorcery jquery sample</title>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
var PROVISIONING_URL = "https://www.sipsorcery.com/provisioning.svc/rest/";
$(document).ready(function() {
login("yourusername", "yourpassword");
});
function login(user, pass) {
$.get(
PROVISIONING_URL + "customer/login",
{ username: user, password: pass },
function(data){
getSIPAccounts(data);
});
}
function getSIPAccounts(authid) {
$.ajax({
beforeSend: function(req) {
req.setRequestHeader("AuthID", authid);
},
url: PROVISIONING_URL + "sipaccounts?count=3",
dataType: 'json',
success: function(data){
$.each(data, function(index, sipAccount) {
alert("Username: " + sipAccount.SIPUsername);
})
},
error: function(xhr) {
alert ("Oopsie: " + xhr.statusText);
}
});
}
</script>
</head>
<body>
SIP Sorcery jquery test
</body>
</html>
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.
Along with playing around with Tropo to test out VoIP applications where sipsorcery’s signalling only design is insufficient I have also occasionally fired up an Asterisk EC2 instance (thanks to Voxilla for bundling up an Asterisk EC2 AMI to make things easy). Each time I would customise the Asterisk dialplan to test out whatever it was and then take the instance down a few hours later. The great thing about sipsorcery is that it saves me having to configure SIP accounts or providers on the Asterisk system. I’d always thought it would be great if someone else did all the grunt work for me and offered Pay As You Go hosted Asterisk instances and saved me even the small amount of time I spent bringing my own instance up. There are lots of hosting companies out there that will host Asterisk instances but the key for me is the Pay As You Go piece, I might only want to test something out once every three months and I’m not interested in paying a monthly charge.
That’s why I’ve been somewhat interested in Cloudvox’s offering. It’s the first time I’ve seen hosted cheap hosted Asterisk instances. It’s great that they provide free “Hacker” accounts so you can at least make sure it’s not a snake oil product. Above that the cheapest plan is $6/month and calls at $0.06 per minute. Even though I’m not a fan of the monthly charge $6 is pretty cheap and it looks like you can switch back to the Hacker account easily if you know your account is not going to be in use for a while. The $0.06 per minute is not so appealing and it’s still a little bit fuzzy to me whether SIP-to-SIP calls are billable or not, apparently they are but I found that it depends on how they are dialled as to whether they show up on my account as billable or not (note I’m not trying to find ways around the cloudvox billing rather I’m trying to work out if SIP-to-SIP calls are free).
Cloudvox have two APIs for building applications although for some reason they have included SIP+RTP in the HTTP vs AGI comparison which doesn’t really make any sense and must be awfully confusing to developer new to VoIP. The HTTP API is very basic but is the easiest to get up and running with. I found it counterintuitive to begin with but that’s because I was so used to the concept of dialplans, VoiceXML and Asterisk that I was thinking of it as a way of simply loading the Asterisk dialplan whereas the approach is for the Cloudvox Asterisk servers to receive a call, send a HTTP request for a small number of Asterisk commands to a web server somewhere, execute those commands and return the result via another HTTP request, it makes perfect sense to me now. An example of an ideal task for the HTTP API is one the same I mentioned in the Tropo Transfer post about a user dialling into sipsorcery, somehow entering a number and then dialling that number out through one of their providers. The HTTP API would be perfect for getting Asterisk to play a prompt, collect some digits and then return them to sipsorcery via a HTTP request.
The second API revolves around the Asterisk Gateway Interface. Again I got somewhat confused this time by the fact that the emphasis is put on some pre-canned AGI servers like Adhearsion or the Asterisk::AGI Perl module. My confusion arose from thinking I needed to somehow connect to an AGI server Cloudvox had somewhere or that there was some special configuration on Cloudvox’s end that only allowed it to work with specific AGI servers. In the end the situation was again a lot simpler and Cloudvox don’t care what the AGI server is and all the examples and configuration guides are targetted at the common ones on the assumption, most likely correct as well, that most people will use one of them. Once that light bulb went off for me I dusted off my own C# AGI server, written many years ago, and had calls coming into it from the Cloudvox Asterisk servers in no time at all.
I’ve checked the very rudimentary C# AGI code into the sipsorcery code base, I had to strip out all the business logic so it’s really bare bones, it’s called SIPSorcery.Asterisk.FastAGI and is in the sipsorcery-servers directory. I don’t know when the next time I’ll get fired up to do anything else with it but it’s there as a reference should any other C# developers be interested. Generally I get all excited about integrating with new VoIP platforms but once i can play the monkey sounds or equivalent I consider the integration proven until something else crops up.