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.
For example, if this item is selected, the authorization name will be “+firstname.lastname@example.org” 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.
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.
This feature was merged to the latest V25 (build 20160126).
Some special SIP devices, for example embeded devices in automaticated system, don’t have full SIP capabilities, they can make or receive simple SIP calls without account and password authorization. They even cannot send REGISTER messages to MSS to update their own status.
Yep, we can configure them as “SIP trunk” in MSS. but it will lost several key features, such as ringing-group. In some scenarios, customers hope to ring all such devices together, so we have to treat them as “local users”.
To fit these requirements, we add “IP address authorization” in local user’s configuration. That means MSS will not require SIP phones/devices to register them firstly, and will not check their account and password if their messages are from specific or configured IP addresses. Please refer to below figure for more details.
By the way, we update openAPI document according to the latest V25. If you are interesting in it, please refer to openAPI document.