Filter
Top Products
Version 6.2 23 December 2010
SIP Release Notes 1. What's New in Release 6.2
8. SIP Route Header in Initial Registration Request:
Product
MP-11x MP-124
Mediant 600 Mediant 1000
Mediant 800 MSBG Mediant 1000 MSBG
Mediant 2000
Mediant 3000/TP-6310 Mediant 3000 HA/TP-6310
Mediant 3000/TP-8410 Mediant 3000 HA/TP-8410
Management Protocol
Web INI
SNMP
EMS
CLI
This feature supports the inclusion of the SIP Route header in initial registration
(REGISTER) requests sent by the device. This feature is enabled by the new
parameter, InitialRouteHeader (by default, this parameter is disabled).
When the device sends a REGISTER message (either for initial registration or to re-
register), the Route header includes 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>
9. CRLF Keep-Alive Mode:
Product
MP-11x MP-124
Mediant 600 Mediant 1000
Mediant 800 MSBG Mediant 1000 MSBG
Mediant 2000
Mediant 3000/TP-6310 Mediant 3000 HA/TP-6310
Mediant 3000/TP-8410 Mediant 3000 HA/TP-8410
Management Protocol
Web INI
SNMP
EMS
CLI
This feature provides support for 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)”. This feature prevents an
“avalanche” of keep-alive messages by multiple SIP UAs to a specific server.
The SIP UA (i.e., device) uses a simple periodic message as a keep-alive mechanism
to keep the 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 notify 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 sends a double-CRLF (the "ping"), then waits to receive a single CRLF
(the "pong"). If the client does not receive a "pong" within this user-defined time, it
considers the flow failed.