- Current openings

Upgrades

Release notice for Ingate Firewall® 4.6.1 and Ingate SIParator® 4.6.1

Release name:	Ingate Firewall® 4.6.1 Ingate SIParator® 4.6.1
Release date:	2007-12-19

This is a service release, providing bug fixes and a few new features. We recommend that everybody upgrade.

The new version and the user manual can be found at: www.ingate.com/upgrades/

When upgrading an Ingate SIParator running in MEDIAtor mode it is recommended that an updated Windows service is installed on the LCS Access Proxy server. Please contact support@ingate.com if you need to obtain this service.

New SIP Functionality

When the internal B2BUA handles call transfers it is now possible to generate ringback audio indicating transfer progress to the transfered party. [Tracking ID: 3314]
An interoperability setting has been added to force CSeq change when performing 3xx recursion. [Tracking ID: 3316]
The internal B2BUA can be configured to relay re-INVITEs to the other end (and wait for the response) before issuing a response to the received re-INVITE. [Tracking ID: 2993]

Other New Functionality

TLS/SSL decrypting relay type has been added. This relay acts as a TLS server, decrypts the data stream, and forwards it as a normal TCP connection. [Tracking ID: 1875]
Information about modules, patches, and installed SIP licenses can now be obtained via SNMP. [Tracking ID: 3482]

Fixed SIP-related Problems

SIP media ports were sometimes not reused. In certain scenarios involving call hold and/or send-only streams, the SIP module could forget to reuse the media port when the call ended. This could eventually lead to exhaustion of the port pool, so that new calls could not be set up. [Tracking ID: 3435]
Attended transfers were not always handled by the internal B2BUA if AOR, instead of remote target, was used in Refer-To. This has been fixed. [Tracking ID: 2983]
The internal B2BUA now again properly extends the session timer when the remote party is performing session refreshes. This broke in the 4.6.0 release. [Tracking ID: 3481]
When a call passes through the internal B2BUA and forks downstream, the B2BUA now correctly keeps the different dialogs apart. [Tracking ID: 3324]
In some situations the IP address 0.0.0.0 could show up in the internal B2BUA's Contact header. This has been fixed. [Tracking ID: 3504]
When the offer is sent in an INVITE response, the SDP in the 1xx message is now only considered an offer if the response is reliable. [Tracking ID: 3330]
When a request cannot be delivered because of network problems we now properly try alternative destinations (from SRV lookup). [Tracking ID: 3201]
Hold requests using 0.0.0.0 address could trigger 503 response in some situations. This problem appeared in 4.6.0 and has now been fixed. [Tracking ID: 3501]
The internal B2BUA now includes a Contact header in provisional INVITE responses as it should. [Tracking ID: 3385]
The transport protocol is now checked properly when determining if a destination is known as down. [Tracking ID: 3461]
The internal B2BUA now delays early re-INVITEs until the initial INVITE has been ACKed. [Tracking ID: 3489]
The SDP version field is always updated now. [Tracking ID: 3034]
Remote NAT detection has been improved for stream-based transport protocols. [Tracking ID: 3460]

Known Problems

Known SIP-related Problems

This problem is only relevant if the SIP module is used.

When Local REFER handling is used, and the users register on a LAN PBX which uses authentication for calls, remote users cannot make SIP Trunk calls. [Tracking ID: 3335]

Known VPN-related Problems

These problems are only relevant if IPsec is used.

Packets with a destination address that belongs to either end of a tunnel will appear to be encrypted in the log, even when they should not be encrypted. This is a problem with the log only. [Tracking ID: 46]
The local endpoint must be chosen so that it is the address closest to the next-hop router for that peer. This means that mobile clients must always connect via the same interface (typically the interface connected to the Internet). [Tracking ID: 508]

Known Failover-related Problems

This problem is only relevant if failover is used.

Upgrading a failover team is a complex operation. To upgrade it, you must break the team and upgrade each machine in turn. This will require a number of reboots and network outages. See the separate failover upgrade document which is available on the upgrade web. [Tracking ID: 499]