“Call forwarding” is a very traditional service in VoIP or communication fields. By default, SIP clients can send 3xx messages to miniSIPServer to invoke a forwarding. In another way, miniSIPServer can also directly invoke forwarding by itself.
But when the callee side is being forwarding, the caller side knows nothing about it. In most scenarios, the caller parties don’t care the forwarding. but some customers sometimes need to know what happens when the call is being forwarded.
miniSIPServer can send 181 “Call Is Being Forwarded” messages back to the caller side to update it that callee side is being forwarding. In the 181 messages, miniSIPServer will add a Call-Info header to indicate the forwarding information. Please refer to the figure below.
In this figure, there are two forwardings, (1) user B is being forwarded to user C; and (2) user C is being forwarded to user D.
The Call-Info header of the 181 message will indicate (1) the call is being forwarded, (2) who is being forwarded, and (3) who is being forwarded to. Please refer to the Call-Info header of the first 181 message which indicates user B is being forwarded to user C.
OpenSSL released new versions to fix several serious security problems. miniSIPServer uses the OpenSSL library to provide the SIP over TLS feature and we upgrade miniSIPServer to V40 (20230221) versions which use the latest OpenSSL library.
If you have deployed “SIP over TLS” in your VoIP network, we strongly recommend that you upgrade miniSIPServer to the latest versions.
By default SIP network always uses SIP URI to carry information, such as From, To, and so on. For example:
But for traditional telecommunication networks, they always use E.164 telephone numbers which are different with SIP URI. So ETSI (or 3GPP) defines a new URI, that is TEL URL. For example:
So when working with IMS networks, there could have two URI formats, SIP URI and TEL URI. miniSIPServer can support both formats, it can process TEL URI of incoming calls automatically, but all outgoing calls always use SIP URI formats.
It could be a problem. Fortunately IMS networks consider it very carefully. For example, China Mobile can accept TEL URI and SIP URI with special parameter ‘user=phone‘ which is described below.
If we configure external lines of miniSIPServer to work with China Mobile networks, it can be no problem because miniSIPServer will automatically add ‘user=phone’ to Request-URI. But in some markets, China Mobile requires to establish SIP trunk connections, then it could be a problem. miniSIPServer will not add ‘user=phone’ in Request-URI since we think it is a ‘server to server’ scenario.
To fix that, we add a ‘additional parameter of Request-URI’ parameter in SIP trunk outgoing call configuration. Please refer to the figure below.
We updated miniSIPServer to fit 4K screen recently, but we find that we have to upgrade our tool chains at the same time if we want to get a perfect result.
Unfortunately the new tool chains cannot support Windows XP/2003 systems, so it is time to say good bye and move on now.
The latest version (V40) is released yesterday and it requires Windows 7 or abover version if you want to deploy miniSIPServer on Windows system. V40 is also rebuilt for Debian / Ubuntu systems to fit higher DPI screens.
Please enjoy the new versions. And please update us if you have any questions or opinions. Thanks.
Our customers report a bug when running miniSIPPhone with a 4K screen. Please refer to the figure below.
When building GUI (including miniSIPPhone and miniSIPServer), we use absolute positions and lengths to assign components, so they are quite small or tight if the screen has hight resolution ratio, for example, a 4K screen.
To fix that, we change the absolute values to relative positions and lengths. Of course, both miniSIPServer (V39 build 20220823) and miniSIPPhone (V8.4) are updated.
In another way, we refine dialogs sizes and styles of miniSIPServer at the same time. It should be more comfortable now.
Sometimes, customers want to know some details about history calls, such as who released such calls and why they were released. Because they were not real-time information, we cannot use miniSIPServer trace tool to get the results, so we update CDR function to save more informations for deep research.
In the FCI (Furnish Call/Charge Information) section, we add two parameters “callTag=” and “cause=”. Please refer to the CDR records as below.
“callTag=” parameter will be used to save the position where the call is released in miniSIPServer. We can know where and who release the call. For example, the call might be released because it received a BYE message from caller side, and so on. The tag value is an inner value and it will not be published to customers.
“cause=” parameter is used to save the cause value. If miniSIPServer receives 4xx or 5xx messages from the called side, and there is “Reason” header which has ’cause’ parameter, miniSIPServer will use this value to release the call,otherwise, miniSIPServer will use inner cause value. And of course, this parameter will be saved in FCI of CDR records.
By default, miniSIPServer opens UDP port 5080 to receive call-back message to invoke calls. If miniSIPServer is deployed in public network, it is possible to receive lots of other UDP packages. Of course, we can configure “application server address” for IP address authorization, but unfortunately its default value is blank and it could be dangerous.
So we update call-back service to protect the system and refine its service logic. Please refer to the configuration window firstly.
(1) The default value of “Application server address” is changed to a local loop address “127.0.0.1”, so outsides UDP packages will be disabled. Of course, we can still keep it to be blank to accept all packages from any address, but we suggest not to do that.
(2) Local listen port can be zero which is used to close UDP socket. If the port is zero, miniSIPServer will disable the whole call-back service since it is impossible to receive any outsides UDP packages now. If you don’t use call-back service, it is better to set it to be zero.
(3) Cancel “external line mode” item. Some cutomers always ask us what it is and always confused with this item. It is just to add ‘out group prefix” automatically before the called numbers in two sessions. In fact, it is not flexible if we want to call local users and outsides users at the same time. So we discard it, if we want to call outsides users, we can add ‘out group prefix’ manually in the REQUEST messages. That means application server should be responsible for the numbers format and dial plan result.
In normal, we configure ringing group information in local users’ profile. And one user can only be assigned to one ringing group. It works in most scenarios.
As you know, it is hard time now. Some companies reduce their human resources to save cost, so someone has to take more works. For example, it is possible that someone could be assigned to several ringing groups at the same time. In fact, some customers have requested us to fit this requirement.
We understand that completely, so miniSIPServer is upgraded to have a new method to provide ringing group service.
Two independent tables are added. One is used to define ringing groups and their users. Please refer to below figure.
Another table is used to detect ringing groups according to called numbers in different calls. Please refer to below figure.
Service document has been updated. Please click here to get more details about this new feature.
Sometimes we need to use customized resource files, such as audio files, special IVR flows, certificate files and so on. With previous versions, all these files are stored in miniSIPServer install directory or its sub directories.
It could be a management problem when trying to uninstall or upgrade miniSIPServer. We have to be very careful to backup our own resource files.
V38 (build 20210108) is released to refine this. Customized resource files are separated to be stored in independent directories which are in application data directory.
For example, customized audio files will be stored in ‘custAnn’ directory. Once miniSIPServer is uninstalled or upgraded, these audio files will be kept without any affection.
When deploying a VoIP network, we often have one-way or no-way audio problems. It is caused by private network, for example, some SIP phones or miniSIPServer are behind routers and other SIP devices are in another different network which could be a private network or public network.
To resolve such problem, we often suggest to configure “forwarding ports” in routers manually. If you are familiar with routers, it is easy to do that.
But someone might not know how to do that, or someone might make mistake in router’s configuration. So we add a new feature in miniSIPServer to help that.
It is UPnP (Universal Plug and Play). UPnP can help miniSIPServer to map necessary ports automatically.
Firstly, you need confirm that your router can support UPnP and it has been enabled.
Then, you can click menu “Data – System” in miniSIPServer and enable the item “Enable UPnP to ask router to map ports”. Please refer to following figure.
By default, miniSIPServer will map SIP (over UDP) port and audio ports for relaying audio streams.
In another way, there is a limitation in routers. Most routers limit the number of UPnP ports, for example less than 30 ports. So if you are deploying a miniSIPServer for 50 clients or more, you will still have to configure “forwarding ports” manually.