sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
After a brief interlude (nearly 3 years) I recently got motivated to look at using the SIPSorcery SIP stack to build a video softphone. Of course there are already a number of fully featured video softphones available so the project was for fun rather than to solve any particular problem.
Unlike my previous attempts this time I have been successful and the image below shows the video softphone prototype on a call with CounterPath’s Bria Softphone (that’s me chatting to Max).
I did end up using Microsoft’s Media Foundation (MF) for the getting samples from my web cam but I gave up on trying to use the MF H264 codec and instead used the VP8 codec from the webproject. A motivation to use the VP8 codec is that it was the initial codec proposed for WebRTC and at some point I’d like to experiment with placing calls from the softphone to a browser.
The video softphone is available in at the sipsorcery codeplex repository under the sipsorcery-softphonev2 folder. All the MF and libvpx integration is contained in the sipsorcery-media folder.
The new softphone is purely experimental and video calls do not even work with the only other softphone I tested with, jitsi, due to a VP8 framing problem. But it is a working implementation of a Windows video softphone so may prove useful for anyone who wants to do some work in those areas.
Enjoy.
For some reason after being completely disinterested in doing anything with the RTP and audio side of VoIP calls for the last 5 or so years suddenly in the last month I decided to explore how well a .Net based softphone would work. Consequently I started tinkering around with a .Net library called NAudio that I’d seen mentioned around the traps. For my purposes NAudio provided a convenient way to get at the underlying Windows API calls for interacting with audio input and output devices. It took a little bit of time and effort to get things working but eventually I was able to successfully read audio samples from my microphone and write samples to my speakers through a test .Net application.
The softphone is open source and available in a binary form here and the source is availabe here in the sipsorcery-softphone project. Before going any further it should be noted that the softphone is extremely rudimentary and geared towards developers or VoIP hobbyists wanting to tinker rather than end users looking for trouble free calling. The user interface is extremely lacking and there are also crucial components missing such as echo cancellation, a jitter buffer, codec support (G.711 u-law is the only codec supported) etc.
My original verdict on using .Net as a softphone platform was that it was not particularly good. This was due to the fact that the microphone samples coming from NAudio were only capable of being delivered with a sample period of 200ms which is useless since the in practice the jitter buffer at the remote end will drop any packet over 50 or 100ms. However it turned out that a combination of some inefficient code in my RTP packet parsing and the fact that I was testing by running the softphone in Visual Studio debug mode was responsible for the high sampling latency. Once those issues were removed the microphone samples have been delivered reliably with a sample period of 20ms exactly as required. I was thinking i I ever wanted to have a usable softphone I’d have to move the RTP and audio processing to a C++ library but now I’m starting to believe that’s not necessary and .Net is capable of handling the 20ms sample period.
The other thing worth mentioning about the softphone is that it’s capable of placing calls directly to Google Voice’s XMPP gateway. I’m still surprised that none of the mainstream softphone developers have bothered to add the STUN bindings to their RTP stacks so that they could work with Google Voice. In the end I decided I’d just prototype it myself just for kicks. For a softphone that already has RTP and STUN protocol support adding the ability to work with Google Voice in conjunction with a SIP-to-XMPP gateway (which SIPSorcery coudl do) would literally be less than 20 lines of code.
Hopefully the softphone will be useful to someone. Judging on the number of queries I get about the SIPSorcery softphone project and the questions about .Net softphones on stackoverflow I imagine it will be.
Due to popular request, mainly from Voxalot refugees, a new web callback feature is now available for SIPSorcery Premium and Professional users. The feature is available on the AJAX portal. Unlike the original call manager approach (outline at the bottom of this page) which initiated a Ruby dial plan execution and did not require authentication the new mechanism DOES require authentication and sets up a call between two pre-configured dial strings rather than executing an existing dial plan.
The new mechanism is simpler to use but is not as powerful and flexible as the original approach. Hopefully the new mechanism is closer to what Voxalot refugees are used to and will allow any saved Voxalot callbacks to be used.
There is help available but the mechanism should be fairly intuitive to use. The way it works is that you enter in two dial strings (dial strings are the same format as those that can be used in sys.Dial in Ruby dial plans and can include multiple call legs and other options) and a description. After that it’s just a matter of clicking on “place call” and the SIPSorcery server will attempt to call the first leg and if it gets an answer will then call the second leg and finally bridge the calls together with a SIP re-INVITE.
Enjoy!
A new version of the Simple Wizard is now available. The SIPSorcery Silverlight portal with the new changes is version 4.1.1.554 (the version is displayed in the top left hand corner when the portal is first loaded).
The changes are:
Rule Disabling
The disabling of rules is self-explanatory. Disabling a rule will prevent it from being used when processing a call. Re-enabling the rule will cause it to be used again.
Incoming Rule Matching
The incoming rule matching is now more powerful and flexible. The Any option will match all incoming calls (although caller ID and time matching are subsequently applied and could result in the rule not matching a call). The ToSIPAccount option requires a specific SIP account to be selected and will cause the rule to only match incoming calls to that SIP account. The Regex option allows a regular expression to be applied to the incoming call’s SIP URI (Uniform Resource Identifier, the equivalent of an email address for SIP).
The final option is ToSIPProvider and can be used to match calls that have been received from a specific SIP provider. The way this option works is that the incoming SIP URI must be in a specific format of “provider name.username@sipsorcery.com” for example “blueface.aaron@sipsorcery.com” where blueface is the provider name and aaron is the username of the SIPSorcery account. In order for the SIP URI on received calls to be in the required format it will need to be set on the Register Contact for the provider. An additional update will be coming soon which will set that format as the default on new SIP provider entries but in the meantime it will need to be set manually.
Highrise Lookups
The HighriseLookup command is a new one that will be useful to people who already manage their contacts in a Highrise instance. By setting a Highrise URL and authentication token in the Simple Wizard command parameters the SIPSorcery application server will lookup the contact in the Highrise instance and if found it will set the display name on the SIP From header of subsequent forwarded calls. The command is primarily designed to be used with a new version of the Switchboard that’s coming soon but it may also be useful for anyone with an IP Phone or softphone that has enough screen space to show the display name on incoming calls.
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.
In July I made my first attempt at providing a simple wizard like interface for call processing. The effort was based on the fact that a lot of sipsorcery users find writing Ruby script based dial plans daunting not to mention time consuming. By providing a simple wizard interface the hope was that the portion of users that don’t need sophisticated dial plans would be able to started without having to churn out a line of code.
There wasn’t a big uptake of the simple wizard dial plans so I went back to the drawing board and today I’m announcing the release of the second version of the simple wizard. Conceptually it’s still the same in that you need to write incoming and outgoing rules but the difference is I’ve expanded the data entry section for the rules to make it easier to understand what each field does. In the first version the aim was to condense the data entry for the rules into a single line but I think that just served to confuse matters.
I plan on posting some more howto guides for the simple wizard and this post is really just a taster. There is a help page available that describes what each of the data entry fields are. Below are a couple of screenshots for outgoing and incoming rules respectively. If you’d like to give the simple wizard a spin it’s only available in the Silverlight portal; create a new dial plan and select Simple as the type.
Outgoing rule screen for Simple Wizard
Incoming rule screen for Simple Wizard
As always any feedback about how the Simple Wizard could be improved or whether it’s closer to the mark etc. are appreciated.
During last weekend’s maintenance window (maintenance window because the upgrades are performed in the early hours of Sunday morning; no down time occurs) two new dial plan functions were introduced. The new functions are to do with applying a user’s time zone settings within their dial plan. The functions aren’t particularly sexy but they will make certain operations easier such as determining when calls should be sent to voicemail based on the time of day.
The two new functions are:
For a full description and how the functions can be used please visit the dial plan help page.
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.
One last friendly reminder for SIP Sorcery Beta users that the switch to a Free account service level will be happening within the next 24 hours. For anyone that hasn’t already done so an wants to avoid any disruption to the operation of their account please upgrade to a Premium service.
For anyone unsure the main limitations on a Free account compared to a Beta account are:
The logic that will be applied to determine which dial plans and SIP providers get marked as read only will be:
It will be possible to view and copy information from the read only records as well as delete them but it won’t be possible to update them.
Thank you to all those who have purchased a Premium service to date!
I’ve had a couple of requests from people who made a previous donation to the SIP Sorcery project regarding whether the donation would count towards a payment for a Premium account. The answer is that yes it can. I’m happy to apply a pro-rata basis for all donations towards a Premium account. In fact all types of previous payments including donations and the eBay auctions are treated the same. If you would like to take advantage of this offer please send an email to admin@sipsorcery.com with your sipsorcery username and if your PayPal payment came from a different email address please include it or a copy of the payment receipt.
