Release notice for Ingate FirewallŪ 4.7.1 and Ingate SIParatorŪ 4.7.1
Release name: Ingate FirewallŪ 4.7.1
Ingate SIParatorŪ 4.7.1
Release date: 2009-03-23
This is a major release, with many bug fixes, security fixes, and new
features. We recommend that everybody upgrade.
The new version and the user manual can be found at:
http://www.ingate.com/upgrades/
* New SIP-related features
*** Monitoring of SIP media. If enabled, the Ingate unit will monitor
the RTP streams and compute the following information (separately
for each direction):
- number of packets seen
- number of bytes seen
- jitter
- number of missing packets
- maximum number of consecutive missing packets
The above information is included in the RADIUS accounting stop
ticket. [Tracking ID: 2756]
*** A new SIParator mode, WAN SIParator, allows the SIParator t
be placed in front of an existing firewall. The SIParator will
handle SIP signaling and media, while data traffic transparently
passes through the SIParator and is handled by the existing
firewall. The main benefit is that Ingate's SIP-capable QoS can
be used to proritize, while the legacy firewall handles the
data traffic as before.
[Tracking ID: 3548]
*** It is now possible to have additional default gateways. These
gateways can be used for traffic to relays on the Ingate Firewall.
A single additional default gateway can be used for some or all
outbound SIP traffic. This makes it possible to for instance route
all SIP trunk traffic via one ISP, while routing all data traffic
to another ISP. It can also be used to send SIP-related traffic
via one VLAN and data traffic via another.
The additional default gateway is primarily intended to be used for
SIP trunks, and has received limited testing in other scenarios.
Currently, registrations received via an additional default gateway
cannot be used in calls, as the media may not be set up correctly.
[Tracking ID: 3931]
*** Limited support for the a=rtcp attribute in SDP. The administrator
can select if this should be enabled or not. If enabled, we can no
longer guarantee that the RTCP port is one higher than the RTP
port, so RTCP will not work unless all clients support the a=rtcp
attribute. (Fixing this limitation has tracking ID 3939). Also,
the a=rtcp attribute support cannot be enabled if media encryption
transcoding is used (fixing that has tracking ID 3941).
[Tracking ID: 1477]
*** Added support for "TCP-Based Media Transport in the Session
Description Protocol (SDP)" as defined by RFC 4145.
[Tracking ID: 2252]
*** Added an option to always perform NAT traversal for SIP requests.
This can be configured per interface, and exceptions for certain IP
address ranges can be added. This can be useful when the NAT box
understands enough SIP to fix the Via header, but not enough SIP to
actually make the call work without NAT traversal support at the
Ingate unit. [Tracking ID: 2805]
*** It is now possible to configure DMZ SIParators so that they allow
equipment in one surrounding to negotiate media streams for devices
in another surrounding. [Tracking ID: 3110]
*** You can now define user routing for RADIUS-authenticated SIP
users. [Tracking ID: 3580]
*** You can now specify the display name for outgoing calls in some
SIP trunking scenarios. [Tracking ID: 3582]
*** It is now possible to have non-user accounts (for SIP trunking) and
RADIUS-authenticated local users at the same time.
[Tracking ID: 3607]
*** The SIP User table has been split into two tables: one for
user accounts, and one for other accounts. [Tracking ID: 3609]
*** An interop setting has been added to keep the original user-agent
header when the internal B2BUA is used. [Tracking ID: 3685]
*** The internal B2BUA can now be configured to keep the To header from
the original request. This can be useful in several scenarios, for
example it may make the RADIUS accounting information more useful.
[Tracking IDs: 3773, 3906]
*** The SIP module can now be configured to add an P-Asserted-Identity
header to requests even when authentication is not used. This can
sometimes be useful for interop purposes. [Tracking ID: 3850]
*** Added support for receiving UPDATE requests to the B2BUA.
[Tracking ID: 3869]
*** Added an interop setting to remember media streams for a while
when they are no longer used, so that they can be reused (for
example after a hold). This is needed by some devices that do not
accept the port numbers to change after a hold.
[Tracking ID: 3882]
*** The ringback media is now sent using symmetric RTP.
[Tracking ID: 3885]
*** The Refer-To header of REFER requests is normally set to an
encrypted string. It is now possible to configure an IP
addresses or domain name that should be inserted instead for blind
transfers. The user name will be left unchanged. This can be used
when a PBX needs to match the user name in its dial plan.
[Tracking ID: 3890]
*** The SIP module can now be configured to use a template SDP to
construct an offer if it hasn't seen one from one side, but needs
it. This can make more call transfers work, but it also means that
the generated SDP may not correctly describe what the phone
supports. [Tracking ID: 3892]
*** It is now possible to configure which local IP address the SIP
module should use when it talks to a particular SIP server.
[Tracking IDs: 3412, 3901, 3915]
*** If a part of a SIP multipart message don't contain a Content-Type header
we now log a message about that fact. This can make it easier to
diagnose broken SIP units. [Tracking ID: 4055]
*** Improved handling of 3rd party call control, which now handles
transfer scenarios better, particularly when the codec changes.
[Tracking ID: 2993]
*** When the B2BUA receives an offer-less INVITE, it will add a dummy
SDP and renegotiate it once the call is set up. This improves
interoperability. [Tracking ID: 3389]
*** The performance of the 1190 model has been increased.
[Tracking ID: 4111]
*** Improved the logged error message when certificate verification
fails for TLS connections. [Tracking ID: 3288]
* New IPsec-related features
*** It is now possible to disable PFS (Perfect Forward Secrecy) for
IPsec. This can be needed when setting up a tunnel to some devices
that lack PFS support, but you should be aware that disabling PFS
is a security risk. [Tracking ID: 1669]
*** It is now possible to define the proposals we send in both phase 1
and phase 2 of IPsec negotiations. This should make it easier to
set up IPsec tunnels to some devices. [Tracking ID: 1717]
*** IPsec tunnels can now be configured to always let the other end
start renegotiations of the tunnel. This solves some interop
problems. [Tracking ID: 2867]
* Other new features
*** Proxy ARP is now supported.
[Tracking ID: 351]
*** Several minor usability improvements to the web configuration
interface:
- Use