1.2.1 Back to Back User Agent

Back to Back User Agent (B2BUA) sits on the path from sender to receiver of the SIP requests. When the softswitch receives a SIP message from a client it regenerates that message and transmits it on to the destination as if it was coming from a client.  It just acts as a combination of both a User Agent Server (UAS) – receiving messages and as a User Agent Client (UAC) – sending messages further to the next hop. During the regeneration of the SIP message the softswitch can modify its headers and body and thus add value to the communication.

Participating in all call requests allows the B2BUA to perform a number of different roles. In voipswitch these capabilities are additionally extended by the authentication, routing and charging functions which belong to the call control unit – the logical part which open up possibilities for creating various VoIP services.

The picture below presents the SIP call path from the originating SIP endpoint to the destination SIP endpoint through the B2BUA.

Picture 3 B2BUA high level diagram

The two side blocks of the softswitch act as SIP User Agents. In an abstract visualization, as in the diagram, we can think of them as separate units which are state machines responsible for maintaining communication with the endpoints. When the answering UA receives a request, for example an INVITE, it sends an event to the call control unit which takes a series of decisions based on programmed logic and inputs from the UAs’ state machines and data from the voipswitch schema.

Admission control

Admission Control is a validation process where a check is performed before a connection is established.

Information about the endpoints is stored in the voipswitch database. On an incoming new request the control unit checks with the clients table if the endpoint requires authentication. Authentication differs depending on the client type and can be based on:

• Originating IP address – used mainly in server to server communication
• SIP username and password, digest authentication – the standard mechanism used for authentication of SIP endpoints, used in retail scenarios
• 2^nd stage authentication by PIN carried by the string of dial tones (DTMFs) or by the caller ID; this is a service authentication which occurs after the initial request has been authenticated by IP address or SIP digest. The transition from one client to another can be triggered only when the call is directed to the appropriate scenario in the routing plan (more explained in the Routing chapter)

If authentication is successful, the client is recognized and the flow moves to the next stage in which the following properties are checked:

• If the client’s account is in an active state,
• If the list of allowed codecs contains at least one codec offered by the client in the SDP,
• If the maximum number of concurrent calls for the account has not been exceeded.

A failure at any of the points will cause the softswitch to send an error SIP response.

If the above conditions are met, the next phase deals with the SIP address part from the TO header of the incoming packet. For each account you can define special rules whose purpose is to modify the address. The rules are string operations allowing for adding, replacing and removing a definable part of the address string. Different sets of rules are used for charging and for routing as the softswitch’s logic separates these functions.

The result of modifying the SIP address from the TO header according to the predefined charging rules must match an entry in the assigned tariff. Moreover, the entry has to be in a non-blocked state. If there is a match, the control unit learns the associated cost per a time unit, taking into account various tariff properties. Finally, it checks the account balance and calculates the time block for the call, i.e. the call’s maximum allowed duration.

An additional level of checks occurs if the client is identified as belonging to a reseller or is a subaccount of a UC/PBX account. In such a case the system checks also the properties of the higher level account and calculates the maximum time block for the call. 

In this phase the error responses may contain more meaningful information as to why the user is barred from accessing the service. For example, in the case when there are not enough funds the Payment required error is sent; if the destination is blocked on the tariff, there will be a service unavailable error.

Routing

The next phase decides on the routing for the dialed number. Again the SIP address from the TO header is manipulated according to the account’s routing rules and then the result is processed by the routing procedure. It should be emphasized that routing is completely separated from charging. This approach gives a lot of flexibility in service creation as you can offer different pricing for each user even though they use basically the same service, or just the opposite, have the same pricing but different routes for various groups of users. There are many more examples which we will explore.

The routing procedures try to match the obtained address with a destination. The destination can be a voipswitch internal service or an external SIP endpoint. Voipswitch’s service is, for example, voicemail or IVR based scenarios. For those services the softswitch itself is the final SIP destination. The other group of destinations is SIP endpoints, which are divided by their type into:

• User endpoints
• Gateways
• Registrars

A user endpoint is a client’s terminal which acts as a UAC (User Agent Client), whereas the voipswitch acts as a UAS (User Agent Server).  The voipswitch maintains the location service through registration, keeping information about the current IP and port of each registered endpoint.

