Release 2.2 - An Overview of Features

F-1253 IPV6

Brief Description:

With the introduction of feature F-1253 IPv6 Support, the IMG 2020 now supports the IPv6 protocol. The stack employed for this functionality is a dual IPv4/IPv6 network stack that is IPv6 Ready Phase II certified that supports mixing the IPv6 and IPv4 protocols. For more information, refer to the links in the Related Topics section below.

Related Topics:

IPv6 / IPv4 Overview

Channel Group

In addition to the overview topic in the Related Topics section, the following objects and procedures have been impacted by IPv6 or combination of IPv6/Multiple SIP IP's features being added to the IMG 2020. Refer to each topic for the updated information.

Configure DNS

External Gateway 

DNS Servers 

DNS Server

DNS Server Associations

DNS Server Association

DNS Clients

DNS Client

SIP Signaling - IP Address

IP Address

Packet Facility

F-1291 Support for tel URI RFC 3966

Brief Description:

Tel URI (RFC 3966) is a unique identifier that is expressed using either an Address-of-Record or a Dial String. Feature F-1291 adds tel URI support to the IMG 2020. With the inclusion of this feature, the IMG 2020 can receive the tel URI information in a SIP request of an incoming call and pass the same tel URI information to the outgoing SIP leg. The tel URI will be separated into two parts: the phone number and the optional parameters. This will allow the phone number to be used for routing in the same way as for SIP URI while the optional parameters can still be sent out as received. The tel URI functionality is by default enabled and cannot be disabled. Refer to the topic links in the Related Topics section below.

Related Topics:

tel URI 

F-1675 Ethernet Redundancy via Smart Probing

Brief Description:

Ethernet Link Redundancy via Smart-Probing enhances the 2020 SBC’s ability to initiate a switchover due to a failure in the network. Currently the IMG 2020 employs a link based Ethernet Redundancy scheme. In the current scheme, the IMG 2020 would initiate a switch-over such as from interface Data A0 to Data A1 located on the rear of the system. With the addition of this feature the IMG 2020 can be configured to employ a probe-based detection scheme. In this scheme, the IMG 2020 would probe a set of pre-configured endpoints (send an ARP request packet). The endpoints would then reply with a Gratuitous ARP packet. These packets inform the IMG 2020 that the endpoints are still alive. If the IMG 2020 sends out an ARP Request Packet and does not receive a Gratuitous ARP in return it will continue to send ARP Requests until the pre-configured number of requests is met. If at that time no Gratuitous ARP’s are sent back then a switchover to its Hot Standby Port (Data A1 in this case) will be initiated. If the switchover solves the problem, then calls will continue to be processed on the new switched-over port. However, if the issue is not solved, the IMG 2020 would continue to switch back and forth between Data A0 and Data A1 (ping pong effect) until the issue in the network is solved. The feature is enabled through the Web GUI and can be enabled on any of the network interfaces (CTRL, Data A, Data B).

The second part of this feature allows the customer to initiate a link switchover manually. A manual switchover can be executed from the Logical Interface object within the Web GUI. The manual switchover was added to allow a customer the ability to switch from one network to another. An Event such as maintenance to a specific network is now possible by switching away from the network that needs maintenance to a different network that could handle any traffic while maintenance is being performed. Below is diagram displaying the Smart-Probing Via Ethernet Redundancy feature using ports Data A0 and Data A1.

Related Topics:

Ethernet Redundancy via Smart Probe 

Smart Probe Detection 

Smart Probe Endpoint 

F-6294 Precondition (RFC 3312) and P-Early-Media Header (RFC 5009)

Brief Description:

Feature F-6294 was developed for a customers application and uses the Precondition and P-Early-Media Header functionality. The Precondition and the P-Early-Media Header are used to indicate that resources are allocated. Once the resources are allocated, media streams are available for transmission and reception. Refer to the topic in the Related Topics section below for more information.

Related Topics:

Precondition and P-Early-Media Header Support 

F-6295 Passing Unsupported SIP Headers

Brief Description:

If a SIP Header that is not supported on the IMG 2020 is received, this header would normally be dropped. F-6295 Passing Unsupported Headers changes that behavior by giving the user a choice whether a header that is not supported on the IMG 2020 can be passed to the outgoing leg or be dropped. The functionality is configurable through the SIP Headers object and by default is set to Disabled. Refer to the topic links in the Related Topics section below for more information.

Related Topics:

SIP Profile - Headers 

Passing Unsupported SIP Headers (SIP to SIP) 

F-6296 Overload Control Support

Brief Description:

Feature F-6296 Overload Control support uses the SIP OPTIONS message to control SIP signaling traffic between two SIP networks or entities. To accomplish this, the SIP method OPTIONS is utilized. Feature F-6296 uses this method to perform the following functions:

