Posts Tagged ‘sip’

Mac SIP client : Zoiper Configuration guide | My SIP Switch

Friday, December 5th, 2008

Zoiper is nice little softphone that works well on MAC OS (note that they also have Windows and Linux versions). It has been tested with My SIP Switch and is working more than fine.

You can download it for free on http://www.zoiper.com/

It’s quickand easy to set it up and if you don’t have firewall or connection issues you should be able to get started quickly.



Here is a step by step configuration guide.

1) This is the default interface, click on the spanner to open the “Options” window.

Zoiper : no account

2) Select “SIP accounts” and then “Add new SIP account”. You’ll be prompted to enter a name. MySipSwitch in our example, but that can also be your name or something else.

Zoiper : no account

You should see the interface below, to add your My SIP Switch account details.

Zoiper : SIP settings



The domain is : sip.mysipswitch.com (you can also specify the port : sip.mysipswitch.com:5060 but this should be optional)

Then mention your MySIPSwitch username and password.

The Caller ID is your Username, so write it again.

Once you are happy with the settings you specified, press OK at the bottom and you should be ready.

Zoiper : my sipswitch settings


If the line one shows “green” (as below) that indicates a successful registrations. Now you need to take a look at your dial plan and get calling.

Zoiper successfully registered



If you need help regarding the dial plan, you can refer to older post on this blog :

Default Ruby Dial Plan and  Inbound Call Management in Ruby

Do not hesitate to use our forum if needs be.

Pear Skidding

Monday, August 11th, 2008

The last few months have been a bit of a roller-coaster ride for mysipswitch. The ride started on Mar 25th when Ruby dial plans were introduced. Initially the new dial plan format did not gain a lot of traction but then a combination of people wanting to do more complicated things and the default dial plan for new users being set to Ruby saw their use increase considerably.

Around the start of June the roller-coaster, which had been on a nice gentle climb, encountered a little dip, just enough of a dip to cause some worry about what was around the next corner. This corresponded to a few incidents where mysipswitch had 3 outages over the space of three or four weeks. Up until this point outages had been virtually non-existent. 

The outages were tracked down to abnormally high memory usage on the mysipswitch process followed by it becoming unresponsive to registrations and calls. Restarting the process fixed the problem but then the memory usage would start creeping up and reach a dangerous level somewhere between 2 and 7 days later.

Now memory leaks are not uncommon in software and apart from buffer overflows are probably the second biggest software defect. However in the case of mysipswitch it is written in managed C# and runs within a runtime that takes care of memory management making it difficult, but not impossible, for memory leaks to manifest. Initially we thought that we must have introduced a leak within the SIP stack in one of the lists that tracks registrations or calls. However after a couple of weeks of poring over the code and purchasing some profiling tools nothing was discovered and the memory leaks were still occurring.

Our attention was then turned onto the IronRuby assemblies. Straight away we found that if a Ruby dial plan generated an exception then memory utilisation would shoot up by up to 2MB. Some re-jigging of the way the scripts were loaded and executed improved things a lot but there was still a slow leak which meant a restart of the mysipswitch process was needed about twice a week.

Restarting twice a week was not that problematic but it was not ideal either. As such it was decided to get started on another initiative which was to split out the mysipswitch agents into individual processes. That would have the advantage of verifying that the leak was definitely in the process hosting the Ruby scripts and also meaning only it would need to be restarted and the other agents would be able to keep running. The mysipswitch agents are:

  • SIP Proxy/Application Server, this is the process that is the first point of call for all SIP traffic into and out of mysipswitch and handles dial plan processing and Ruby scripts,
  • SIP Registrar, registers user agents and records their contact details for incoming calls,
  • SIP Registration Agent, registers 3rd party SIP accounts with external SIP Providers,
  • Monitor, the telnet shell that allows some rudimentary monitoring of the other mysipswitch agents to add in troubleshooting and diagnostics.

The splitting out of the agents was always going to involve a bit of pain because it involved significant changes to both the code and the mechanisms used. As one example the SIP Proxy could no longer ask the SIP Registrar for a list of bindings for a particular account and instead would have to retrieve them from the database. The splitting out of the agents took two weeks or so and actually probably caused less pain than anticipated.

