____________________________________________________________________________________
____________________________________________________________________________________
TAU-4M.IP Subscriber gateway
53
Click the configurable profile link by the left mouse button to configure the profile. An 'Edit profile'
window will be opened. Fill in the following fields:
SIP parameters
Profile includes
- list of subscriber ports, which assigned with profile; field is non-editable;
Profile name
- custom name of the configurable profile;
Proxy mode
–select SIP server (SIP-proxy) operation mode form the drop-down list:
–
Off
- SIP proxy server not using, all INVITE queries are sending to address, pointed after
'@' symbol, in the dialplan mask entry;
–
Parking
–SIP-proxy redundancy mode without main SIP-proxy management;
–
Homing
–SIP-proxy redundancy mode with main SIP-proxy management.
The gateway may operate with a single main SIP-proxy and up to four redundant SIP-proxies. For
exclusive operations with the main SIP-proxy, 'Parking' and 'Homing' modes are identical. In this case,
if the main SIP-proxy fails, it will take time to restore its operational status.
For operations with redundant SIP-proxies,
'Parking'
and
'Homing'
modes will work as follows: The
gateway sends INVITE message to the main SIP-proxy address when performing outgoing call, and
REGISTER message when performing registration attempt. If on expiration of
'Invite total timeout'
there is no response from the main SIP-proxy or response 408 (when 'changeover by timeout' option
is enabled) or 503 is received, the gateway sends INVITE (or REGISTER) message to the first
redundant SIP-proxy address. If it is not available, the request is forwarded to the next redundant
SIP-proxy and so forth. When available redundant SIP-proxy if found, registration will be renewed on
that SIP-proxy.
Next, the following actions will be available depending on the selected redundancy mode:
In the 'parking' mode, the main SIP-proxy management is absent, and the gateway will continue
operation with the redundant SIP-proxy even when the main proxy operation is restored. If the
connection to the current SIP-proxy is lost, querying of the subsequent SIP-proxies will be continued
using the algorithm described above. If the last redundant SIP-proxy is not available, the querying will
continue in a cycle, beginning from the main SIP-proxy.