SIP Signaling

The 2020 IMG supports the SIP protocol as described in RFC 3261. To configure the 2020 IMG to process calls using the SIP protocol, a SIP Stack must first be created. The SIP stack must be created on each 2020 IMG node to be able to process SIP signaling. This is accomplished by creating a SIP stack using the SIP Signaling object. Right Click on the SIP Signaling object and select SIP. Follow steps below to configure the SIP Stack to be used for SIP Signaling. See information below.


ClientView Pane

Dialogic BDN > BDN Name > Signaling > SIP



Max SIP SGP objects within Web UI

One SIP Signaling object per 2020 IMG Node.


Related Topics and Dependencies

A separate SIP stack must be created for each individual Physical 2020 IMG. Once the SIP stack is created, SIP Signaling is enabled on the 2020 IMG.

SIP Overview

Configuring SIP


Field Descriptions

SIP Signaling IP Address

The SIP Signaling IP Address field has a drop down menu displaying the IP addresses of all the interfaces configured under the IP Network object that could be used to pass SIP Signaling. Select the IP Address from drop down menu.


Local SIP Port

This field defaults to Port 5060 which is the port that is used for SIP signaling when transporting over TCP or UDP. The port number can be changed by clicking in the Local SIP Port field and entering a different port number.


Local TLS Port

This field defaults to Port 5061. Port 5061 is the port that is used when communicating with an external entity using TLS. The port number can be changed by clicking in the Local TLS Port field and entering a different port number. To be able to modify the TLS port, verify that TLS is initially enabled in the Default Transport Type field below.


SIP Compact Header

The 2020 IMG can be configured to represent the SIP Headers in either a non-abbreviated standard form or an abbreviated form. The abbreviated form is useful when messages become too large to be carried on the transport available to it. A compact form may be substituted for the longer of a header field name without changing the semantics of the message. Select from drop down menu whether to enable or disable the shorter form. See below.

Enable - If enabled is selected, the SIP message will be an abbreviated message according to RFC 3261 Sec 7.3.3 Compact Form. A wireless application where bandwidth needs to be limited is a good reason for using compact headers.

Disable - If disabled, the SIP message will send non-abbreviated message.


Transport Type

Select from drop down menu UDP, TCP, or TLS. The 2020 IMG Defaults to UDP. If TLS is selected, the Secure Profile and Default Secure Profile Fields can now be modified. Initially, they can not be changed when UDP or TCP is selected.


SIP UserName (AOR)

A SIP Identifier, Public Address, or Address of Record (AOR) specifies the To: and From: URI user part that will be used in any outbound messaging. This field defaults to: DIALOGIC-BDN. To modify, click in the Username (AOR) field and enter a different username. This field is commonly referred to as Public Address.


Authentication UserName

Username used for authentication to guard against hijacking. To add a username, click in the Default SIP Authentication Username field and enter username.


Authentication Password

Password used for authentication to guard against hijacking. To add a password, click in the Default SIP Authentication Password field and enter a password.


SIP-T Enabled

SIP-T is a mechanism used to interwork ISUP messaging from the PSTN into SIP messaging for transport through a SIP network. SIP-T allows traditional ISUP parameters to originate in an ISUP network, transport those messages across SIP Network using UDP,TCP, or TLS and then terminate in a second ISUP Network. To confgure SIP-T on the 2020 IMG select either Yes or No from drop down menu.

No (Default) - Do not inter-work ISUP messaging into SIP-T format for transport.

Yes -  Inter-work ISUP messaging into SIP-T format for transport.

For configuration information, see Configuring SIP-T link

Note: The 2020 IMG can also accept a SIP message from a SIP endpoint which originally has no ISUP information in it and create a SIP-T message which has the ISUP information embedded in its SIP body and send this SIP-T message to a SIP-T endpoint. See the SIP to SIP-T Interworking object link for more information on configuration etc.


SIP-T Behavior

This field defaults to Not Used when SIP-T is not enabled. When enabled the selections Optional and Required can be chosen.

Optional - Optional is the default. If Optional is selected, and the far end does not support SIP-T, the call will not be released.

Required - If Required is selected, and the far end does not support SIP-T, the call will be released.


Privacy Support

To enable Privacy, set the Privacy Support field to the method supported by the proxy. All calls will be handled according to this setting regardless of other SIP Privacy settings on an External Gateway or ISDN/ISUP Group.

P-Asserted only - The P-Asserted-Identity header field is sent in the SIP messaging. The P-Asserted-Identity header field is used among trusted SIP entities to carry the identity of a user sending a SIP message as it was verified by authentication. A proxy server which handles a message can, after authenticating the originating user, insert such a P-Asserted-Identity header field into the message and forward it to other trusted proxies. A proxy that is about to forward a message to a proxy server or UA that it does not trust MUST remove all the P-Asserted-Identity header field values if the user requested that this information be kept private.

Remote-Party only - The SIP Remote-Party-ID header identifies the calling party and includes user, party, screen and privacy headers that specify how a call is presented and screened. The new header contains a URL and an optional display name that identifies a user. A valid Remote-Party-ID header may be either a SIP URL or a TEL URL. See the sections Remote-Party-ID Syntax and Screening and Presentation Information for more information on the syntax of the new header. The following example shows representative.

Both - Both the remote party info and the P-Asserted Identity is sent in the SIP messaging.

Off (default) - Neither the P-Asserted Identity header nor the Remote Party ID header is sent.

See SIP Privacy


SIP Group Profile

Select from a drop down menu a SIP SGP which will define how a remote 2020 IMG should treat a call going to or coming from the local 2020 IMG.


Secure Profile

If TLS is selected in the Default Transport Type field then the Secure Profile field becomes active. The Secure Profile field will display a list of all the available secure profiles created and once selected, will be used when the 2020 IMG behaves as an external gateway. Select one of the profiles from the drop down list.


Default Secure Profile

If a SIP transaction is received by the 2020 IMG on the TLS Port but the external gateway sending the call is not configured to use TLS security, the call will fail. To avoid this from happening, select a Secure Profile from the Default Secure Profile list. If an external gateway, not configured for TLS, sends a SIP message to the TLS Port the message will be processed using the credentials defined by selected default secure profile.


Fully Qualified Domain Name (FQDN)

The FQDN to be inserted in outgoing SIP messages when FQDN is enabled in the SIP Profile. See Fully Qualified Domain Name Support for more information.


Retry-After (# of Seconds)  (Default=5 seconds)

The number of seconds (1 - 65535 seconds) the 2020 IMG will inform a remote inbound gateway to wait before re-sending a SIP INVITE message. The 2020 IMG informs the remote gateway by use of the Retry-After Header Field in its response.  See SIP Retry-After Header -or- SIP Retry-After Header-Receive for more information. To modify the Retry-After field either click in the Seconds box and enter the number of seconds to wait or use the sliding scale to modify.

Note: The Retry After field in the SIP SGP object must be enabled.