Browsed by
Category: miniSipServer Cloud

PBX in cloud for small business

Critical Maintenance for CPU Vulnerabilities

Critical Maintenance for CPU Vulnerabilities

Maintenance is required for all virtual servers in our cloud system. We will reboot all our servers in 2018-01-19 7:00:00 AM UTC. You can prepare your VoIP networks for this mantenance.

This action affects the underlying infrastructure that your virtual server resides on and will not affect the data stored within your virtual server

During the maintenance window, your virtual server will be cleanly shut down and will be unavailable while we perform the updates. A two-hour window is allocated, however the actual downtime should be much less.

We regret the short notice and the downtime required for this maintenance. However, due to the severity of these vulnerabilities, we have no choice but to take swift and immediate action to ensure the safety and security of our customers. For these reasons, we must adhere to a strict timetable, and will not be able to reschedule or defer this maintenance.

If you experience any issues following the maintenance, please feel free to reach out to us and we will be happy to assist.

Connect to sonetel

Connect to sonetel

“sonetel.com” is a VoIP carrier who can provide local phone numbers. We can add “external line” to work with their servers. According to its description, there are some special items need to be cared:

  • Sonetel uses email address as SIP account and
  • It deploys SBC or proxy to process all incoming SIP messages.

Here we give a simplel example to describe how to work with Sonetel. We assume the SIP account is “abc@gmail.com”.

In MSS, please cilck menu “data > external line” to add a record.

Configure Sonetel lline
Configure Sonetel lline

In “Basic” tab, the line type should be “Connect to peer VoIP server”, the Account should be “abc” and the Domain is “gmail.com”.

By the way, the Password is the password you sign up in Sonetel, not your own email password.

Since all SIP messages are processed by sonetel SBC/Proxy, we need configure “outbound” information in the “Outgoing call” tab. Please refer to following figure.

Sonetel SBC
Sonetel SBC

The Sonetel proxy address is “sip.sonetel.com” which should be described in the email sent by sonetel.

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
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.

Modification of “one number” service

Modification of “one number” service

We upgraded miniSIPServer V30 today to change “one number, multi-devices” service in local user’s configuration. In previous versions, we don’t need configure anything to enable this feature in local user since it was enabled by default. Customers think it is good idea to reduce configuraiton workload, but it brings new management problem. In fact, they hope to be able to control which local users can have this feature. In most scenarios, only some local users have several phones with same number, others are not permit to do that.

To fit this requirement, we add a new optional item in local user’s configuration. Please refer to following figure for more details. By default, this service is not enabled now until you configure it obviously.

One number service right in local user's configuration.
One number service right in local user’s configuration.

This modification is applied to cloud MSS too.

Operator services

Operator services

We added two traditional PBX services in new MSS version: operator break-in and operator overstep. Please refer to service document for more details.

Both local-MSS and cloud-MSS have been upgraded for these services. The latest MSS version is V29 now.

Next local MSS version will be V30 and we will focus on refining media gateway functions. If you have any suggestions or requirements, please update us and we are very glad to discuss with you.

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.

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.

Some virtual servers changed

Some virtual servers changed

Some virtual servers in cloud-MSS system have been changed, please pay attention to these items.

STUN server

Each virtual SIP server will enable STUN feature. For example, if the SIP server address is “1234.s1.minisipserver.com”, its STUN server can also be the same address. That means “1234.s1.minisipserver.com” is also its STUN server address.

Now we suggest “stun.minisipserver.com” by default. It is a simple public STUN server for all virtual SIP servers. Of course, you can still configure your virtual SIP server address as your STUN server.

SMTP server

In voice-mail feature, we need a SMTP server to send emails with attached audio files. Each virtual SIP server can be configured with customers’ own SMTP servers. But we find it could make several problems. For example, most customers try to use Gmail SMTP server. Gmail SMTP server requires that you need enable POP/SMTP firstly, and grand other access. Most customers don’t know how to do that.

So we disable SMTP server configurations. All voice mails will be sent from our own SMTP server.  Most important is that you will need check your spam box if you cannot find voice email in ‘inbox’.