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

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

The new version can be found here

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]

Other Fixed Problems

     * All dialogue pages in the GUI now contains standard-compliant XHTML.
       [Tracking IDs: 3459, 3484]

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]

  Other Known Problems

     * Using multiple default gateways does not work with PPPoE interfaces.
       [Tracking ID: 2980]
     * Autonegotiation of NIC duplex and speed does not work with Alcatel
       Speedtouch modems using some Ingate models that support configuration
       of NIC duplex and speed. Setting the duplex and speed manually to
       half/10 solves the problem. Affected models: Ingate Firewall 1450,
       1880. Ingate SIParator 45, 88. [Tracking ID: 3006]

Support?  |  Helpdesk!
Contact us  |  info@ingate.com
How Ingate uses cookies