1.4.5 Advanced options
The Advanced tab groups the additional options that can be set per client account.
Play server ringback – off by default and recommended not to change it. When on, the voipbox generates own fake ringback tone played from a file. The ringback is sent to voipswitch and then to the client. It can be used when a termination gateway for some reason cannot send own ringback tone. In such cases however it is better to leave playing the tone to the client endpoints as most of them can play own local ringback tone on receiving SIP 183 response.
Enable transcoding – allow for transcoding service. For example when the client sends a call in a codec that is not supported by the termination endpoint. The system, in such case, allows for establishing the call with different codecs and automatically puts the stream through the transcoder server.
Calls limit – allows to define the limit in number of concurrent calls the client can make
FROM header parameters manipulation
FROM and Display name – allows for modification these two parameters which are in the FROM header in SIP requests. The header describes the initiator of the request. It consists of the SIP URI for example 1234@mydomain.com, which is the client login (user) and domain or IP of the server, and optionally the display name which carries a friendly name for example Peter.
FROM: “Peter” sip:1234@mydomain.com;
The receiving endpoint should use the Display name to show as the caller ID (if Display name exists). When a call is terminated in PSTN network it can happen that even if Display name is set the user of the SIP URI part will be presented as caller ID. In such case you should replace the user part with Display name in the Routing plan’s Field rules option.
Voipswitch enables modification of the user part of the SIP URI and the Display name. Click on the extended menu button on the right. A new window will appear which allows for changing the prefix, adding suffix and controlling the length of the parameter.
Dialed number manipulation
The dialed number specify the recipient of the request. Despite the used name it does not have to be a number, just any string that is the user identifier – the user part of the SIP URI. This parameter is carried in the TO header of SIP request.
In voipswitch the dialed number is used in two functions:
- Routing – the dialed number is matched against the routing plan in order to find the next hop for the request
- Billing – the dialed number is matched against the client’s tariff to find appropriate rate if the request is a chargeable event (call or message)
The dialed number parameter can be changed for each of the functions separately. Thus it is possible to use a different number for further routing and different for charging.
For example a client who signed up for a premium service has a tariff with rates in E164 format that is beginning with country codes. His calls are sent to the softswitch also in E164 format (his UAC takes care of converting the number dialed by the user to E164). We want however that his calls will go thru premium routes which offer better quality than standard routes. The premium routes are grouped in the routing plan under only one entry as all the destinations (country and area codes) should go to one carrier only. It is the case when we do not do any LCR for the service. The entry’s name is “premium”. To have the routing process match the dialed number with this entry we have to modify the dialed number i.e. the number that came from the client’s endpoint.
At the same time we do not want to change all the rates in the tariff to match the modified number.
To address this problem the two separate procedures for changing the dialed number were introduced:
Dialing rules – the rules provided here will be applied only to the number which is passed to the routing function.
Tariff rules – the rules from this field are taken into account only by the billing function.
TODO diagram pokazujacy te zmiany I przejscia do billing I routing
This approach introduces great flexibility in various scenarios. As in the above example we can keep the same rate sheets while using different routing.
The rules for modifying dialed number are also very useful as they allow to use uniform rates and routing format even though the clients send calls in various formats i.e. with international dialing prefixes (+,00,011) or some special prefixes. We can easily strip such prefixes when they hit softswitch but also we can do much more. The detailed explanation on using modification rules is described in Header strings modifications chapter.
Codecs
In this section you can specify allowed codecs for different types of media – audio, video and fax.
For each type you can add codecs in the allowed codecs multiple choice list. If the client’s endpoint sends SDP with the list of codecs only those which are in the allowed list will be taken into further negotiation with the destination endpoint.
The primary codec will be put as the preferred one on top of the codecs list in the SDP sent to destination.