AudioControl VERSION 6.2 SIP Route Header in Initial Registration Request, Crlf Keep-Alive Mode

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.

Version 6.2 23 December 2010