The RCS platform uses the client based routing, which is also referred to as local dialing plan. The RCS client uses the routing plan to determine its location server (home server) and to determine the servicing server for calls and messages addressed to particular user.

The home server is a voipswitch to which the client registers. Also by default all requests related to presence i.e. Publish and Subscribe are sent to the same server.

The servicing server is a voipswitch to which INVITE and MESSAGE requests addressed to certain SIP URI in the request line are sent to. Depending on the URI the requests can be sent to different servers. In a single server deployment one voipswitch can act as both home server and servicing server. In a cluster solution you can split the traffic among many servers using the client routing.

Finding the home server

When the RCS client starts first downloads the routing plan from the EMCD. The EMCD reads the plan’s entries from the api.local_dialing_plan table and creates a json list which consists of one or more records with two columns – prefix and SIP server FQDN.

The RCS client looks for the entry with prefix value best matching the user’s SIP login. When the entry is found the respective SIP server is then used as a home server. The client will store this information and will keep refreshing the local dialing plan periodically. Also when registration fails it will try to update the list from EMCD.

Routing calls and messages

Before the INVITE request is sent the client tries to find best matching entry in the local dialing plan for the user part of the request line URI. For ONNET calls it will be the SIP login of the called user. If we use special prefix for onnet calls then the SIP login will be preceded by the prefix in the URI. This procedure is repeated for every call. If you call user A the client will find a matching route, if then you call user B the system will look for a route again, this time for user B.

Thus you can divide the traffic among many servers. Or you can have the servers in different locations and distribute the traffic based on the country code – in the case when logins are phone numbers.

Example:

Prefix	Sip server
44	sip1.company.com
47	sip1.company.com
3	sip2.company.com
int	offnet.company.com
1	sip3.company.com
2	sip3.company.com
4	sip3.company.com
5	sip3.company.com
6	sip3.company.com
7	sip3.company.com
8	sip3.company.com
9	sip3.company.com

Local dialing plan

If a user has a login which is a phone number and it starts with 44 the application will register to SIP server with address sip1.company.com

If the user wants to call another user with SIP login starting with 3 for example a French number, the INVITE will be sent directly to the server sip2.company.com

OFFNET calls are configured to be sent with prefix int, therefore the application looks for the prefix beginning with int and finds the server offnet.company.com

If you have one server for all prefixes enough is just to create entries from 1 to 9 and point to the same address.

Note: if you allow for alphanumeric SIP logins (usernames) you should use a prefix for ONNET calls. For example a prefix “onnet” which will be added to each outgoing SIP login. Before placing a call the softphone will look for a prefix beginning with onnet, thus you can avoid adding all the entries for all allowed characters. The example below shows a dialing plan with two prefixes only.

Prefix	Sip server
onnet	sip1.company.com
offnet	sip2.company.com

Browser not supported