____________________________________________________________________________________
____________________________________________________________________________________
VoIP subscriber gateways
51
–
Check username only in RURI
—
when checked, only subscriber number (user) will be analyzed, and
if the number matches, the call will be assigned to the subscriber port. When unchecked, all URI
elements (user, host and port—subscriber number, IP address and UDP/TCP port) will be analyzed
upon receiving an incoming call. If all URI elements match, the call will be assigned to the
subscriber port;
–
100rel
–
use reliable provisional responses (RFC3262):
Supported
– reliable provisional responses are supported;
Required
– reliable provisional responses are mandatory;
Off
– reliable provisional responses are disabled.
SIP protocol defines two types of responses for connection initiating request (INVITE)—
provisional and final. 2хх, 3хх, 4хх, 5хх and 6хх-class responses are final and their transfer is
reliable, with ACK message confirmation. 1хх-class responses, except for '100 Trying' response,
are provisional, without confirmation (rfc3261). These responses contain information on the
current INVITE request processing step, therefore loss of these responses is unacceptable.
Utilization of reliable provisional responses is also stated in SIP (rfc3262) protocol and defined by
'100rel'
tag presence in the initiating request. In this case, provisional responses are confirmed
with PRACK message.
Setting operation for outgoing communications:
Supported
– send the following tag in 'INVITE' request—
supported:100rel.
In this case,
communicating gateway may transfer provisional responses reliably or unreliably—as it
deems fit;
Required
– send the following tags in 'INVITE' request—
supported
:
100rel
and
required:100rel
. In this case, communicating gateway should perform reliable transfer of
provisional replies. If communicating gateway does not support reliable provisional
responses, it should reject the request with message 420 and provide the following tag—
unsupported:
100rel. In this case, the second INVITE request will be sent without the
following tag—
required: 100rel
;
Disabled
– do not send any of the following tags in INVITE request—
supported: 100rel
and
required: 100rel
. In this case, communicating gateway will perform unreliable transfer of
provisional replies.
Setting operation for incoming communications:
Supported, Required
– when the following tag is received in 'INVITE' request—supported:
100rel, or required: 100rel—perform reliable transfer of provisional replies. If there is no
‘supported: 100rel’ tag in ‘INVITE’ request, the gateway will perform unreliable transfer of
provisional replies;
Disable
– when the following tag is received in 'INVITE' request—required: 100rel, reject
the request with message 420 and provide the following tag—unsupported: 100rel.
Otherwise, perform unreliable transfer of provisional replies.
–
Enable timer
–
when checked, the 'timer' (RFC 4028) extension support is enabled. When connection
is established, and both sides support 'timer' extension, one of them periodically sends re-INVITE
requests for connection monitoring purposes (if both sides support UPDATE method, wherefore it
should be specified in the 'Allow' header, the session update is performed by periodic transmission of
UPDATE messages). The following settings are available for configuring:
Minimal session time (Min SE, sec)
–
minimal time interval for connection health checks
(90 to 1800s, 120s by default). The value shouldn’t be more then value specified in the
field ‘
Session
time’
;
Session time, sec (Session expires, sec)
–
period of time in seconds that should pass before
the forced session termination if the session is not renewed in time (90 to 80000s,
recommended value—1800s, 0—unlimited session);