This chapter describes the Oracle Communications WebRTC Session Controller Lightweight Proxy Registrar and how to configure it.
You need to perform the tasks in this chapter only if you intend to use the Lightweight Proxy Registrar. If you will not use the Lightweight Proxy Registrar, you can skip this chapter.
The Lightweight Proxy Registrar introduces a layer between the WebRTC Session Controller Signaling Engine and the Proxy Registrar. The Lightweight Proxy Registrar reduces resources consumed in the Proxy Registrar, which reduces overall cost.
WebRTC-based clients come and go as people open and close their browsers. Each WebSocket connection to WebRTC Session Controller triggers a SIP registration. A single user often has multiple devices, which equates to multiple endpoints and requires more register and unregister requests. These factors make the number of registrations at any time difficult to predict, making it harder to plan needed resources. Any cost associated with registration might not be well known and could be problematic.
The Lightweight Proxy Register addresses these problems in one of two ways:
Multiplexing registration requests from many WebRTC endpoints into a single SIP registration per user
Managing all registrations, leaving no registrations for the Proxy Registrar. In this case, an external system must route inbound calls to WebRTC Session Controller, for example, by using static routes based on the domain.
Customers who do not want or need a SIP or IMS integration do not need to use them This case is suitable for an enterprise that only wants to connect WebRTC endpoints.
The Lightweight Proxy Registrar forks inbound and outbound calls, or SIP INVITE messages, to multiple connections.
WebRTC Session Controller operates in three modes:
Normal: The Lightweight Proxy Registrar is not part of the call flow, which means that every WebRTC endpoint will trigger a unique SIP registration towards the proxy registrar. This is the default behavior.
Single: The WebRTC Session Controller Signaling Engine sends REGISTER requests to the Lightweight Proxy Registrar, which tracks and forwards only the first registration per user to the Proxy Registrar. Likewise, the Signaling Engine sends a de-registration message to the Proxy Registrar when the last registration for a user is removed.
Static: The same as Single mode except that no registrations are sent to the Proxy Registrar. You can use this mode when IP Multimedia Subsystem (IMS) integration is not required, although you can use this mode with an IMS integration. Two possible cases for using this mode are:
You do not want or need SIP or IMS integration, such that only WebRTC endpoints can communicate.
You want to completely offload all registrations, but still be able to route calls to and from WSC using, for example, static configured routes.
For requests that originate from WebRTC endpoints, you can configure the WebRTC Session Controller to operate in one of the following modes:
Always: WebRTC Session Controller forwards outbound requests to a remote proxy and does not use the Lightweight Proxy Registrar
Conditional: if one or more WebRTC endpoints exist in the registrar repository, the Lightweight Proxy forks the request locally. If no endpoint exists, the request is routed to a remote proxy.
Never: The Lightweight Proxy handles all requests internally and WebRTC Session Controller never routes requests to a remote proxy. If no endpoints exist in the registrar repository, the Lightweight Proxy Registrar responds with the error: 404 Not Found.
The Lightweight Proxy Registrar consists of the following components:
Lightweight Registrar
The Lightweight Registrar maintains the list of active bindings in the Location Service, propagates requests from WebRTC endpoints, propagates REGISTER requests or responses to and from the external registrar, and determines the registration mode based on the registration mode configuration.
Lightweight Proxy
The Lightweight Proxy processes both inbound and outbound call setup attempts by forwarding and, optionally, forking SIP INVITE requests.
Location Service
The Location Service maintains information about the location of the called party.
Custom Application Router
The Custom Application Router is called by the container to select which SIP servlet application will service each initial request.
The Lightweight Registrar is triggered by SIP REGISTER requests and responses. It takes the following actions:
Maintains the list of active bindings per Addresses-of-Record in the Location Service, based on the Contact headers and expiration intervals in the requests or responses from the external registrar.
Only propagates requests received from WebRTC endpoints based on the registration modes. It does not generate any re-register requests or maintain any timers.
Propagates REGISTER requests or responses, without modifying them, to or from the external registrar. Transparently forwards any authentication or authorization headers between the external Proxy Registrar and the WebRTC Session Controller Signaling Engine. The last REGISTER request in Single mode, however, is changed by the Lightweight Proxy Registrar to include exactly the same Contact header(s) as the first REGISTER request for the sake of removing the bindings correctly in the external Proxy Registrar.
Determines the registration mode based on the registration mode configuration.
The Lightweight Proxy is triggered by both inbound and outbound SIP INVITE requests.The Lightweight Proxy sets up both inbound and outbound calls by forwarding and, optionally, forking the SIP INVITE requests.
The Lightweight Proxy takes the following actions:
Forks INVITE requests to multiple WebRTC endpoints based on the bindings information in the Location Service. The called party address-of-record for the subscriber lookup is based on the To header of the INVITE request.
Forks the call in parallel if it finds one or more bindings. Otherwise, it forks the call to the outbound Proxy or responds with an error, depending on the forking mode. If no WebRTC endpoint for the called party corresponds to the address-of-record, the Lightweight Proxy responds with the error: 404 Not Found.
Determines the forking mode based on the Forking Mode Configuration. In Always mode, the Custom Application Router filters out requests.
The Lightweight Proxy uses the Location Service to obtain information about the possible location of the called party. The Lightweight Registrar maintains the information as a result of processing the REGISTER message.
The Location Service contains a lookup table of the bindings between the address-of-record keys and registration records. Each record represents one or more contact header addresses, which have been received from prior registration requests from WebRTC endpoints. Data is kept in memory, replicated across the WebRTC Session Controller servers, but is not written to disk. This means that a full cluster restart clears all data because a cluster restart means all WebRTC sessions are gone.
Table 7-1 represents an example of a lookup table that contains three records.
Table 7-1 Example Lookup Table
| Address-of-Record | Registration Record |
|---|---|
|
alice@example.com |
<instance-id1, reg-id1> = <alice-contact1, expires=t1> <instance-id2, reg-id2> = <alice-contact2, expires=t2> |
|
bob@example.com |
<instance-id3, reg-id3> = <alice-contact3, expires=t3> <instance-id4, reg-id4> = <alice-contact4, expires=t4> <instance-id5, reg-id5> = <alice-contact5, expires=t5> |
|
alice@otherdomain.com |
<instance-id1, reg-id1> = <alice-contact6, expires=t6> |
The Lightweight Proxy Registrar supports the association of multiple subscriber identities with a registered address-of-record. For example, subscriber Maria could have identities of maria-home, maria-work, and maria-mobile. If she connects as both maria-home and maria-mobile, each with different SIP contact addresses, the Lightweight Proxy Registrar stores these relationships and associates them with subscriber Maria. If an inbound call generates an INVITE message for maria-home, the Lightweight Proxy Registrar retrieves all of Maria's registered identities and forks an INVITE to maria-mobile as well.
To configure the Lightweight Proxy Registrar, you set the SIP registration mode and the proxy forking mode through existing Groovy scripts. Beyond that, the Lightweight Proxy Registrar acts appropriately based on the SIP messages it receives.
The default registration mode is Normal, which indicates the Lightweight Registrar is not used and all registration requests are sent to an external registrar. You set the registration mode only if you want to change the default mode or change the registration mode you previously set. To configure the registration mode:
Log in to the WebRTC Session Controller console using your user name and password.
Select the Packages tab.
Under Package Name, select register.
Select the row with these values:
Direction: FROM_APP
Verb: connect
Type: request
Click the Edit button.
In the Groovy Script section, locate the line that begins with the following text:
sipReq.requestURI = context.sipFactory.createSipAddress(Constants.PROXY_SIP_URI).URI
Modify the value of sipReq.requestURI as follows, based on the mode that you want to use:
Static mode:
Replace the Request-URI with a URI corresponding to one of the local SIP listening interfaces. For example:
sipReq.requestURI = context.sipFactory.createSipAddress("sip:127.0.0.1:5060").URI
Single mode:
Specify the outbound proxy in the Request-URI and push an additional Route header by adding the def route entry to specify one of the local SIP listening interfaces. This header indicates that the Lightweight Proxy Registrar should be visited prior to the outbound proxy, depending on the forwarding decision by the Lightweight Proxy Registrar:
sipReq.requestURI = context.sipFactory.createSipAddress(Constant.PROXY_SIP_URI).URI def route = context.sipFactory.createSipAddress("sip:127.0.0.1:5060;lr") sipReq.pushRoute(route)
Normal mode:
No changes are required for Normal mode.
The default forking mode is Always, which indicates the Lightweight Proxy is not used and all requests are sent to an external proxy. Set the forking mode only if you want to change the default mode or change the forking mode you previously set.
To configure the forking mode:
Log in to the WebRTC Session Controller console using your user name and password.
Select the Packages tab.
Under Package Name, select call.
Select the row with these values:
Direction: FROM_APP
Verb: start
Type: request
In the Groovy Script section, locate the following lines:
def route = context.sipFactory.createSipAddress(Constants.PROXY_SIP_URI + ";lr") sipRequest.pushRoute(route)
Modify the lines as follows, based on the mode that you want to use:
Conditional mode:
Specify the outbound proxy route and push an additional Route header that contains one of the local SIP listening interfaces. The header indicates that the Lightweight Proxy Registrar should be visited prior to the outbound Proxy, based on the forwarding decision made by the Lightweight Proxy Registrar.
def route = context.sipFactory.createSipAddress(Constants.PROXY_SIP_URI + ";lr") sipRequest.pushRoute(route) def localroute = context.sipFactory.createSipAddress("sip:127.0.0.1:5060;lr") sipRequest.pushRoute(localRoute)
Never mode:
Replace the route header contents with an address corresponding to one of the local SIP listening interfaces.
def localroute = context.sipFactory.createSipAddress("sip:127.0.0.1:5060;lr") sipRequest.pushRoute(localRoute)
Always mode:
No changes are required for Always mode.