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.
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.
miniSIPServer can support customers’ own audio files to replace default files. With previous MSS, customers have to backup and restore these files once they want to upgrade MSS.
This is a little trouble. With the new V32, we can resolve it now.
When MSS starts up, it will create a sub directory ‘cust_ann’ in ‘mss_ann’ directory, now all your own audio files can be stored in this directory. When MSS is uninstalled or upgraded, this directory and its files will not be deleted or replaced by default files, and MSS can get audio files from this directory directly when it starts up.
In windows system, it could be “d:/myvoipapp/minisipserver/mss_ann/cust_ann” directory by default. In Linux system, it could be “/opt/sipserver/mss_ann/cust_ann/”.
Please refer to our online document for more details about how to record own audio files.
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 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:
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.
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.
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.
Some customers have several office branches and hope to establish VoIP connections between them. There are several methods to do that. Here we give an example to describe how to establish voip connections between two MSSes with SIP trunk feature.
2. Network topology
The network topology is simple. There are two office branches. Please refer to below figure.
Before we setup voip network, it is better to assign extension numbers. Different office numbers will effect how to configure call routing in both MSSes. In above figure, we can see the extensions in office 1 are 1xx, and extension numbers in office 2 are 2xx.
Both MSSes are configured with public IP address. If your MSS is behind NAT or router and you want to provide connection for outsides users, please refer to another document firstly.
Now we give detail configurations for it.
In below configurations, items should be kept their default values if we don’t configure them obviously.
Please click menu “data – SIP trunk”, then add a record:
SIP trunk ID = 1
Description = to MSS2
Server address = 10.23.x.x
Please click menu “dial plan – analyzed called number” , then add a record for routing 2xx to such SIP trunk.
called number prefix = 2
route type = SIP trunk
SIP trunk ID = 1
It is almost same with MSS1.
Please click menu “data – SIP trunk” to add a record.
SIP trunk ID = 1
Description = to MSS1
Server address = 41.32.x.x
Please click menu “dial plan – analyzed called number” for routing calls to above SIP trunk.
called number prefix = 1
route type = SIP trunk
SIP trunk ID = 1