15.11. Using RADIUS

15.11. Using RADIUS
	Chapter 15. VoIP

RADIUS can be used to allow new handsets to be registered dynamically without individual configuration by using RADIUS authentication to an external RADIUS server. RADIUS is also used to make call routing decisions.

RADIUS accounting can be used to log calls as they start and end to an external RADIUS server.

15.11.1. RADIUS accounting

RADIUS accounting logs each call leg, so a typical call has an incoming and outgoing leg.

A RADIUS START message is sent when the call leg is created.
A RADIUS INTERIM update is sent if/when the call connects (i.e. status 200).
A RADIUS STOP message is sent when the call ends, even if it did not connect.

The update includes the call duration, which is the time spent ringing for the interim update, and the connected duration in the stop message.

15.11.2. RADIUS authentication

RADIUS authentication is used for any challenged requests, such as REGISTER, INVITE, REFER, SUBSCRIBE, OPTIONS etc. The Digest-Method is always included to indicate a VoIP request and identify the type of request.

Tip

You can have a RADIUS authentication before the FireBrick challenges the reqestor setting the radius-challenge settings, allowing a RADIUS challenge response to customise the challenge. Otherwise the FB6000 will send a challenge automatically and only send a RADIUS authentication when the authenticated message is received.

For REGISTER an accept response can include a Called-Station-Id attribute can be used to define the registered connection as a tel:number URI for call routing. Without this, the registration is not logged on the FB6000 and it is assumed the RADIUS server will record where to send calls based on the registration. The SIP-AOR AVP in the access request provides the Contact URI.

An access request is sent to approve any SIP request such as REGISTER, SUBSCRIBE, OPTIONS, etc.
An access request is sent to make call routing decision for INVITE and REFER.
An access request is sent to make a call routing decision when a 3xx response is received from a connection being made to a telephone. Acct-Terminate-Cause specified the redirect code, e.g. 301, 302.

Access requests are made even when the request is coming from an locally configured telephone. In such cases the telephone must also pass validation against a locally configured password (if present). To identify such requests, the User-Name is the configured name (or extn or ddi) of the telephone user, and Chargeable-User-Identity attribute is set based on the configured CUI.

Access requests are made even when from a recognised carrier. In such case the carrier is validated by the FireBrick directly, and then the access request made to decide call routing. To identify such requests, the User-Name is the configured name of the carrier prefixed with an @ character.

Note

In the case of a telephone user, any @ charaters at the start of the name are removed so that it cannot be confused with a carrier.

15.11.2.1. Call routing by RADIUS

For requests that relate to call routing, such as INVITE and REFER, the response can include a set of call routing information to direct the call. If none is included then the call is routed following default rules within the FireBrick.

The routing action is specified by including one or more Called-Station-Id attributes. However, these can be interleaved with Calling-Station-Id and Chargeable-User-Identity which set the current CLI and CUI that apply when the Called-Station-Id is reached. If there is a CUI after the last Called-Station-Id then this is assumed to apply a sticky CDR to the calling leg (see Section 15.14).

Alternatively, the reply can simply include a SIP-AOR attribute which specifies the Contact sent on a redirect response (302) to the sender. This only works where the calling leg has not yet been answered.

There are a number of formats for call routing (Called-Station-Id) which can be used:-

tel:number - send to registered addresses for the number.
sip:uri - send to SIP destination.
@carriername - send to named carrier.
number@carriername - send to named carrier using specific target number.
number - don't make a call, but create a CDR using previous CLI and CUI and this as dialled number. This is accumulated to following call routing.

The above formats can be prefixed with digits and a plus to indicate a delay of a number of seconds before the destination is to be called. This allows a cascade ring pattern.

Tip

At any point, if all outgoing calls are waiting for a delay (none are trying, ringing) then the delay is moved forward to whichever is first. This means using a long delay such as 999+ can be used as a fallback - i.e. when the other call fails to connect the delay is skipped and the delayed call tried immediately.


15.10. Busy lamp field		15.12. Call recording