This document describes, how to use the beroNet Gateway Call Progress Table.
beroFix is a modular SIP Gateway, which translates the SIP Protocol according to RFC3261 [1] into the technologies:
- ISDN PRI and BRI, according to the EuroISDN Standards ITU/T Q.931 [2]
- FXO, FXS
- GSM, via a GSM Module according to the ETSI GSM AT commandset [3]
Each technology has the possibility to create and finish a phone call, which makes it clear that some SIP messages are translated to corresponding ISDN/ANALOG/GSM messages:
SIP Message | ISDN Message | FXS | FXO | GSM |
INVITE | SETUP | Generate Ring Voltage | OFFHOOK | ATD |
200 OK | CONNECT | - | - | ATA/CONNECT |
BYE/CANCEL | DISCONNECT | Unobtainable Tone | ONHOOK | ATH |
There are additional messages, that provide call progress information to the user (like a Rinback Tone). The translation of these messages between SIP and ISDN is handled via the Call Progress Table in beroFix. It can be found in the GUI under the menu point Preferences->Call Progress.
Call progress messages are normally not important for establishing or finishing a voice call. But they are important to inform the user about the state of the current call.
beroFix has a default call progress table which tries to map the progress messages in a proper way, but there are some SIP Servers that have a different understanding of those messages, that's why berofix allows to change the translation.
You can create as much call progress tables as you want. Each table contains a set of translation entries. The table can later be referenced in the beroFix dialplan. The default call progress table will be used as template and is always valid unless it's entries are overwritten with a self configured call progress table.
listing Progress Tables
beroFix has it's defaut progress tables and the ones that are added by the user. You can review the call progress tables with the telnet interface of berofix. The command for that is lcpt (list call progress table).
The default ones look like:
lcpt Table: s2i:default nt with_audio ALERTING: 180_SDP KLINGELING nt any_state ALERTING: 180 KLINGELING nt with_audio PROCEEDING: 183_SDP PROCEEDING nt any_state PROCEEDING: 183 PROCEEDING nt with_audio PROGRESS: 183_SDP PROGRESS nt any_state PROGRESS: 183 PROGRESS nt any_state CONNECT: 200 OK te with_channel ALERTING: 180_SDP KLINGELING te any_state ALERTING: 180_SDP KLINGELING te with_channel PROCEEDING: 183_SDP PROCEEDING te any_state PROCEEDING: 183_SDP PROCEEDING te with_channel PROGRESS: 183_SDP PROGRESS te any_state PROGRESS: 183_SDP PROGRESS te any_state CONNECT: 200 OK Table: i2s:default nt 180 * ALERTING nt 183 PROGRESS PROGRESS nt 183_SDP PROGRESS PROGRESS nt 183 * PROCEEDING nt 180_SDP * ALERTING nt 183_SDP * PROCEEDING nt DIALPLAN_MATCH_FOUND * PROCEEDING te 180 * ALERTING te 183 * PROCEEDING te 180_SDP * ALERTING te 183_SDP * PROCEEDING te DIALPLAN_MATCH_FOUND * PROCEEDING
The Table s2i means SIP to ISDN and i2s ISDN to SIP. Let's examine one line like:
te any_state ALERTING: 180_SDP KLINGELING
It means that if coming from an ISDN TE Port we receive an ALERTING, (no matter if it contains a B-Channel Information Element nor a Progress Indicator Information Element -> any_state). Then we send an 180 including SDP and the Response Text "KLINGELING" towards SIP.
Adding/Modifying Progress Tables
When you click on "Add Table" you will see a pop-up which looks like:
Here you can choose a name for this new table, which is later used as reference in the Dialplan. You've got also the option to create automatic entries for:
- Call Forwarding Rules - used in call forward scenarios ISDN -> SIP -> ISDN, with 3CX and some asterisk verions.
- Early Audio Outbound Rules - used to playback tones to the ISDN side before connecting the ISDN side
After clicking Save, you will see the call progress table editor:
Here you can add another table or add/modify/delete entries for each table. When you click on add/modify an entry, you will see the entry editor:
Here you can define a entry to the call progress table. You can define the condition:
* Interface Type - TE or NT * ISDN Event Stack - defines which Messages where received consecutively * ISDN channel details: + no_channel - no B-Channel was provided + with_channel - a B-Channel was provided + without_inband - no progress indicator was provided + with_inband - a progress indicator was provided + any_state - channel details don't matter
Then you see the Resulting Response:
* SIP Response - 180/183/200 * SDP - wether to send SDP or not * Response Text - free Text that is used in the SIP Response
After filling out everything, the rule will apply when the condition is true, and will then create the defined Response.
References:
[1] http://www.ietf.org/rfc/rfc3261.txt [2] http://www.itu.int/rec/T-REC-Q.931/e [3] http://www.3gpp.org/ftp/Specs/archive/07_series/07.07/