1. Transmit or Inform the entity in a network that the IMG 2020 has reset or failed and has come back into service. At this point, calls can now resume.

2. Block or Unblock calls coming from a network.

3. Monitor resource usage and inform entities in a network and restrict calls when a maximum number is reached.

4. Monitor and inform entities in a network and resume calls when the resources available go below a set threshold after reaching a set maximum.

Refer to the topics in the Related Topics section below for more information.

Related Topics:

SIP Overload Control Overview 

SIP Signaling - Overload Control 

F-6318 Private Alarm MIB

Brief Description:

A new private MIB was added to the dictionary.dialogic file. Prior to software Release 2.2, alarm information was displayed using the standard MIB described in RFC 3877. Feature F-6318 Private Alarm MIB enables the alarms generated by the IMG 2020 to be displayed via SNMP. Refer to topic in Related Topics below.

Related Topics:

SNMP - Private MIBs 

F-6381 User Management

Brief Description:

Feature F-6381 adds to the IMG 2020 the ability to be able to encrypt and decode messaging going between an SSH and HTTPS Server. Within the system software binary file that gets downloaded to the IMG 2020 are four default certificate files. They are as follows:

• default_cert.pem

• default_key.pem

• wrapped_pwd.txt

• default_calist.pem
  
  

With these four files loaded, HTTPS and SSH are encrypted. Nothing needs to be done if the default certificates are used. If however, the customer wants to add their own certificates then the custom proprietary certificates need to be added to the system. Refer to the topics in the Related Topics section below for more information on this.

Feature F-6381 also modifies the password requirements when creating and modifying New and Existing Users. The Password requirements have been tightened so that only passwords that meet the requirements will be allowed. Refer to the Username Password Rules topic for information on the new requirements.

Related Topics:

Secure HTTPS/SSH 

Security 

Certificate Database

Certificate 

F-6416 Configurable Text Banner in Web GUI Login Dialog Box

Brief Description:

When logging into the Web GUI a Login Banner is displayed. Previous to F-6416, the login banner displayed fields where a username and password could be entered. With the addition of F-6416 Configurable text banner in Web GUI Login Dialog Box a banner screen can be added to the Login Box that can display any text that a user decides. Refer to the links in the Related Topics section below for more information on how to set up the dialog box to display a text banner prior to logging into the Web GUI.

Related Topics:

Configurable Login Text Banner 

F-6442 Cause Code Mapping

Brief Description:

The IMG 2020 currently has the ability to receive a cause code on an outgoing leg from any supported protocol (SIP, ISUP, H.323) and interwork that cause code into either the same protocol or a different protocol on the incoming leg. Feature F-6442 adds new functionality pertaining to cause code mapping. With the addition of this feature, the IMG 2020 can now map a cause code received on the outgoing leg to any other supported cause code. Once mapped, it is then transmitted out the incoming leg using the newly mapped cause code. Again, this functionality is supported between any of the supported protocols (SIP-SIP, SIP-ISUP, ISUP-ISUP, ISUP-SIP).

Related Topics:

Cause Code Values 

Cause Code Mappings 

Cause Code Conversions

Reject Call with a Cause Code

Customize / Map Cause Codes

Cause Code Tables

Cause Code Table

Cause Code Table Element

F-6443 Passing Referred-By Header in INVITE Message

Brief Description:

The Referred-By Header which is an optional header in the REFER request provides the recipient of the REFER message information on the originator of the request. Currently on the IMG 2020, it depends on the call flow as to whether the Referred-By header is passed or dropped. The new functionality added in F-6443 passes the Referred-by Header from the incoming to outgoing leg on a SIP to SIP call. Prior to this feature, the Referred-By Header was dropped. The new functionality encompasses both the Referred-By header in both the SIP-URI and tel-URI and is by default always enabled and cannot be disabled. Refer to the links in Related Topics section below.

Related Topics:

Passing Referred-By Header (SIP to SIP) 

F-6445 Support for P-Asserted-Identity Header with 2 URIs

Brief Description:

According to RFC 3325 section 9.1 "There may be one or two P-Asserted-Identity values. If there is one value, it must be a sip, sips, or tel URI. If there are two values, one value must be a sip or sips URI and the other MUST be a tel URI." Prior to the addition of feature F-6445 Passing P-Asserted-ID with two URI's, the IMG 2020 could pass only one P-Asserted-Identity value from an incoming SIP network to outgoing SIP network. With the addition of this feature, the IMG 2020 can now pass two P-Asserted-Identity Headers as long as RFC 3325 section 9.1 is adhered to. The functionality is by default enabled and cannot be disabled. Refer to the information in the Related topics below.

Related Topics:

Passing P-Asserted-ID with two URIs (SIP to SIP) 

F-6467 SNMP Trap to Report STM-1 Interface Status

