Browsed by
Tag: sip

Say goodbye to V24

Say goodbye to V24

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.

Final V31

Final V31

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.

Tools upgraded

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.

SIP stack upgraded

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.

Work with Chinese CTC IMS network

Work with Chinese CTC IMS network

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.

Authorization user name

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.

Authorization user name
Authorization user name

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.

Proxy

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.

SIP proxy in IMS
SIP proxy in IMS
miniSIPServer on Debian 9

miniSIPServer on Debian 9

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

RFC3262

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.

Concurrent calls of SIP trunk

Concurrent calls of SIP trunk

By default, MSS previous versions don’t limit concurrent calls of SIP trunk. That means you can make or receive calls as much as you can. If peer sides don’t have enough resources, they will reject calls by themselves. But now in some scenarios, customers hope MSS can handle concurrent calls and limit them automatically.

To fit this requirement, we upgrade MSS to provide concurrent calls configurations in SIP trunk. Too much calls will be rejected by MSS itself. Please refer to following figure for more details about these items.

Concurrent calls of SIP trunk
Concurrent calls of SIP trunk

Please pay attention to these.

(1) These items are independent. You can configure different values for them to limit different concurrent calls for outgoing calls and incoming calls.

(2) If one of them is zero, in fact all them can be zero, that means only incoming calls can be received, or can only make outgoing calls outsides.

Citel Technologies, Inc. Announces Interoperability with MyVOIPApp miniSIPServer

Citel Technologies, Inc. Announces Interoperability with MyVOIPApp miniSIPServer

AMHERST, NY and ShenZhen, P.R. China — August 4, 2016 — Citel Technologies, Inc., is pleased to announce that it has successfully completed interoperability testing with MyVoIPApp’s miniSIPServer, a software-based SIP PBX, designed for small and middle size companies, miniSIPServer is very easy to use with rich features and can work on multi-platforms, such as Windows and Linux whilst also fitting both IPv4 and IPv6 networks.

The Portico™ TVA™ offers companies the means to migrate their customers to VoIP without the unnecessary burden of ripping and replacing existing cabling infrastructure, purchasing new IP phones and installing Power over Ethernet switches. Customers can retain their existing digital, analog and Centrex phones without removing the existing switches by SIP enabling those phones through the use of the Portico™ TVA™.  This is a quick and cost-effective means of VoIP migration.

“Used together, the two innovative solutions provide companies with the fastest and most cost-efficient means to upgrade from legacy systems to modern Unified Communications,” said Ian Gomm, VP of Sales & Marketing for Citel.

Citel and MyVoIPApp kicked off interop testing with miniSIPServer at the request of a high-profile customer who was looking to use this Windows-platformed softswitch for a cross-country network of customer service training centres. “We have undertaken interoperability with many IP PBXs over the years, and know that sometimes some systems are easier than others to complete. MiniSIPServer was new to us, but I was really pleased to hear engineers’ initial feedback that the system was easy to work with and interop had gone smoothly” said Andrew Davies, VP, Engineering at Citel. He continued “Then they showed me some quite sophisticated presence monitoring and Busy Lamp Field functionality and I saw the product was a great fit with the Portico™ TVA™, wherever digital business phones were the preferred handset. We look forward to taking the relationship further.”

About Citel Technologies, Inc. (citel.com)

Citel enables SMBs, large enterprises and service providers to realize the cost and productivity benefits of IP telephony while at the same time leveraging their existing PBX infrastructure. Businesses with single or distributed locations and PBX vendors can now deploy next-generation IP applications and services at their own pace, with minimal business disruption. Service providers can deploy Hosted IP telephony services quickly, without having to “rip and replace” existing enterprise PBX handsets and LAN cabling. Citel is based in Amherst, New York with offices in Loughborough, England (UK) and Toronto, Canada.

About MyVoIPApp (myvoipapp.com)

MyVoiPApp was founded in 2007, in ShenZhen, P.R. China. Although a small company its employees all have more than ten years experience in the field of communications and its focus on communication technology has facilitated strong growth and penetration in the VoIP marketplace.

Invalid CSeq number

Invalid CSeq number

One of our customers reported a problem that his external line was always offline with a voip provider. That’s very strange because “external line” is a very basic function of MSS and it works perfectly with lots of voip providers.

We captured the log and found the voip provider returned “400 Bad Request” message with following cause:

P-Registrar-Error: Invalid CSeq number

We checked the REGISTER messages, and think it is no problem in CSeq header. Following items are from MSS:

==>
REGISTER sip:sip.xxx.com SIP/2.0
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 13 REGISTER
...

<==
SIP/2.0 401 Unauthorized
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 13 REGISTER
...

==>
REGISTER sip:sip.xxx.com SIP/2.0
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 14 REGISTER
...

<==
SIP/2.0 400 Bad Request
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 14 REGISTER
P-Registrar-Error: Invalid CSeq number
...

We checked RFC3261 to find “CSeq” in SIP-REGISTER procedures:

A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID.

Obviously we are right. But why did peer side reject MSS’ messages?

Finally, we tried to send SIP-REGISTER with different ‘call-id’, and the problem was resolved! That made us confused again because in RFC3261 we can find the details of “call-id” in SIP-REGISTER procedures:

All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar.

We think the voip provider is unprofessional. Unfortunally, it is hard for them to upgrade their system. So we have to add a switch varant to control MSS to fit this kind of situation.

[sip]
gVarSipRegSameDialog=0

If you have the same problem with some voip providers, please add above parameter into “mss_var_param.ini” file and restart your MSS to enable it.

Anti SIP scanning

Anti SIP scanning

One of our customers reported that his extensions have been cracked. We checked its MSS CDR records. It seems someone has cracked one extension’s password and used this extension number to make lots of calls.

Obveriously, it is a very dangerous problem. We think this “hacker” might send lots of SIP messages to MSS to try such extension’s password. MSS previous version doesn’t consider this scenario and always permit the SIP phone to keep trying its password until it is authorized.

To stop this, we upgrade V26 to support “fail to ban (F2B)” feature. Once SIP phone has failed to check authorization for several times in one minute, MSS will detect it as “scanning” and ban its IP address for several hours. All SIP messages from such address will be rejected directly. Then it is impossible for “hacker” to crack SIP passwords.

This feature is enabled by default and need configure nothing for it.

miniSIPServer updated and say goodbye to webRTC

miniSIPServer updated and say goodbye to webRTC

miniSIPServer V25 is updated to fix some bugs and refine system to be more stable. The most important change is that we cut ‘webRTC’ feature from this version and abover.

As we described in previous post, MSS webRTC feature can work with Chrome navigator. Chrome is upgraded to V48 and make some changes to webRTC and doesn’t consider compatibility with previous version. We think maybe webRTC is perfect for public network services, such as Google hangouts, but it is not suitable or flexible for small or middle size enterprise communication markets.

So we cut it from V25, and keep it in V24. If you are using webRTC feature, please keep your Chrome to V47 or lower versions.