SDK 6.7.5 is the latest Brooktrout development kit providing feature rich capabilities to our partners. We’ve added some new features that will be quite useful, and I will discuss a couple of them on what they do and why they can help you.
We’ve added a feature in SDK 6.7.5 that allows users to specify which channel the SR140 software uses to answer an incoming SIP call.
This feature allows the user to specify an SR140 channel to answer an incoming SIP INVITE based on certain header fields. The “To:” and “From:” SIP INVITE header fields correspond to the called party number (called address) and calling party number (calling address). A user can set up an optional routing table file to specify channels and credentials that will be used based on the information in the SIP INVITE header fields.
By default, when a new call arrives, whichever channel has been waiting the longest for a call will get the next incoming call. For example, if you have two SR140 channels, whichever of those channels had last called an API function to wait for a call will get the next call assigned to it.
There may be times though when you may want to define certain SR140 channels for special purposes in your application. For example, you may want to have one channel play a specific greeting when it answers the call but still have all the rest of the channels just go straight to sending fax tones.
In callctrl.cfg, you’d set your routing table file like this:
[host_module.1] module_library=brktsip.dll enabled=true routing_table=c:\brooktrout\boston\config\routing.txt
What does the routing table file look like?
The routing table uses a set of rules that specify the channel(s) the rule applies to. Each rule has a rule number which sets its priority against other rules (the lower the rule number the higher the rule’s priority), an SR140 channel or range of channels, and called and calling address fields.
The called address and calling address numbers can contain digits 0 through 9 as well as the character X to specify wildcards. The wildcard character X is not case sensitive. Ranges of digits may also be set. Plus you can populate one or both of these fields depending on which information you’re interested in creating the rule for.
Here are some example rules:
[routing.1] channel 0 called_address = "1001" calling_address= ""
This first rule is called “routing.1”. The 1 is the rule number and so this rule would have the highest priority in the routing table. This rule applies only to SR140 channel 0 and it looks for a called party number of 1001. The “calling_address” field is left blank, so this rule would not care about whatever was set in the calling party number. If a call comes in with a called party number of 1001, channel 0 on the SR140 would get this call.
[routing.2] channel 1 called_address = "2xx4" calling_address ="1"
We can see that for this rule, called “routing.2”, channel 1 would be the intended recipient. This rule looks at both the called party and the calling party numbers for it to apply. Further, the “called_address” field uses two wildcard digits. So for this rule, the calling party number would need to be 1 and the called party number could be any 4-digit number with 2 at the beginning and 4 at the end, like 2174 or 2294.
[routing.3] channel 2-5 called_address = "[2-4]234" calling_address="973xxxXXXX"
For rule “routing.3” we’ve further mixed things up a bit. Instead of applying to just one SR140 channel, this rule applies to a range of channels, specifically channels 2 through 5. Any of those channels could receive this call. Again, both a called party number and calling party number would be needed to meet this rule, but the “called_address” field now has a range in use for the first digit. Thus the called party number would need to be 2234, 3234, or 4234 here.
If a rule is not constructed correctly, it will simply not be used. The SR140’s call control will recognize the rule as invalid and skip over it. Also, it’s permissible to skip over rule numbers. You could have rules “routing.2”, “routing.3” and “routing.5” if you wish. Of course, “routing.2” would be the highest priority rule for that example.
So what if the specified SR140 channel is already in the middle of a call when another call comes in that matches it? The SR140’s SIP stack would send back a 486 Busy to this new call because the rule’s channel was already in use (assuming there was only one channel for that rule). The new call will not be routed elsewhere.
What about the channels that don’t have rules set up for them? What do they do? They would behave as normal. If a call came in that didn’t match any of the rules, it would be assigned to one of the channels with no routing rules and whichever of those channels had been waiting the longest would get the call.
OK, so what about if an incoming call matches more than one rule or if the call pertains to a range of channels? Which channels answers then? If more than one rule would apply then the rule with the highest priority would get the call. If a rule sets up a range of channels, then within that range whichever channel has been waiting the longest will get the next call matching that rule.
I hope you find this new feature useful.
Thx, very usefull and could be usesull for some customers.