Re-establishing connection on TCP transport exception

SIP Server is now enhanced to re-establish connection when a TCP transport exception occurs. The new enhancement allows SIP Server to overcome a temporary single transport failure of a reliable SIP transport.

New procedures

The following two procedures are now implemented for handling a reliable transport failure:

Handling of Reliable Transport Failure for Standalone Deployment

If SIP Server detects a TCP transport failure of a single existing reliable transport while sending a re-INVITE request, it re-sends a request as soon as the preconfigured timeout expires. It repeats this action until a response is received successfully to the request but not for longer than the timeout defined by the sip-invite-timeout option.

Handling of Reliable Transport Failure for Deployment with SIP Proxy

Important

Coming soon. Check SIP Proxy Release Notes for availability of this feature.

SIP Proxy, on detecting a TCP transport failure of a forwarded request terminates that request transaction (client transaction). It returns a 503 error with the header, Error-Info, and value, transport-error, to the original request (server transaction). SIP Server processes the 503 response by waiting for the time defined by the pre-configured timeout and then re-sends the INVITE. It repeats these actions until a response is sent successfully to the request. Actions are not repeated after the timeout defined by the sip-invite-timeout option expires.

Unimpacted existing procedures

The following existing procedures are not impacted by this improvement and will continue to work the same way.

Handling of Failure with More than One Reliable Transport

If a failure occurs when more then one reliable transport is present, SIP Server processes the failure by re-sending the request through another transport. This behavior is preserved.

Handling of UDP Failure

There is no change in handling of UDP failures.

SIP workflow

There are no changes for cases with new INVITEs and for cases with non-INVITE requests.

Note on backward compatibility

Prior to this improvement, while receiving a 503 response with the Retry-After header, SIP Server waited for the retry-after time to expire, then re-sends the INVITE request and repeated that process without a limitation. That was not an acceptable behavior. Now, SIP Server re-tries the INVITE only within the period defined by sip-invite-timeout option.

Configuration options

A new configuration option, retry-after-reliable-transport-error, is introduced to specify the number of milliseconds SIP Server will wait before re-sending a request after transport failure on INVITE.

retry-after-reliable-transport-error
Setting: [TServer] section, Application level or Device level
Default Value: 0
Valid Values: 0 to 34000 (recommended - 500 to 5000)
Changes Take Effect: Immediately

The option specifies the number of milliseconds that SIP Server will wait before re-sending a request after a transport failure on re-INVITE. If the option is set to 0 or not configured, SIP Server disconnects the SIP peer after a transport error.

Important

Values at the device level take precedence over the values at the application level.

The existing sip-invite-timeout option is extended to specify the number of seconds for which SIP Server tries to re-send the request after the first failed attempt is detected after a transport error or a 503 response.

sip-invite-timeout
Setting: [TServer] section, Application level
Default Value: 0 (in effect, 32 seconds)
Valid Values: 0 to 34
Changes Take Effect: Immediately

Important

In an environment with SIP Proxy, it is expected that SIP Proxy reacts to the transport failure of a forwarded request with a 503 response to SIP Server. Such a response should have Error-Info: transport-error in the header.

HA considerations

In case a SIP Server HA switchover happens during the time period configured in the retry-after-reliable-transport-error option, SIP Server, after becoming the primary instance, terminates the SIP dialog in which the reliable transport error failed before the switchover. The corresponding T-Library party will be released in this case.

Limitations

This improvement is only for transport failure during re-INVITEs (failures which may lead to dropped calls). There is no change for other SIP transport failure cases such as:

• New INVITEs. Failed initial INVITEs normally do not break established calls. They are followed by corresponding T-Library errors and can be processed in a regular way.
• Processing of non-INVITE transactions such as, SIP NOTIFY with talk or hold events. Failure of these transactions does not lead to dropped calls and will be processed in a regular way.
• This improvement covers only cases with single transport. If a failure occurs when more then one reliable transport is present, as usual, SIP Server will continue to process the failure by re-sending the request through another transport.