VoIP
112
for a non local request where the user is not recognised as a local telephone user. Otherwise the FB2700 will
send a challenge automatically and only send a RADIUS authentication when the authenticated message is
received. This also happens if an Authorization header is presented without a response value.
Tip
For an unauthenticated request you can respond with an Access Challenge including the paramaters
to challenge, but any attributes you omit will be completed automatically, so you can simply respond
with an empty challenge to confirm the FB2700 is to go ahead and do the challenge itself.
For REGISTER an accept response can include a Called-Station-Id attribute to define the registered connection
as a
tel:number
URI for call routing. Without this, the registration is not logged on the FB2700 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, and can be used in the reply to cause a 302 redirect response to
a specified contact.
• 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 specifies 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 the 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 is 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.
Note
A call can come from anywhere. An unknown request from a non local IP will send a RADIUS request
before challenging the requestor so that the RADIUS server can decide if it is to be challenged or not.
An Access reject with no message attribute will not send any error to a non local IP requestor - add
a message to force this.
17.11.2.1. Call routing by RADIUS
To understand how call routing works you need to understand how call legs work. A call leg is a connection to or
from the FB2700 to another SIP device. It could be a SIP carrier or a telephone. Typically there is an incoming
call leg from a carrier or a phone, which needs to be authenticated, and then a call routing decision is made.
An Access Accept response can then contain the call routing attributes. This causes one or more outgoing call
legs to be created. These would typically be ringing telephones. Once one of these legs answers the others are
cancelled and the two legs are connected together to form a call. The purpose of the routing attributes is to
create these outgoing call legs, and to set up attributes such as CDRs and call recording.
Each call leg has a CLI (calling number), a Dialled number, a display Name, a number of CDR records (each
of which have CDR and Dialled as well), and finally a number of email addresses for call recording.
The response attributes are processed in order. Initially the last call leg is the originating call. When a new
outgoing leg is added, that becomes the current call leg.