What makes a system “Carrier Class” (as in Telecoms Carrier)?? The answer is subjective of course but a few idle ideas popped into my head that I thought worth wasting a few lines for.
Hi all,
Here are some screen shots of the configuration interface of a Grandstream Handytone 286 ATA that with indications on how to set it up with My SIP Switch service.
Note that it is very similar to Budget Phone 100 / 101 configuration screens.
Thanks a lot to Luc for the screen shots.
Note that the IP settings are specific here. This ATA is connected behind a Linksys WR54G router with NAT enabled ! You will want to change that depending on your network configuration.
The DHCP options means that the IP settings will be assigned dynamically by the router. It may be handier for less technical people.
The DNS values are specific to your broadband provider so mind these values.
Note that the “local SIP Port” has been changed here for a specific reason. 5060 is in most cases fine. You need to make sure that the router which is in front of this ATA allows SIP traffic on this port.
The STUN server can be changed of course. There are a bunch of free ones you can use (see : http://www.voip-info.org/wiki-STUN)
Press Update and give it a go !
On the status page, you should see the SIP packets getting through and RTP ones if you are making calls.
You can also take a look at the configuration guide on Blueface’s site : HandyTone286 Configuration
Any questions , refer to our Technical Forum
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:
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
Default Ruby dial plan line by line.
When getting started, the default Ruby dial plan can be a bit hard to understand and many people don’t really know what to edit inside. This small article is aiming at explaining the basics so you can get started easier.
The first thing to mention is that with My SIP Switch there are 2 (very) different syntaxes for the dial plans. The “old one” is based on Asterisk syntax and using lines like that: “exten => …”. The new one is based on Ruby scripting and his much more powerful. You cannot use both syntaxes in the same dial plan! You need to pick one.
Here is the default Ruby dial plan (as of July 2008 and minus a few comments for clarity):
#Ruby
sys.Log(”call from #{req.Header.From.FromURI.ToString()} to #{req.URI.User}.”)
if sys.In then
# Do your incoming call processing customisations here.
sys.Dial(”#{sys.Username}@local”)
else
# Do your outgoing call processing customisations here.
case req.URI.User
when /^303$/ then sys.Dial(”303@sip.blueface.ie”)
when /^612$/ then sys.Dial(”612@fwd.pulver.com”)
when /^\*1/ then sys.Dial(”${dst:2}@provider1″)
when /^\*2/ then sys.Dial(”${dst:2}@provider2″)
when /^\*3/ then sys.Dial(”${dst:2}@provider3″)
else sys.Dial(”provider1″)
end
end
A Ruby dial plan must start with the line (Never remove that line):
#Ruby
The lines starting by # are comments. They are not interpreted as part of the dial plan. I removed most of them here.
The line:
sys.Log(”call from #{req.Header.From.FromURI.ToString()} to #{req.URI.User}.”)
will “log” all calls into the monitoring page. That allows to keep track of what’s going on and also to debug when you are testing the service.
The syntax is the following: sys.Log(” my log here “)
If you want to insert a variable into a log, you can use #{variable_name} for instance : #{req.URI.User}, as you’ve seen in the example above.
Then, starts the actual dial plan!
Inbound and outbound calls are clearly separated with the following structure:
if sys.In then
# INbound calls here
else
# OUTbound calls here
end
When you receive a call: sys.In will be equal to “True” and only the code between “then” and “else” will be interpreted.
The next line, starting with a #, is not interpreted. It’s a comment.
Incoming calls:
sys.Dial(”#{sys.Username}@local”)
That line, when interpreted, will call the phone which is registered to My SIP Switch.
sys.Username is a variable as is, it must not be changed! It will be equal to your actual username. Don’t do anything like that: sys.JohnSmith ; that would trigger an error.
If you want to receive your incoming calls on another phone, you can edit this line like that:
sys.Dial(”123456@myprovider”)
Where 123456 is the number you want to dial with the provider: myprovider (the provider’s name used here are the ones you set up when adding a new provider, in the 1st field).
That’s it of the incoming calls on this guide.
If you need further help, you can refer to this article:
Inbound Call Management with Ruby Dial Plans
You can also refer to these threads on the forum:
http://www.mysipswitch.com/forum/viewtopic.php?t=139
http://www.mysipswitch.com/forum/viewtopic.php?t=399
Then for the outgoing calls, by default we have:
case req.URI.User
when /^303$/ then sys.Dial(”303@sip.blueface.ie”)
when /^612$/ then sys.Dial(”612@fwd.pulver.com”)
when /^\*1/ then sys.Dial(”${dst:2}@provider1″)
when /^\*2/ then sys.Dial(”${dst:2}@provider2″)
when /^\*3/ then sys.Dial(”${dst:2}@provider3″)
else sys.Dial(”provider1″)
end
case req.URI.User is another test based on “pattern” which include several possibilities: each when represent a different situation if the outgoing call can’t be match to any of those cases then my SIP switch will follow the else rules.
As pattern match tool, we are using Regular Expressions (everything between /^ and / is a regular expression).
when /^303$/ then sys.Dial(”303@sip.blueface.ie”) means that when you dial 303 on your SIP phone. You will hear Blueface speaking clock.
when /^612$/ then sys.Dial(”612@fwd.pulver.com”) means that when you dial 303 on your SIP phone. You will hear FWD speaking clock.
when /^\*1/ then sys.Dial(”${dst:2}@provider1″)
Any number starting by *1 will match this case. Note that the * is a special character so we need a \ before it. ${dst:2} is representing the number you dialed minus the 2 first digits (*1 here).
If you called your provider something different than “provider1″ you’ll need to modify this! It must be one of the names you set as provider. If you don’t do that, when calling, you’ll notice an error message in the monitoring page saying : “Cannot resolve provider1″.
when /^\*2/ then sys.Dial(”${dst:2}@provider2″)
when /^\*3/ then sys.Dial(”${dst:2}@provider3″)
Same thing with *2 and *3.
else sys.Dial(”provider1″) Forward outgoing calls to provider1.
If you dialed a number which doesn’t start by *1, *2 or *3 then this line will be used. That’s the provider by default. Note that there is not ${dst} involved, since here you don’t need to remove any digit but to dial the number as is.
If you wanted to match any UK number and dial them with a specific provider you can do something like that:
when /^0044.*/ then sys.Dial(”0${dst:4}@ukprovider”)
Any number starting by 0044 will match the case, and then we remove the 0044 and replace that by a 0 (to adjust to local dialing). Then the resulting number is called via the provider named: ukprovider.
Then we have the closing tags “end” of the IF and of the CASE. Make sure not to remove them!
Remember that, this is a basic guide so I mentioned only a few possibilities of the software. If you want to go further you can refer to our forum and blog; quite a few examples have been written there.
Guillaume
PS : Thanks Thomas for the draft you made about this article 
Over the last 6 weeks there has been a bit of a slowdown in new features with the sipswitch this has been in due solely to the memory leak that we have been chasing down during that period. I’ve posted on the forums site about the problem 3 times in the News section. A number of times we thought the issue was fixed only to find the sipswitch memory usage creeping up again. This is a real problem as if it’s not caught the sipswitch will at the very least become slow and unresponsive and at worst will crash.
One issue was found in the IronRuby engine that was a definite problem and a workaround was put in place that made a big difference. The ironRuby developers were made aware of the problem and hopefully it will be fixed over time. However despite that we still supsect that even with the workaround in place there is still a slow leak occurring. As such we have been working to re-factor the software so that each of the individual agents can run in its own process. The four main agents are the SIP Proxy, the SIP Registrar, the Registration Agent and the Monitoring Console. Currently they all run in the same process which is a nice easy approach to manage but not so good for troubleshooting and scalability.
The idea is to be able to have the sipswitch software able to run as a single process, useful when run locally, or to be able to split out into multiple processes. The splitting out has required quite a bit of refactoring as when everything is in the same process information can be share easily, things such as the Proxy looking up the contact on the Registrar. If they are split out some extra work is required.
So that’s it another quick update for anyone wondering what has been going on in the background. Hopefully we’llg et all this ironed out and get back to adding features in the near future. At the end of the day if the leak has been caused by IronRuby, which I strongly suspect, then it’s still been worth it. I can’t imagine not having a Ruby dialplan now I’ve had a taste.
Regards, Aaron
Following my previous article about PhonerLite I wanted to write a quick review of his elder brother : Phoner
http://www.phoner.de/index_en.htm
It’s a Windows only softphone (95/98/ME/NT40/2000/XP)
The configuration is also made with a step by step Wizard (nearly the same one as PhonerLite), so it is really convenient and easy. I tested it with My SIP Switch and my impressions were the same as for PhonerLite : really fast to get started, easy to use and I cannot complain at all on the audio quality.
It is fully compatible with SIP and has all the main options/feature you would expect on a softphone. What makes it a bit special is that it has ISDN facilities (which is not that common on a softphone). Note that you need an ISDN adapter.
The complete list of features is available here : Phoner Features
I discovered today (Thanks to our user : deeknow) this nice, very easy to use and free softphone : PhonerLite.
Official site and download
The offical English web page is :
http://www.phonerlite.de/index_en.htm
PhonerLite is the lighter version of Phoner. It shares most of the code but with a (much) lighter interface in order to save resources. It was using 8Mo of RAM on my Windows XP while idle which is much lower than the idle XLite which was using up to 32Mo.
The donwload page is :
http://www.phonerlite.de/download_en.htm
If you download the ZIP file, you don’t need to do any installation (just don’t mess with the DLL); you can start using the phone by double clicking on PhonerLite.exe .
Screenshot and a quick review
It does all the necessary thing : easy control of settings and options (sound settings, codecs, security, network settings) … Regarding the phone features : call on hold (that’s the little hand near the green ‘pick up’ button), redial (the yin-yang like image below the hang up button), do not disturb, conference calls , call forwarding (I didn’t test these 2 features so far), logs, phone book …
Another thing I like about it is that it provides live statistics about the line such as Jitter and packet loss for instance. If you are having call quality issues, you can easily check if it is due to your network or broadband connection.
I have not tested it for long enough to judge it properly but the voice quality seemed nice; as nice as you can expect it to be on a softphone.
My SIP Switch Configuration
Now here are the steps to configure it with My SIP Switch:
Note that if you are behind a firewall, you may want to enter a STUN server (for instance : stun.xten.com).
Enter your My SIP Switch username and password. The authentication name is not necessary.
Select your audio devices.
Confirm and start My SIP Switching
This article is a bit off topic on this blog but I found the tool so powerful and easy to use that I wanted to share this.
I needed to start a computer running Windows XP SP2. The former user had a password on his account (account with admin rights) and I had no way to contact him.
I used a tool which allows editing or resenting the password of any of the user account on the computer.
That doesn’t recover the password (at least I don’t think so), that allows to reset or to allocate a new one. According to their website it works for Windows NT versions : 2000, XP, Vista.
Here is the link: http://home.eunet.no/~pnordahl/ntpasswd/
Basically you simply need to
You need less that 10 minutes all together. That’s brillant.
That also makes you realise a few security threats on a windows computer : get the boot sequence to start from the hard drive first (that will prevent anyone trying to boot your computer with that kind of software and change your password) and also lock the Bios changes with a password so that anyone cannot change the boot sequence.
Guillaume
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.
A simple dialpan rule may look like this:
exten => _X.,1,Switch(VOIPBUSTER)
or:
exten => _X.,1,Switch(${EXTEN}@VOIPBUSTER)
(to set other $ and {EXTEN} values)
(at the bottom of this blog, you’ll find a Ruby translation)
This will dial all you dial (exactly) with provider VOIPBUSTER or any other, which you gave that name, When you registered that provider, with that particular “Provider Name”
But this would mean, you only can make a phonecall, when you dialed the complete International dialing sequence, also for someone that lives in your own city, that’s a bit clumbsy,
and you have to “instruct” the other people using your phone system, So, you want to overcome this, and it can !
Here comes the “transparent” part !
Say, you always have to dial: (i’m living in the Netherlands) 0031 for the Netherlands, and 020 for Amsterdam, and 1234567 for the subscriber, what should be dialed is: 0031201234567 (notice the first 0 of the city dial code should not be dialed, when dialing internationaly) Your dialplan rule could look like this:
exten => _ZX.,1,Switch(003120${EXTEN}@VOIPBUSTER)
The first part in the dialplan detects you are not dialing a zero, (expression letter is used, for a value in the 1 - 9 range) see the dialplan expressions list below.
Now, this will be dialed by MySIPSwitch: 003120 + what you have dialed in the first place.. For dialing nationaly/internationaly, you can figure out in the same way a “plan” detecting te amount of zero’s depending how “far” the call will go, nationaly:
exten => _0ZX.,1,Switch(0031${EXTEN:1}@VOIPBUSTER)
or internationaly:
exten => _0032X.,1,Switch(${EXTEN}@VOIPCHOICE)
and according to the country code, which provider you want to use for that destination, that is the cheapest way to do so…. you use one of the Provider (Name)’s, you have registered.
btw. keep in mind you ‘re using your dialplan at MySIPSwitch, so you do not do this in your ATA or SIP phone, these settings should be completely transparent, and accept all combinations, and do nothing with it, just pass it through, otherwise your dialplan at MySIPSwitch will not respond like here is mentioned.
A Ruby translation for outgoing only:
when /^06/ then sys.Dial(”00316${dst:2}@INTERVOIP”)
in the above sample, you see 06 is detected, 00316 plus what’s keyed in, minus the first two digits that where keyed in. > dst:2 with the INTERVOIP provider, 06 are the first digits dialed in the Netherlands, to dial a mobile phone, nationally, 0031 is the international code needed for VoIP, and the first zero shouldn’t be dialed, just like with the city dial code. you can edit this rule to your likings, edit the “06″ edit or remove the “00316″ or edit or remove the “:2″
TheFug.
btw: some dialplan expressions:
X - any digit from 0-9
Z - any digit from 1-9
N - any digit from 2-9
[1235-9] any digit in the brackets
. wildcard, matches anything remaining
