AudioCodes Mediant 3000, Руководство пользователя

Страница: 694 / 872

User's Manual 694 Document #: LTRT-89729
Mediant 3000
Parameter Description
to all registrations, but it can only be used if the Expires header field is
present with a value of "0".
Web/EMS: Add Empty
Authorization Header
[EmptyAuthorizationHea
der]
Enables the inclusion of the SIP Authorization header in initial
registration (REGISTER) requests sent by the device.

[0] Disable (default)

[1] Enable
The Authorization header carries the credentials of a user agent (UA) in
a request to a server. The sent REGISTER message populates the
Authorization header with the following parameters:

username - set to the value of the private user identity

realm - set to the domain name of the home network

uri - set to the SIP URI of the domain name of the home network

nonce - set to an empty value

response - set to an empty value
For example:
Authorization: Digest
username=alice_private@home1.net,
realm=”home1.net”, nonce=””,
response=”e56131d19580cd833064787ecc”
Note: This registration header is according to the IMS 3GPP TS24.229
and PKT-SP-24.220 specifications.
Web: Add initial Route
Header
[InitialRouteHeader]
Enables the inclusion of the SIP Route header in initial registration or
re-registration (REGISTER) requests sent by the device.

[0] Disable (default)

[1] Enable
When the device sends a REGISTER message, the Route header
includes either the Proxy's FQDN, or IP address and port according to
the configured Proxy Set, for example:
Route: <sip:10.10.10.10;lr;transport=udp>
or
Route: <sip: pcscf-gm.ims.rr.com;lr;transport=udp>
EMS: Ping Pong Keep
Alive
[UsePingPongKeepAlive
]
Enables the use of the carriage-return and line-feed sequences (CRLF)
Keep-Alive mechanism, according to RFC 5626 “Managing Client-
Initiated Connections in the Session Initiation Protocol (SIP)” for
reliable, connection-orientated transport types such as TCP.

[0] Disable (default)

[1] Enable
The SIP user agent/client (i.e., device) uses a simple periodic message
as a keep-alive mechanism to keep their flow to the proxy or registrar
alive (used for example, to keep NAT bindings open). For connection-
oriented transports such as TCP/TLS this is based on CRLF. This
mechanism uses a client-to-server "ping" keep-alive and a
corresponding server-to-client "pong" message. This ping-pong
sequence allows the client, and optionally the server, to tell if its flow is
still active and useful for SIP traffic. If the client does not receive a pong
in response to its ping, it declares the flow “dead” and opens a new flow
in its place. In the CRLF Keep-Alive mechanism the client periodically
(defined by the PingPongKeepAliveTime parameter) sends a double-
CRLF (the "ping") then waits to receive a single CRLF (the "pong"). If
the client does not receive a "pong" within an appropriate amount of
time, it considers the flow failed.