Brief Description:

This feature is covered in the Private Alarm MIB Support feature (F-6318).

Related Topics:

n/a

F-6480 Propagate 180 Ringing to Ingress Leg

Brief Description:

Prior to Release 2.2, if the IMG 2020 received a SIP 180 Ringing from the egress or b leg of a call, the IMG 2020 would not propagate the 180 Ringing to the ingress or A leg of the call. Instead, a 183 Progress message with SDP and ringing tone would be generated and transmitted out the ingress or A leg side. Feature F-6480 adds new functionality when receiving the 180 Ringing message. The user can now choose between the current functionality or can configure the IMG 2020 to generate and transmit a 180 Ringing message to the ingress or A leg. Refer to the topic in the Related Topics section below.

Related Topics:

SIP Profile - SGP 

F-6481 Gateway Range for SIP and H.323 (Subnet Prefix Field)

Brief Description:

The field Allowed Gateway Subnet Prefix field was added to the External Gateway object so the IMG 2020 can be configured to accept calls from multiple gateways with one entry. The value entered in the new field Allowed Gateway Subnet Prefix field will work in conjunction with the value entered in the IP Address field to determine the range of IP Addresses from which the IMG 2020 will accept any calls. If the Incoming IP Address equals one of the IP Addresses in the range set up then the call will be processed. The allowed values in the Allowed Gateway Subnet Prefix field range from 0 to 32. Refer to the link in the Related Topics section below for more information on this feature.

Related Topics:

External Gateway 

F-6482 Configurable Expires Header

Brief Description:

The Expires Header limits the time the SIP INVITE message is valid. If the time configured in this header expires and no answer has been received from the far end, the User Agent Client will cancel the INVITE request. Feature F-6482 adds an INVITE Expires field to the SIP Headers object and allows a user the ability to modify the Expires Header timer value.

Related Topics:

SIP Profile - Headers 

F-6483 Configurable User Agent and Server Headers

Brief Description:

Feature F-6483 adds both the User-Agent and Server fields to the SIP Headers object. These two fields enable or disable whether the SIP User-Agent or SIP Server Headers will be included in the SIP messaging being sent between a User Agent Client and User Agent Server. Refer to the link in the Related Topics section for more information on the added functionality.

Related Topics:

 SIP Profile - Headers

F-6484 Configurable Call Answer Timeout and 183 Periodic Retransmission

Brief Description:

Feature F-6484 adds two new fields to the SIP Advanced Settings object. The first field added is the Call Answer Timeout. Prior to the introduction of this feature, when making an Early-Media SIP call, the IMG 2020 allowed up to 3 minutes for the call to get established. If the call was not accepted by the remote gateway within that time frame, the call was canceled. The new functionality allows the user the ability to configure the Call Answer Timeout anywhere from 3 minutes to 60 minutes and during this timeout period, the call will not be canceled unless separate factors either internal or external are used.

Because of the longer Call Answer Timeout value described above, the call can take longer to complete. The destination gateway on the B leg of the call can start periodically retransmitting the 183 Session Progress messages back to the IMG 2020. On the A leg of the call, the IMG 2020 can also start retransmitting 183 Session Progress messages once every minute. In this case,the IMG 2020 may end up sending twice the amount of 183 Session Progress messages back to the gateway on the incoming or A Leg of the call. One set of 183 Session Progress messages are sent from the response from the gateway on the B-Leg of the call and a second set of 183 Session Progress messages are sent from the IMG 2020 when the Retransmit timer in the IMG 2020 expires.

To solve the issue of too many retransmissions of the 183 Session Progress message, the second field labeled 183 Periodic Retransmission has been added to either enable or disable the retransmission of the 183 Session Progress messages on the A Leg of the call. In this situation only the 183 Session Progress responses from the external SIP gateway on the B Leg of the call will be transmitted out the A Leg of the call.

Refer to the topics in the Related Topics section below.

Related Topics:

Call Answer Timeout and 183 Periodic Retransmission functionality 

SIP Profile - Advanced Settings 

Upgrade EMS and BDN System Software

Brief Description:

An upgrade to a newer EMS and system software is required to make use of any new functionality that may have been added. Follow the procedure in the Software Upgrade - EMS System topic for information on upgrading both the EMS software running Red Hat Enterprise Linux on a separate VM along with the system software running on the IMG 2020 node.

Related Topics:

n/a

Rollback EMS and BDN System Software

Brief Description:

In the possible event that the upgrade procedure had issues or did not solve the intent of the upgrade, a rollback procedure can be executed to rollback to the previous EMS and node software. Follow the procedure in the Software Rollback - EMS/System topic for information on rolling back both the EMS software running Red Hat Enterprise Linux on a separate VM along with the system software running on the IMG 2020 node.

Related Topics:

n/a