Sometime, we may fail to make outgoing calls through SIP trunk if its service provider has some problem, such as no enough resources, and so on. If customers configure several SIP trunks and they are from different service providers, we can configure miniSIPServer to try another SIP trunk to continue outgoing calls.
In the SIP trunk “outgoing call” configuration, please configure a chained SIP trunk described in below figure.
Previous miniSIPServer has a trace tool which is “trace all”. It can capture and trace all SIP calls which MSS receives or sends out. This tool is very useful when we build the VoIP network at the first step. But it is almost useless in an exist working environment.
It is dangerous to capture ALL SIP calls in a working system since there are too many SIP messages and inner information. By default, we can filter the call according to caller number or called number. In the recent V33 version, we disable “trace all” and replace it with “trace on IP address”. Please refer to following figure.
With this tool, we can capture a specific complete IP address, such as “10.0.0.101”. We can also set a part of IP address to capture some SIP calls from some IP addresses, such as “10.0.0”, in this scenario, all SIP calls from IP addresses begin with “10.0.0” will be captured. By the way, we can also set IPv6 address with this tool.
Now you can see this tool can be used in both lab environment and working environment.
We often configure miniSIPServer to connect VoIP carriers’ network with external lines. There are lots of VoIP carriers and someone always asks us how to configure external line.
In our step by step document, we give a demo to configure MSS to work with “call centric”. You can refer to this document for more details about VoIP networks and external lines. In another way, we give some more examples in chapter “External lines” of F.A.Q document. Please refer to these documents if you are interesting in it and hope they can be helpful to you.
https://www.myvoipapp.com/docs/faq/index.html
It is perfect to run miniSIPServer on Ubuntu 18.04 which is the latest LTS version.
We have tested some scenarios with miniSIPServer on Ubuntu 18.04, everything is OK. We strongly suggest you to upgrade your Ubuntu system to this version.
In some VoIP scenarios, we need configure “SIP trunk” to work with VoIP providers or gateways. When processing media streams, we hope (1) local users/phones should process their streams by themselves without MSS, and (2) MSS should help to relay media stream for all outgoing calls to peer SIP servers or gateways.
To fit these requirements, we update MSS V32 to be able to configure “relay media” item in “SIP trunk”. Please refer to following figure for more details.
By the way, MSS can only relay audio streams at this time, so video streams will be lost if you want to MSS to relay streams.
It has been two years since the first V24 was released. It is the second LTS version of MSS. Now it is time to say goodbye. The latest LTS version will be V32 and we will provide five years support for it.
V32 will base on current stable version which is V31. We hope to do enough test on V31 as much as we can, so we decide to remove V24 linker from download page and only keep V31 linker. According to our test and customers’ experiences, V31 is very stable now. It will be a good choice to install or upgrade previous MSS to this version.
V32 is on the way and will be released in the beginning of 2018.
We released the final V31, that means we will be focus on next very important version V32 which will be our next LTS version to replace V24.
In fact, lots of features have been merged into the latest V31, and we will stay with V31 for several months since it is the base line of V32. Please refer to following sections for more details about the key points.
In Windows platforms, we upgrade several important tools for V31. The VC++ is upgraded to VC2010, so new MSS is using VC2010 run-time libraries. It could be powerful and better than previous VC2008 which has several manifest problems in customers’ environments.
The basic SSL library is migrated from OpenSSL to LibreSSL in MSS for windows. In Linux system, we still keep OpenSSL at this time and will move to LibreSSL in future. LibreSSL provides official windows library and we think it is optimized to be better than OpenSSL. If you are deploying “SIP over TLS”, this modification could be much better and safer then previous versions.
In recent days, we work with several customers to process scenarios with different IMS networks. We have to say we met several strange and very old SIP call flows. That’s ok, V31 is refined to fit these requirements.
“18X with/without SDP” flows are supported. “18X” means 180 or 183, so you can see several possibilities, such as “180 with SDP”, “180 without SDP”, “183 with SDP”, “183 without SDP”, and so on, and their orders are different. Sometimes we receive 180 firstly, sometimes we receive 183 firstly. In most scenarios, these messages are used to play different ring-back tone, so it is not only something with SIP stack but also something with media connections which means MSS inner MG module is upgraded too.
Another key point is SIP-UPDATE. Some IMS networks don’t use 18x to bring ring-back tone media information, they use SIP-UPDATE messages. In another IMS network, we find it use “SIP-UPDATE without SDP” to keep alive in dialog. It is an interesting topic and we hope to write another blog to describe these scenarios carefully. Anyway, V31 is upgraded to support part of SIP-UPDATE to work with such IMS networks. We don’t implement all features about SIP-UPDATE and MSS will not invoke SIP-UPDATE flow by itself. If MSS wants to change media, it always invokes reINVITE procedures.
“tel” number format is supported in V31. Traditional soft-switch networks could transfer this format to MSS when they work with PSTN networks. We don’t understand why these soft-switch don’t convert it to SIP URL. Now V31 can accept that. Of course, MSS will never send out such number format.
Yesterday, we helped a Chinese customer to deploy MSS to work with CTC IMS network. In this scenario, CTC IMS network has ZTE soft-switch (according to User-Agent header in SIP messages) , we need be careful to cooperate with it.
Since CTC provides user name and password for authorization, we configure “external line” in MSS to do that. Following sections will illustrate some key points.
By default, we often use “External line (account)” as authorization user name, but ZTE softswitch requires full URI format, so we need configure “The authorization ID should include address information” in external line. Please refer to following figure for more details.
For example, if this item is selected, the authorization name will be “+8612345678@gd.ctcims.cn” according to above figure.
If it is not full format, IMS network will return “403 Forbidden” messages to reject it. In fact, we think it is a bug in ZTE softswitch since there is “realm” and “domain” parameters in SIP authorization header. No matter the user name is full format or not, the device should pass it according to successful authorization itself.
Anyway, if you have same problem to cooperate with other IMS networks, please pay attention to it and configure such item to take a try.
In Chinese CTC-IMS network, its “SIP server” is logic domain, not a real SIP device and cannot be visited. In above scenario, “gd.ctcims.cn” is its domain, not its real address. SIP messages should be routed to another device (we think it is a SBC or proxy), so we need configure “Via” address in MSS external line configuration. Please refer to following figure.
It is a good news to see that the latest Debian 9 is released. We have downloaded and tested it in our lab.
Debian 9 is very interesting. Since it is a stable version, it is important for us to run miniSIPServer on this system. We have to find that so many libraries and softwares have been changed or upgraded. Previous MSS versions cannot work on it by default.
We did lots of work to fix these conflict and upgrade MSS to V31 (build 20170621). And we are exciting to announce that the latest versions can still work on previous Debian systems, such as Debian 7 and Debian 8. Everything is perfect now!
If you want to try Debian 9, please upgrade MSS to the latest V31. And please refresh the document for more details about libraries.
RFC3262 defines a method to provide reliable provisional response messages in SIP dialog. Simply, it uses a new message which is PRACK to response “response” messages. We don’t think it is a good idea, and most traditional VoIP devices don’t following this RFC document.
But now in some interoperability scenarios with the PSTN, it is required to provide RFC3262 capability. Specially in some 4G-IMS networks, for example, in China telcom markets, mobile carriers’ networks will reject SIP calls if they don’t have this capablity.
So we upgrade MSS to V31 to support RFC3262. New MSS will add ‘100rel’ in outgoing calls to update peer sides or SIP phones that it has RFC3262 capability, they can decide to invoke it by themselves. For incoming calls, MSS will not invoke RFC3262 procedures automatically unless peer sides or SIP phones require that.
If you have problem to work MSS with your local ISP networks, please try the latest MSS and hope you can enjoy it.