Overview of G711 Transparent Fax and T38 fallback G711

In a FAX over IP communication, when a SIP External Gatway is involved, the transmission is done through T38 Procedure. From OXE R11, the G711 procedure for fax communication is implemented, as well as a “Fallback” procedure from T38 to G711.

With this feature, OXE will support two more procedures. For SIP calls, FAS support will be done in 3 modes:

• The T38 only procedure

• The G711 transparent procedure

• The T38 to G711 Fallback procedure (In a first step, fax will try to establish with T38, if remote side doesn’t support it, it will fallback to G711 mode) The configuration of the above options is made in the corresponding External Gateway parameter (Fax procedure type).

Remark: this feature is applicable for the INTIP3/MG3 couplers only

OXE Remote Extension

Enhancement with OXE R11: Overflow to associate set if REX user is unavailable


Behavior before R11:
when the mobile set of a Remote Extension user receives a call from OXE and the mobile is in one of the following states (swithed off, busy, Out of Coverage area, Out of Service, the REX user may reject the call), OXE will receive a DISCONNECT message from the REX is unavailable due to the above mentioned reasons. When an Associate Set is managed in OXE for the Remote Extension, on receiving a DISCONNECT message, the behavior in OXE depends on the value of a system parameter

System ->  Descend Hierarchy -> Other System Parameters -> Descend Hierarchy -> External Signaling Parameter ->  Review/Modify -> “Listen to guide on DISCONNECT”

According to the existing implementation of Remote Extension, when the parameter “Listen to guide on DISCONNECT” is set to:

• TRUE the incoming call to Remote Extension overflows to its Associate Set only after no answer timer expires.
• FALSE the incoming call to Remote Extension overflows to its Associate Set immediately

Enhancement from R11: 

When REX user is configured as Non-Tandem set, then the call will overflow to the associate set of the REX immediately irrespective of the value of parameter “Listen to guide on Disconnect”. 

Whenever REX user is configured as Tandem’s secondary set, the overflow will depend upon the state when the DISCONNECT message is received. If OXE receives a DISCONNECT message before ALERT, the call will not overflow to the associate Set immediately but will overflow only after the call no answer timer. If OXE receives the DISCONNECT message after ALERT, the call will overflow to the associate set of the REX immediately

OXE Gateway

Entity between SIP world and legacy world, the gateway is used to establish a call from a SIP equipment to an ISDN link, to a legacy set, etc… and vice versa

• Do not confuse the SIP gateway with the OmniPCX Enterprise media gateway boards:
• The SIP gateway is a logical entity that resides within the call server (CS) and is responsible for the SIP signaling for the conversation setup,
• The media gateway boards (GD, GA, INTIP) are the physical devices where the media session will be established when calling to a classic PBX set.

• There is one and only one internal SIP gateway. But there can be many different external SIP gateways (we will come back to this in a later section).

• The SIP gateway is associated to a SIP trunk group. Although there can be many SIP Trunk Groups, there is only one SIP trunk group which is associated to the local SIP gateway. We call this special trunk group the local SIP trunk group.

OXE Dictionnary

Contains the SIP users created on the OXE, it is the database that holds the mapping between SIP URLs and PBX directory numbers (MCDUs). Each registered SIP terminal is automatically added to the dictionnary. Classic PBX terminals are added only if a SIP URL is defined for them in the user management.

• Most of the time you shouldn’t do anything with the Dictionnary. Everything will be handled automatically. You need to access the SIP Dictionnary configuration only for configuration of aliases

OXE Duplication

In case of OXE duplication, the SIPMOTOR is completely started on the Stand-By CPU, but acting as Stand-By(cannot handle the SIP requests). The Main CPU puts the Stand-By CPU up to date about the SIP contexts (Calls,registrations, subscriptions, etc...). In case of CPU switchover, the SIP calls are maintained and the registration andsubscriptions are kept.

In Case of spatial redundancy with dual subnetworks (2 main IP addresses), the SIP uses the FQDN of the OXE(nodename + DNS local domain name) for the SIP messages and also for the responses of the SIP messages. In thatcase, the remote SIP equipment must use it. The use of external DNS server is recommended to resolve this FQDN

The OXE contains the following compoments:

Registrar

Registers the SIP terminals addresses (“Location Service”)

·       The REGISTRAR is contained in the “localize.sip” file under /tmpd. If for any reasons you need to clear allentries in the registrar database, remove this file and then restart the SIPMOTOR:

(1)OXE> rm /tmpd/localize.sip

(1)OXE> dhs3_init -R SIPMOTOR

Proxy

Entity between the Client and the Server, the proxy is used to route the SIP requests.

·       The call can be routed between 2 SIP terminals. For instance, if Alice calls Bob (both are SIP), Alice sends a SIP request to the proxy, and the proxy sends this request to Bob.

·       The proxy can be used only for the authentication of the SIP equipment for Registration or SIP request.

o   The proxy can modify the request by adding information like a Via, Record-route, etc...

The INVITE is the same on each proxy sides, to get this behavior, and the UAC manages the IP address of the OXE SIP  proxy as the “Outbound proxy”

Here is an example:

·              UAC IP address: 172.27.143.184

·              proxy IP address: 172.27.143.186

·             UAS FQDN: oxe-ov.alcatel.fr (IP address: 172.27.141.151)

SIPMOTOR Processes

In the OmniPCX Enterprise, the logical functions of registrar, location service, proxy server and gateway are co-locatedin the process called sipmotor, running on the CPU7/CS2/AS board.

You may use the linux ps command to verify that the SIP processes are running :Example:All processes can be forced to reset with the command:

Example:

All processes can be forced to reset with the command:

•        dhs3_init -R SIPMOTOR 

This command stops properly the SIPMOTOR processes and restarts them. They will be automatically relaunched after a few seconds.The following commands can be used as well:

(1)OXE> dhs3_init –R SIPMOTOR

They will be automatically relaunched after a few seconds.

The following commands can be used as well

• killall sipmotor, this command kills the SIPMOTOR processes and restarts them.
• kill -9 “father pid”, this command kills the SIPMOTOR processes and restarts them.

Remarks:

If no licenses about SIP are present, the SIPMOTOR processes are not running.