beroNet Gateway Call Progress Tables

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 MessageISDN MessageFXSFXOGSM
INVITESETUPGenerate Ring VoltageOFFHOOKATD
200 OKCONNECT--ATA/CONNECT
BYE/CANCELDISCONNECTUnobtainable ToneONHOOKATH

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/

If you need scheduled remote assistance, you can request our on-demand support services: https://www.beronet.com/support