After a week or so of running with the indiviudal agents the memory leak was able to be verified to be confined to the SIP Proxy process and deemed to be manageable enough there to keep things going as the IronRuby code base continued to evolve (it’s still only on alpha 3 so gremlins have to be expected) and eventually eliminated whatever was causing the memory leak.

So up to this point the rollercoaster had been fairly sedate or at least not bad enough for anyone to lose their lunch. However trouble was just around the corner. Since the agents were all operating smoothly and not having any integration problems it was decided to get back to the feature requests. The most in demand feature was the Callback application. Now the Callback application is a lot trickier than it seems and requires some serious SIP Kung Fu! In theory what the application does should be straight forward enough using transfers (SIP REFER requests) but in the real World most providers don’t support REFER and some clever hacks using things such as raw sockets for IP impersonation are required.

A new version of the Callback application was introduced around last weekend (2nd of August) and in hindisght that’s when things went Pear Shaped and the roller coaster started the stomach churning descent (excuse the metaphors, they make it easier to keep writing dubious quality material). The problem was after the update was introduced strange things started happening with the Registration Agent and the SIP Registrar. Initially there was no obvious link to the happenings and the SIP Proxy but on Friday, after 3 or 4 days of pulling our hair out, the incident was finall observed and the strange happenings occurred at the same time the Proxy utilisation spiked.

After identifying there was a link between the agents it took three more solid days of investigation to indentify and then fix the issue (or at this point it may be better to say “hopefully” fixed the issue).

So after all that we are now hopefully at a point where the rpevious stability of mysipswitch is just around the corner. Despite the last 3 months of intensive effort not a lot has happened in the way of new features which is frustrating on one level but since most of the effort (the last week excepted) has been as a consequence of introducing Ruby dail plans it’s undoubtedly been well worth it.

 Another benefit of the recent work is the that the mysipswitch architecture is a lot more flexible and means it will be possible to change the modulus operandi slightly. Up until now new versions of the software has been rapidly released to the live mysipswitch service in line with its purpose as an experimental tool. There is no desire to take a step back from that rapid release approach but since most of the new development work is confined to the dial plan and dial plan applications it will now be possible to isolate the areas subject to rapid development and even give users the choice of using the cutting “edge” version or the “stable” version.

 The diagram below illustrates where we are aiming to get to with the mysipswitch architecture. Previously all teh mysipswitch agents were encapsulated in a single process. Now they are separate and two new ones are being introduced. The first is the Stateless SIP Proxy which will take over the role of the Stateful Proxy of being the first point of contact for all external SIP traffic and acting like a traffic cop for all the other agents. The second is an “Edge” application server. This server will fulfil the same role as the current Stateful Proxy, or SIP Application Server as it could now be more correctly termed, but will be used as for cutting edge releases of new code. The new server will likely be given a name like edge.mysipswitch.com and users will be able to conenct directly to it for their calls or alternatively will be able to stay connected to the stable server and choose to forward only specific calls to the edge server from within their dial plan.

Hopefully that gives people some idea of where our efforts have been going of late and provide a bit of a roadmap about where we are heading to. It hopefully also explains why I have been more grumpier than normal! Even though mysipswitch is a free service we do still take pride in keeping it running smoothly and it gets suprisingly stressful when that’s not the case.

Regards,

Aaron

Inbound calls management with Ruby Dial plans in My SIP Switch

Wednesday, May 21st, 2008

Ruby dial plan within My SIP Switch can really prove to be powerful. They turned My SIP Switch into an easily customizable webPBX. This article aims at providing an introduction (definitely not an overview!) to inbound call management using MySIPSwitch Ruby Dial Plan.

Since programming is involved, non-technical users will need to start with the basis and then do some tweaking. More technically advanced people can really create powerful rules to block calls, to forward calls, to create some backup routes in case of call failure (busy, not available, …) with timers….

A good place to get information on ruby dial plans is the sticky thread on My SIP Switch forum: Ruby Dial Plans.

