SDK 6.7.2 is the latest Brooktrout development kit providing feature rich capabilities to our partners. In addition to the normal assortment of bug fixes, 6.7.2 also has added some new features that will be quite useful. I’m going to focus on a few of them here, over several blog posts, to give more details on why they can help you. This is the third of three blog posts.
The last new feature I’d like to discuss has to do with what the SR140’s SIP stack does when there are no channels waiting for a call. All the channels may be currently occupied with calls or maybe the application hasn’t set any of the channels to wait for calls. Whatever the reason, if a SIP calls comes in then, the SR140’s SIP stack will send back a 486 Busy signal after 5 seconds to let the gateway know that the call can’t be processed then. If a channel does become free and goes into a waiting for call state before the 5 seconds have expired, then the call will be answered and there will be no 486 BUSY sent out. That’s all fine and good, but we have seen at least one case where a gateway wanted more than that. Specifically, it wanted the SR140 first to send a 100 Trying message immediately and then send the 486 Busy after the usual 5 seconds. So we’ve gone ahead and made such a change. This change will not affect the 5 second delay or any other aspect of sending the 486 Busy.
Here are the before and after line diagrams for this feature.
Is there a way to disable the 5 second delay for busy, or configure it to a smaller window?
You can use the inbound_call_timeout parameter in callctrl.cfg (units = ms) for this. You'd set the parameter like this.
Bob, thanks so much. Quick question, will setting that to 0 return a busy immediately, or will it never return a busy?
Setting it to 0 will make the 486 Busy be sent immediately after the 100 Trying.