The gateway type is an endpoint which acts as a UAS to which voipswitch sends requests. It can be a SIP proxy or a PSTN gateway which allows us to connect the VoIP realm with GSM or landline telecom services. As the term gateway is widely used among service providers we decided to stick with it even though it is not precise. In this scenario voipswitch acts as a client. Its requests are authenticated by the remote gateway by IP address or by username and password, which can be set in voipswitch per each gateway.

Another type is registrars. Similarly with the gateways voipswitch acts as a client. In addition, the softswitch has to register to the remote registrar. This scenario is very rarely used in carrier to carrier relations.

The routing mechanism is equipped in many tools which allow for enhanced address manipulation, connecting to lookup services and performing other actions which will be explained in greater detail later.

If the request is an INVITE to a media session, the routing is also responsible for ensuring that the destination endpoint has sufficient resources. It compares the destination codecs with what was offered by the client and also checks if the transcoding facility is available.  Based on this information the softswitch constructs a response and establishes dialogue with the originating SIP endpoint.

Charging

Chargeable services made by the softswitch include both calls and messages. There are also other billing processes responsible for charging other products like DIDs, subscriptions, time plans and others – one time or reoccurring. They are, however, not related to the softswitch call processing and will therefore be omitted from this chapter.

SIP MESSAGE requests are charged, like calls, based on the rate per destination address in the assigned tariff. The rate is per message and is deducted from the client account the moment it arrives.

For calls the charging function is triggered by the session establishment event, i.e. when the destination endpoint responds with 200 OK. The call ends when it is terminated by either of the endpoints (BYE) or if the maximum duration of the call is reached. The maximum duration is a time block calculated based on the assigned tariff and its attributes (including plans). Even if the account is a postpaid billing type, there is a safety credit limit set by the provider. When the call ends the charging function calculates the exact duration and debits the account’s balance or deducts time from a calling plan.

If the account is under a reseller, the same processes take place on each level of resellers as the system controls real-time usage.

Topology and user identity hiding

As B2BUA participates in all requests and responses between endpoints it can thus hide information about the network topology and user details from each other. This feature is required in VoIP services as the carriers with whom we exchange traffic must not know any details about our clients. This is also a basis of the Session Border Controller (SBC) which is a form of B2BUA. When a request is sent from the softswitch to a remote server it comes with a username, FROM, Display Name and other information as configured by you, not that which was sent by the originating client. 

The softswitch can act as a proxy not only for SIP packets but also for RTP packets (media streams). The proxy mode, either full or SIP only, can be configured per route. For example, you may want to proxy RTP when sending traffic to external networks but let the media go directly from a client to a media server in your network. 

ICE and NAT handling

In retail business you will have to deal with endpoints located behind different kinds of NATs. The softswitch supports three methods of handling this situation:

• Checking if the IP presented in the SDP is from a private network ranges; if so, then the packets will be sent to the IP and port from which the RTP packets from the client arrive instead
• STUN – the softswitch acts as a STUN server and responds to clients with information about their reflexive IP and port,
• ICE

If you plan to offer user to user audio and video calling services (like our RCS softphones) then ICE is the right choice.

ICE is the best mechanism for finding the most efficient path for RTP. It tries to establish a peer to peer connection which in general succeeds in more than 98% of cases. If a direct connection cannot be set up, then it fails over to the path through a media relay server (TURN).

Media handling

The voipswitch can be configured to work either in RTP proxy mode or signaling only proxy mode. You can select how the media will be handled for that particular route in the routing plan.

In the full proxy mode the SDP content is modified so that the originating media IP addresses and ports are replaced with voipswitch’s ones. The two endpoints do not send media directly; instead the RTP packets come to the softswitch first and from there are sent to the destination.

The softswitch can also modify the codecs list in the SDP by changing their priorities or narrowing the set of allowed codecs. If the transcoding module is enabled, then the list of codecs sent from the client can be extended in order to match the codec supported by the destination. In such a case there is another element in the RTP flow, namely the Voipbox acting as the transcoding server.

In the signaling only proxy mode the SDP sections pertaining to the media information and addresses are left unchanged. Still, the other sections may be cut before sending further. The SIP requests are routed through the softswitch but the media path will be direct between two endpoints. This approach, although useful in certain scenarios, should not be applied for retails services as there is no provisioning for NATs and firewalls; instead you should use the ICE/STUN/TURN mechanism described in a further part.

More on the supported flows can be found in the Routing chapter.