In this article, I’ll focus on the dial plan side and I consider that some SIP providers have been set up to receive calls.


1. Structure of the Ruby Dial Plan

Here is an example of empty Ruby dial plan:

#Ruby
sys.Log(”call from #{req.Header.From.FromURI.ToString()} to #{req.URI.User}.”)
if sys.In then
# Inbound rules here
else
# Outbound rules here
end

The 1st thing to mention is that the Ruby dial plan must start by “#Ruby”, that allows My SIP Switch to know that your dial plan is using Ruby and not the old syntax.

Then, the command sys.Log(”bla”), allows to leave some logs (ie: some debugging or informative comments) that will be displayed on the monitoring page. That’s a handy tool to use when testing.

sys.In (or sys.Out) are Booleans (true or false) that tell you if the present call is an incoming call or an outgoing call.

Note that any line starting by # will be considered as a comment and therefore won’t be interpreted.


2. Example of Inbound call management

Here is a simple example with some comment afterwards:

1) # INBOUND CALLS
2) if sys.In then
3) sys.Log(”Inbound call from : #{req.Header.From.FromURI.User.ToString()}”)
4)
5) inboundnb = req.Header.From.FromURI.User
6)
7) case inboundnb
8 ) when /^0034/ then sys.Dial(”0039051xxxxxx@provider1″)
9) when /^0123456789/ then sys.Dial(”300@blueface”)
10) when /^0987654321/ then sys.Dial(”00393xxxxxx@provider2″)
11) else sys.Dial(”#{sys.Username}@local”)
12) end
13)
14) # OUTBOUND CALLS
15) else
16) # outbound call rules
1st tip: I clearly commented the 2 main sections of the dial plan: the inbound and the outbound section. Since the screen to edit the dial plan is a bit small that allows finding quicker each section.

Line 3: I added a log with the 2 parties of the inbound call. That is handy to know what’s going on when you are creating your dial plan.

Line 5: That’s a variable allocation. I store the phone number of the person calling me into the variable “inboundnb”, since using all the time “req.Header.From.FromURI.User” is not that handy.

Line 7: I created a “Switch”, it looks at the value of the variable, in this case “inboundnb”, and then will match the corresponding line. For instance:

case red
when blue then “go blue”
when green then “go green”
when red then “go red”
else “go whatever”
end

Here the “switch” will match the 3rd line. If “red” was not stated in the “when” cases, then, the last line, else, would match. Adding a default line is often useful!
Don’t forget the “end” to close the switch; otherwise, you will trigger an error!

Line 8: /^0034/ will match any number starting by 0034. If someone calls me from Spain (Spain’s international prefix is 0034), I forward the call to my Italian landline since I know the call won’t be for me. The call forwarded will be billed via my provider: provider1.

Line 9: If I don’t want to talk to the owner of the phone number: 012456789, then I forward it to 300@blueface, he will hear some monkeys; more seriously, I could send a message:
sys.Respond(480, “Not available”)

Line 10: 0987654321 is that really important potential customer and I really don’t want to miss his call, so I forward it to my mobile, just in case I’m in the train or in coffee break when he calls. Note that this time I’ll use provider2 to bill that call, he has better rates than provider1 for my mobile number.

Line 11: If the dial plan didn’t match any of the previous lines, then the last one with “else” will be interpreted and in that case, the phone which will ring is the one I have registered with My SIP Switch.


3. Going further with inbound call management

- Multiple forwarding with timers :

