Incoming call processing

One of the biggest enhancements in the sipsorcery service compared to the previous mysipswitch service is the number of different ways of processing incoming calls. The drivers for the enhancements were requests by various mysipswitch users for alternative or more flexible ways to process incoming calls. At this stage I believe pretty much every request in the area has been accommodated but unfortunately a side effect has been a number of sipsorcery users having difficulty getting their calls working as they expect. The intention of this post is to clarify the mechanisms available for incoming calls and how they work.

Before delving into the incoming call processing mechanisms one point that needs to be clarified is the mysipswitch concept of SIP accounts and Extensions. An extension with mysipswitch was a SIP URI (e.g. that could be handed out and that was stored in a separate database table to the SIP accounts and that was looked up if no matching SIP account was found. Extensions were very much a bolt on to mysipswitch to cope with the fact that only a single SIP account could be created oer mysipswitch user. With sipsorcery the single SIP account restriction is gone and with it the need to have a separate concept of an extension. Instead there is now the option to create a SIP account that can be specified as incoming only and which will act the same as the mysipwitch Extensions.

Add incoming only SIP account

Add incoming only SIP account

Now that that’s clarified onto the different options for processing incoming calls.

  • Direct to registered bindings,
  • In Dial Plan,
  • Suffix matching.


The Direct option is the default option and is the simplest. It works by forwarding any incoming calls to a SIP account to any currently registered bindings for that SIP account. To use this option the only thing required is that the In Dial Plan setting on the SIP account is left blank. As an example if I were to create a SIP account called joe.bloggs@sipsorcery.comand set up one of my SIP Providers to forward calls to then to receive those calls all I need to do is register my SIP device with with a username of joe.bloggs. Up to 10 SIP devices can register with the same username and when an incoming call comes in they will all ring with the first one that picks up getting the call.

In Dial Plan

The In Dial plan is as the name suggests and the incoming call will be forwarded to the dialplan specified in the In Dial Plan setting for processing. Within the dialplan the call can be processed in any manner desired. An example of an in dialplan that accomplishes exactly the same as the previous Direct option for incoming call processing is shown below.

sys.Log("dialplan defaultin starting...")
sys.Log("call from #{req.Header.From.FromURI.ToString()} to #{req.URI.User}.")

In the above dialplan an incoming call to will be sent to the defaultin dialplan for processing. Once there it will print the two log messages and then the call will be forwarded to all the current bindings registered for the SIP Account, i.e. exactly the same behaviour as the Direct option.

Suffix Matching

Another mechanism that was cobbled on, in the same way extensions were, to mysipswitch was the ability to process calls that had an arbitrary suffix with a prefix matching an existing SIP account username. By popular demand the same behaviour has been added to sipsorcery.

As an example of how it works if I owned a SIP account called myextension@sipsorcery.comthen incoming calls to the following SIP URIs will also be accepted and processed in exactly the same way as myextension:


The crucial factor is all the URIs end with note the ‘.’ it is the separator between the suffix and the SIP Acount name.

Calls to other sipsorcery accounts from within a dialplan

With sipsorcery if you placed a call to another sipsorcery SIP Account within a dialplan then that call will honour the In Dial Plan setting on the called SIP Account. For example if I use the forward below in my dialplan:


If the myextension SIP account has an In Dial Plan set then the call will now be sent to that dialplan for processing rather than directly to myextension’s registered bindings. If the In Dial Plan is not set then the Dial command will result in the call being forwarded directly to myextension’s registered bindings.

This is a powerful and potentially dangerous feature since a chain of calls to local accounts or two accounts dialling each could result in a large number of dialplans being simultaneously processed. It is requested that suitable precautions be taken to avoid that happening for anyone that wished to make use of this feature.

One additional point when calling local accounts within a dialplan is that if a forward is attempted to a SIP account from the same dialplan that is configured on its In Dial Plan setting then the dialplan will not be used, doing so would create an infinite loop, and instead the registered bindings will be used.

And Finally…

it’s not directly related to the incoming call processing mechanisms but if you find that calls are not reliably getting through to your SIP device from the sipsorcery server then more than likely your NAT is timing out the connection. The best way around that is to check your device for a NAT keep-alive option and activate it. NAT keep-alives work by sending a small packet every 15 to 30s from a SIP user agent to the server to keep the connection alive through the router. If there is no option on your user agent then you can select the option on the SIP Account at the sipsorcery end. This does the same thing in reverse. It’s not quite as good as NATs will respect traffic originating from the private side better than traffic originating from the public side but it should still help.

In addition the expiry interval on your user agent can be reduced. The sipsorcery SIP registrar uses a default register expiry of 113s, sometimes reducing that to 60s can improve the durability of the connection between your user agent and the sipsorcery server through your NAT.

And that’s it, please feel free to post comments with questions for any clarifications on the subject of incoming call processing but I would request thatyou not post comments with general support questions.

  1. TheFug’s avatar

    The “time related” function, for rerouting incomming calls i had working in MSS, is not working for SS, is there an explanation for this ?


  2. sipsorcery’s avatar

    I don’t know what you mean by time related function. Can you provide an example. The Ruby time functions should work just the same as they did before but be aware the server is now in a US time zone and not UTC.


  3. TheFug’s avatar

    t = + (1*60*60) # Get current time and adjust to local time GMT+1no DST needed
    sys.Log(t.strftime(‘local time time: %c’))
    tijd = t.strftime(‘%H:%M’)
    sys.Log(“Tijd : #{tijd}”)
    if (1..5) === t.wday && (’06:35′..’17:15′) === tijd
    sys.Dial(“90031xxxxxxxxx@TPAD” ,25)

    gets into an error statement….. if added


  4. sipsorcery’s avatar

    You’ll need to troubleshoot that script yourself. The easiest way would be to add some more sys.Log statements to check values as you go. The Ruby engine is an external library and not something we work on. The sys and req objects are sipsorcery stuff everything else is the Ruby engine. I strongly doubt the Ruby Time functions have been broken in the newer version of IronRuby sipsorcery uses and suspect there is a problem with your script.


  5. destinycan’s avatar

    Thank you Aaron for your effort. It is one of the best web utilities voip users.

    Will you be releasing local version of sipsorcery any time soon?


  6. Todd’s avatar

    Sip Sorcery is the best solution for multiple VoIP accounts! Thank you for sharing this service and your considerable talents!


  7. Alexander’s avatar

    As for the one device from one account to call for the second account?
    It is really?


    1. sipsorcery’s avatar

      Calling between two SIP accounts behind the same NAT is tricky when the server does not get involved in the audio. What you have to try and do is get the two SIP deviceds to set the audio up directly between them.

      I added the networkid setting to the SIP accounts explicilty for this. If you cretae two different SIP accounts and set their netowrkid to the same value, say “home”, then when you call between them the audio “should” get set up directly between them.

      For me it kind of worked. I was able to get audio working from my Cisco to my Polycom but not the other way around. Either my NAT is messing with the packets or the Polycom is doing unhappy about something, I didn’t investigate further.


    2. Alexander’s avatar

      How to make RTP low? (16348-32768) All time high .. No sound ..

      How to make RTP low? () All time high .. No sound ..
      DialPlan=> Response 200 OK for
      DialPlan=> UAC response SDP was mangled from sdp=, proxyfrom=udp:, mangle=True.
      DialPlan=> SDP on response had address of
      DialPlan=> Cancelling all call legs for ForkCall app.
      SIPTransaction=> Send Final Response Reliable udp:>
      SIP/2.0 200 Ok
      Via: SIP/2.0/UDP;branch=z9hG4bKA3F835C588663C31B3E41646953E91C0470E3F0
      Via: SIP/2.0/UDP;branch=z9hG4bK322c750521ce4cd891e1df8bc83f24d9
      Via: SIP/2.0/UDP;branch=z9hG4bK-blS-17846;proxy=udp:
      To: ;tag=1755836624
      From: “1.172703” ;tag=egJ-2595
      Call-ID: XDs-8390@
      CSeq: 86 INVITE
      Content-Length: 263
      Content-Type: application/sdp

      o=root 990 990 IN IP4
      c=IN IP4
      t=0 0
      m=audio 47050 RTP/AVP 0 8 2
      c=IN IP4
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:2 G726-32/8000

      DialPlan=> Dialplan trace completed at 20 Jul 2009 00:04:20:995.


      1. sipsorcery’s avatar

        The RTP ports are set by the user agents at either end of the call. The sipsorcery server does not get involved in the audio stream an is oblivious to which ports get used.

        The one thing the sipsorcery server will do is mangle a private IP addresses it finds in the RTP and replace it with the public IP address the request came from. This “often” helps the audio RTP stream “work”.

        You’ll often find audio works with some providers and not others the reason is that some handle RTP from behind NAT by changing the destination of the server’s stream to the socket the client is sending from.

        If you’re trying to set up a call where both user agents are behind NATs it’s going to depend on how the routers in front of the two UAs work. If they are doing portas well as network translation then there is little chance a call through the sipsorcery server will work. Instead you’d need a service that handles RTP audio such as voxalot or pbxes.


      2. jvwelzen’s avatar

        the networkid doesn’t seem to work for me

        also calling between 2 different nat networks doesn’t seem to work

        any idea how we can solve this or are you going to further check this


        1. sipsorcery’s avatar

          It’s not likely to be looked at again unless you can point out exactly where the deficiency is. There are a number of NAT handling mechanisms in the sipsorcery code that deal with magling the IP address in the SDP. However there are a huge number of different routers and NAT behaviours and troubleshooting issues in that is not something that appeals to me greatly. Once you introduce two or more NATs it gets every tricky to understand your issue.


        2. jvwelzen’s avatar


          I always used 2 fritzbox 7270 routers and the local version off mss

          But I never had problems with calling from nat 2 nat with mss

          with the new ss this is not working anymore

          also i use sjphone 2 make some test calls and it usaliy shows full cone nat but sjphone also was working great when calling from nat


        3. MikeTelis’s avatar

          It seems that suffix matching doesn’t work when invoked like this:


          Sipsorcery is treating “local” incoming calls differently and suffix matching doesn’t work.

          Why do I need that? I’m trying to convert sys.GoogleVoiceCall into a SIP proxy. I created an extension (let’s call it GVDial) and I’m trying to call it like this:


          I was hoping to extract prefix (12125551212) in Ruby script processing incoming calls for GVDial but…


          1. sipsorcery’s avatar

            It’s better if that goes on the forums. I don’t really want this blog to become technical support.





Your email address will not be published. Required fields are marked *