sys.Dial(”#{sys.Username}@local”, 10)
sys.Dial(”00390xxxx@blueface”, 12)
sys.Dial(”00393xxxxx@blueface”, 15)
sys.Respond(404, “No forwards answered”)

When I receive a call, My SIP Switch will 1st try to contact the phone I have registered with it, after 10 seconds, if I don’t pick it up, then this phone stops ringing and my landline starts ringing, and if after 12 seconds, I don’t pick up the call, my mobile will ring and if I don’t reply to my mobile and then the caller will hear a recorded message saying that I’m not available.

Note that the timers start when the call is attempted, so when it starts ringing a couple of seconds can be gone already (especially for mobiles!).

Another possibility is to make 2 phones ring at the same time :
sys.Dial(”#{sys.Username}@local&mycolleaguenumber@blueface”)

Both phone will start ringing at the same time and the 1st to pick up will get the call and the other one will stop ringing.

- Availability checker

The following piece of code can prove to be very handy:

sys.Log(”isavailable=#{sys.IsAvailable().ToString()}.”)
if sys.IsAvailable()
sys.Dial(”#{sys.Username}@local”)
else
sys.Dial(”mymobile@provider”)
end

sys.IsAvailable is a Boolean : true or false. If true, then my phone will ring, if not (my internet connection died, I ran out of battery, …) then I forward the call to my mobile.

- Time management

Here is a quick example, showing that you can also route the call depending the on the time of day:

t = Time.now
timezoneoffset = -1
if (t.hour >= 18+timezoneoffset )
sys.Dial(”…”)
else
sys.Dial(”…”)
end

First : Note that Time.Now will be at GMT since My SIP Switch server is based in Dublin

One trick to cope with that is to set a variable with the time different between your zone and GMT, for instance, I’m based in Italy (GMT+1), so I need to substract 1 from the time I want my rule to match.

Here is a good page with references about Time management in Ruby : http://www.ruby-doc.org/core/classes/Time.html

That’s it for the introduction!
If you want to go further you can combine bits from the different examples I explained here and/or discuss this on My SIP Switch’s forum with other users.

Tips to install your own My SIP Switch application

Wednesday, May 7th, 2008

Since December 07, My SIP Switch can be installed on your own server or local computer with .Net (ie: Mono for Linux or Windows XP or Vista)

The news was given by Aaron on My SIP Switch forum : Local version of My SIP Switch

Here are a few tips to install it on Windows

You can download the zip file here :

http://www.mysipswitch.com/downloads/sipswitch-v0.2.zip

To check for newer versions, please, refer to the news section of My SIP Switch forum

The 1st thing to mention is that there is a readme file inside the zip with already many information about the installation and configuration.

The aim of this article is to provide further help for less technical people.

You’ll see that there are 2 ways of using My SIP Switch on your own : directly in the Windows command (console app) or as a Windows service.


CONSOLE:

The console application is probaby easier to put in place but if you close the window then My SIP Switch stops … so that can be unconveniant. That can be a 1st step in order to test and to get more familiar with My SIP Switch.

You simply need to edit the XML configuration files and the sipswitchconsole.exe.config file.

You need to modify the local loop IP (127.0.0.1) by your server IP (it can be a private IP, for instance, 192.168.1.1). Note that for localsipsockets and registrarrealms I also used my private IP.


SERVICE:

If you want to install it as a Windows service, you’ll find information in the readme file. Here are a few tips that came to my mind when I tried to install it myself on my laptop, running Windows XP:

Installation :

InstallUtil.exe is not in the system32 directory, so you’ll need to specify its path when trying to install the service; for instance:
E:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe “C:\_PATH_\sipswitchservice.exe”
Replace “C:\_PATH_” by the complete path to the .exe to install.

If after the installation you don’t see it in the list of windows service; look at the installation logs. If you have an error like : ” The inner exception System.ComponentModel.Win32Exception was thrown with the following error message: Access Denied”.  Make sure you have admin rights on your computer.  If the error persists, try to install it on a different directory (a simpler one, for instance : C:\Program Files\mysipswicth)

Configuration:
You need to modify the local loop IP (127.0.0.1) by your server IP (it can be a private IP, for instance, 192.168.1.1). Note that for localsipsockets and registrarrealms I also used my private IP.

Database / XML files :

You can use either of these technologies to store your data. Although note that XML are much simpler to edit (you simply need a text editor) than the DB (where you’ll need a PostgreSQL application such as PGAdminlll)

If you prefer to use a DB, then you can use the .sql file in the zip. Remember to uncomment the database related lines in the config file and to comment the lines related to XML files.

Then, to start the service: go to Start > right click on “My Compter” > Manage > Services and Applications. Select My SIP Switch and right-click to open the properties.

In the tab called “Connexion”, you need to make sure that the account using the service as administrator rights : either enter the admin login / password or use the “local system” if you are the admin your computer. If you don’t set this you’ll notice strange error messages when you’ll try to run the service saying that the connection to such or such address:port was not granted because of insuffisant rights.

All these should help you to get started properly

If you need further help, please, do not hesitate to post in My SIP Switch forum : http://www.mysipswitch.com/forum/index.php

By Guillaume

Siemens C450IP configuration guide for MySIPSwitch

Tuesday, May 6th, 2008

Hi,

Here is a quick configuration guide for the IP Phone : Siemens C450IP.

Important : Note that there maybe differences in naming or on the path to reach such or such screen depending on the firmware of your phone.

Siemens C450 IP

1. Get the connected physically

1st connect the phone to your router and then connect the power cable. This phone is simple so nothing tricky there.

Your phone must get an IP address, so if you are not using a DHCP, make sure to allocate an IP to your phone.





2. Get the phone’s IP address

Go to Menu > Settings > Base > Local Network (or VoIP and then Local Network, depending on your firmware) > Enter the system PIN (default is 0000) > IP Address

3. Connect the the web configuration interface

Open your favorite web browser and in the address bar enter the IP address of your phone

Write down the IP address of your phone and press enter.

Ip Address

You should see the interface below:

Web interface of C450IP





4. Enter the system pin

Click on “Settings”.

In IP configuration, by default, you won’t need to change anything. If you are not using a DHCP, then make sure your phone will always get its IP otherwise, you may encounter problems …

5. Telephony settings:

Select “Telephony”, and you should see the screen below:

Web interface of C450IP

In “Dial Plans”, you should not have anything to change (since you can handle that better with My SIP Switch).

In “Advanced Settings”, you may want to change things, but later : DTMF options especially (they should NOT be set as “Inband” if you want to use it with My SIP Switch)

Click on “Connections” and then “Edit”

You should see an interface containing the screen below:

SIP settings

Replace yourMSSusername by your actual MySIPSwitch username and edit your password.

Domain and registrar server should be sip.mysipswitch.com

Then press “Set” at the bottom.

If you go back to the page “Connections”, you should see the status as “Registered” (it may take up to 30 seconds)

5. Testing

Now that the phone is registered, you test incoming and outgoing calls.

If you don’t have sound or if the sound is only 1-way. That is more than likely a NAT problem. The 1st thing to try there is to add a STUN server in the configuration of your IP Phone, there are many free ones on the market. One I recommand often is : stun.xten.com

If you need further help, please, post on My SIP Switch’s forum

By Guillaume





Fritz!Box 7170

Monday, May 5th, 2008

Is SIP/VoIP easy ? depends…. most of the time with the common “Betamax providers” it is,

You should have not much problems, due to standard port addresses, etc… but when you do run into trouble, do you know where to look ? Should you search forever ? No, big chance your router is out of date, and your ATA isn’t the problem, and you then ask yourself, what should I set and where ? Upgrading your (modem)router is a good idea, big chance the new one has allready the “NAT things” set good at its default values, but if you have to set things for another sip-provider or a different setup, it starts all over again, so what did I recently do ? I ….bought the …. Fritz!Box 7170 !

Fritzbox

Also because I heard a lot of good things about this one, by users and also as a “by ISP provided device” (snooping around in the webinterface, I now see the point of that) (voip over ADSL…)

Follow the paperguide, that comes with the Fritz! (7170) and look for your “situation”

The box uses a weird looking cable to connect to your splitter, (or other if appropiate) it’s a ‘Y’ cable, that puts your telephone line connection and ADSL connection to one connector, that goes into the Fritz!Box, so you must read this carefully…but everything is marked…

Dont get confused because the landline connector gets mentioned seperately in “the story”‘,

I guess this makes the Fritz!box also compatible in other configurations…. once the hardware is installed, you put in the disc that comes with the Fritz! in your pc drive, and fill in your ADSL inlog info…and the …MySipSwitch inlog account info at “Internet Telephony provider, and you’re up and running,

All phone calls will now go through the internet, exept the emergency numbers.

After this the real fun starts…and you can make it very fancy ! :) if you want to go that far,

But i guess most of it you will manage from MySIPSwitch,

Use your dialplan settings as always, at MySipSwitch.

Set the Fritz! in “Expert Mode” to see all features and settings, you now should snoop around in the Fritz! web interface, and use the help function, to see what’s possible with that particular function…It’s all reasonably clear to use unlike with the SPA3102, which i found “a bit tricky”

By TheFug

X-Lite 3.0 Configuration for My SIP Switch

Sunday, May 4th, 2008

Here is a quick, getting started guide for X-Lite 3.0 for WIndows XP.

1. After the installation, you should have the following screen:

No SIP Account are Enabled

2. Click on the small white arrow which says “Show Menu” and then select : “SIP Accounts Settings”

Edit SIP Account

3. Click on “Add”

Add a SIP Account

4. Now, you need to register your My SIP Switch account settings:

Display name : your name, for instance Joe Bloggs

Username : it is your My SIP Switch username

Password : your My SIP Switch password

Domain : sip.mysipswitch.com

Register with Domain and receive incoming calls must be ticked

Send outbound via : Proxy : sip.mysipswitch.com

Edit SIP Account settings

Press “Apply” and the OK.

You notice that X-Lite is trying to register and upon success will display “Ready” and “Your username is …”.

Once this registration is fine you can start making test calls.

(more…)

Quick and Dirty Code Overview

Thursday, April 17th, 2008

I’ve had a request to provide some documentation for the code used for the mysipswitch service (downloadable from CodePlex) however there is no documentation. We’ve focused on getting a usable service up and running and providing new features rather than a concentrating too much on a developer friendly code base. The reasoning behind that approach is that there are more people interested in using the software than there are developing with it (plus I am absolutely terrible at providing external documentation for code. UML diagrams and code commenting fine but external reference documents are like pulling teeth). This post is a designed to provide a very very brief overview of the code used in the development of the sipswitch to provide a starting point.

The code is written in C# and uses Microsoft’s .Net Framework v3 libraries. It is possible to disable one part of the sipswitch (Sys.Http which provides web services from the SIP Server) and run it on Linux but for full functionality Windows is required. The main assemblies are:

  • BlueFace.Sys - General purpose assembly that contains commonly used functionality such as database access, cryptographic initialisation, string formatting etc,
  • BlueFace.VoIP.Net - The engine room of the SIP functionality. This assembly handles all the parsing and processing of SIP Transactions, SIP Requests and SIP Responses and all the pieces within them such as SIP URIs, SIP Headers, SIP Parameters etc. The intention is that this assembly implements the SIP RFC however at 269 pages in length it’s a serios RFC with lots of side references and conformance is guaranteed to be incomplete,
  • BlueFace.VoIP.Net.App - This assembly contains more specialised functionlaity that builds on top of the SIP stack in BlueFace.VoIP.Net or compliments it. Most of the functionality in this assembly is incomplete and is either a placeholder or minimum functionality to achieve a specific task. An example is the SDP.cs class which partially implements a Session Description Protocol parser. To date the only information that has been needed from the SDP has been the IP address and port number so no real effort has been put into parsing all the other information in an SDP message,
  • BlueFace.VoIP.SIPServerCores - This assembly implements the different SIP Servers in use by mysipswitch which are:
    • SIP Registrar
    • SIP Registration Agent (client to register with 3rd party SIP Providers)
    • SIP Stateful Proxy
    • Telnet Monitoring Console
    • STUN Server
    • NAT KeepAlive Server
  • SIPSwitch.Service - The Windows Service (can also be compiled as a Console application) that is the mysipswitch dameon and which controls the starting and wiring up of each of the individual servers.

That’s the main assemblies described. The simplest type of SIP Server is a stateless SIP Proxy and the SIP stack makes this a very easy job. I’ll aim to provide some example code for that in the next post as it’s also a good way to demonstrate the use of the code without requiring an in depth understanding of the inner workings which is of course what all time strapped developers are after!

Regards,

Aaron