SIP Signaling Gateway Profile (SGP)

When communicating with an external gateway there are various attributes/features that need to be associated with that particular gateway. Within the SIP Signaling Gateway object the user can configure these attributes/features. Once configured, the SIP Signaling Gateway Profile can be associated with SIP Signaling object, the External SIP Gateways object and External ENUM Server Sets object. The SIP Signaling Gateway Profiles configured will all be selectable from a drop down menu in each of the objects described above. In addition to the fields in the SIP Signaling Gateway Profile, there are also multiple objects that can be configured under the SGP that add additional features/attributes.

Note: Making changes to a SIP Signaling Gateway Profile that is assigned to active calls may result in call failure or other adverse effects. Before making changes, stop all traffic to any gateways or ENUM Server Sets that are using the SIP Signaling Gateway Profile.

 

ClientView Pane

IMG EMS > Profiles > SIP SGP (Signaling Gateway Profile)

SC_SIP_SGP.png

 

Maximum Objects

Up to 16 Signaling Gateway Profile objects can be created per Profiles object

 

Related Topics and Dependencies

When creating the SIP Signaling Gateway Profile object, the SIP Profile ID:0 is a default profile and the individual fields within this object cannot be modified. Change the SIP Profile ID to something other than ID:0 and the fields will change from green to white. At this point the individual fields can be modified.

SIP Signaling

External Gateway

ENUM Server Set

 

Field Descriptions

SIP Profile ID

The 2020 IMG supports configuring ID's 0-15. ID:0 is the default SIP profile. If the SIP Profile ID is not modified and the default ID of 0 is kept, none of the fields within the SIP Signaling Gateway Profile object can be modified. If however the ID is changed to a value other than 0 then the fields below it can then be modified. Once a custom SIP Gateway Profile has been created, the profile can then be assigned to one of the entities shown below:

Once a custom SIP profile has been created and selected into one of the above objects, the SIP Signaling Gateway Profile ID cannot be modified. User will need to create a new SIP Signaling Gateway with a different SIP Profile ID and replace the old SIP Signaling Gateway Profile with the new one just created.

 

SIP Profile Name

Enter a unique name that identifies the SIP SGP being created. The default name is set to default. For a list of valid characters that can be used refer to Valid Characters topic.

 

PRACK Support

Within the PRACK Support field is drop down menu with the following selections. PRACK is disabled by Default.

Disable (default) - Disable sending Provisional Ack message.

Supported - Provides the ability to handle PRACK transactions during call setup if the SIP peer requires it.

Required - Requires the SIP peer and the 2020 IMG to use PRACK transactions during call setup.

 

PRACK Timer (sec)

If User Agent Server (2020 IMG) is not able to answer an INVITE immediately the 2020 IMG will start sending out a reliable 1xx response indicating it needs an extension to prevent a proxy from canceling the call (RFC 3262 page 3 -and- RFC3261 13.3.1.1). The PRACK timer field configures the interval at which these reliable 1xx provisional acks are sent to the far end. Once the timer expires a 1xx reliable response is sent back to get an extension. The Default is every 150 seconds but can be changed to every 60 seconds. See Below

150 (seconds) (Default) - Wait 150 seconds before sending the 1xx message.

60 (seconds) - Wait 60 seconds before sending the 1xx message.

 

CODEC Priority

Allows user to configure the 2020 IMG to specify whether the 2020 IMG or the remote gateway takes priority when selecting a codec during the CODEC negotiation process.

Local - 2020 IMG takes priority when negotiating for CODEC.

Remote - Remote gateway takes priority when negotiating for CODEC.

Example: See table below.

2020 IMG Codec Offering by priority

Remote Gateway Codec Offering by priority

If Codec Negotiation Set To Local

If Codec Negotiation Set To Remote

  1. g.711u

  2. g.729

  3. g.711a

  1. g.729

  2. g.711u

g.711u will be selected

g.729 will be selected

 

Outbound Modem Triggers Re-INVITE

Disable (Default) - Feature is disabled

Enable - The 2020 IMG will send a re-INVITE to the far-end when it detects modem traffic. The 2020 IMG switches the RTP into Modem Bypass mode over G.711. The 2020 IMG will then use the bypass codec type specified in the associated Bearer Profile (u-law or a-law). Incoming Re-INVITE's during modem calls are accepted automatically.

 

R-URI Header Tags

Click on the selection within the R-URI Header Tags field. The tag selected (highlighted in blue) will be added into the R-URI of the outgoing INVITE in the sip_uri_enc method. To highlight more than one selection, hold down the <Ctrl> key while clicking the selection. Selections are described below.

None (Default) - No tags will be added to outgoing INVITE.

RN (Routing Number) = The RN tag is used to convey the location routing number. Refer to the LNP Routing topic for more information.

NPDI (Number Portability DIP Indicator)  = The NPDI tag is used to indicate whether an LNP query has been performed. See LNP Routing for more information.

CIC (Carrier Identification Code) and DAI (Dial Around Indicator) = The CIC parameter is a three or four digit code used in routing tables to identify the network that serves the remote user when a call is routed over many different networks. The DAI parameter will be displayed immediately after the CIC code . See SIP Carrier Identification Code for more information.

 

3xx Redirect Support

In a SIP network it is very common to have a re-direct server which determines where to route the call. The redirect server will reply with a 3xx response with a list of contacts to redirect to. If the feature is enabled, the 2020 IMG will try communicating with each of the contacts one at a time until the call is completed. 2020 IMG will send a maximum of 10 call attempts. The 2020 IMG only accepts redirects to another endpoint within the SIP network.  

Enable (default) - Send an INVITE to the contact returned in a 3xx response from a redirect server.

Disable - Do Not send a new INVITE to the contact returned in a 3xx response from a redirect server. Release the call when it receives a 3xx response from a redirect server and map the 3xx code to a 4xx (Client Error) code.

See SIP Redirect Server Support for more information.

 

SIP Loop Detection:

A loop is a situation where a request that arrives at the 2020 IMG is forwarded, and later arrives back at the same 2020 IMG. An illegal loop occurs if the second time the request arrives, the values in the second request are the same. In the latter case, the 2020 IMG will forward the request the same way it did the first time. Every other entity along the loop path may do the same. This causes an error condition where the message is looped through a set of sip entities for an undefined number of times, but never reaching its final destination. The 2020 IMG can be configured to employ a loop detection algorithm. This algorithm affects the way the 2020 IMG builds the via-branch field. When the 2020 IMG detects that the sent-by value in the Via header field matches a value placed in a previous request, the 2020 IMG would determine that it is in a loop situation. The SIP loop detection field allows the 2020 IMG to do one of three things when a loop is detected.

Enable (Default) - If a loop is detected and the sent-by value in the via header are identical, the 2020 IMG is determined to be in a loop condition, the 2020 IMG will reject the request with a 482 (Loop Detected) response. If the sent-by value in the via header are determined to be different, call processing will resume as normal. This condition could be considered as a spiraling condition such as call forwarding.

Disable - The 2020 IMG will initiate the check on the via header to determine if the sent-by values are similar. If the sent-by values are similar the 2020 IMG will determine this as a loop but will not reject the request if similar values are found.

Disable with no Header Check - 2020 IMG will not check to see if there are similar sent-by values.

 

**Note:  Certain conditions will still result in a 482 (Loop Detected) response regardless of SIP Loop Detection setting. For example, two calls being received from the UAC with matching Call-IDs)

 

SIP Loop Detection Routing Method:

This field decides how the call is to be routed upon receiving an incoming SIP call while the loop detection is disabled and a loop situation is detected.

To header (Default) - If the SIP Loop Detection is set to Disable or Disable with no header check and a loop is detected, the incoming SIP call will be routed based on the value in the To: header of the incoming INVITE message..

R-URI - If the SIP Loop Detection is set to Disable or Disable with no header check and a loop is detected, the incoming SIP call will be routed based on the value in the Request URI of the incoming INVITE message.

 

SIP INVITE Retransmission Attempts (UDP)

If there is no response to a SIP INVITE request then the INVITE is re-transmitted. This fields allows the 2020 IMG to limit the number of INVITE re-transmission attempts (1-5 attempts). The number configured supersedes the standard # of re-transmissions specified in RFC 3261 (which is based on timers T1 and T2 ).

Retransmit All (Default) - Retransmit the SIP INVITE Request until SIP Timers expire. For more information refer to RFC 3261.

1-5 - Select from drop down menu the number of INVITE re-transmissions. Selections range from 1 to 5 retransmission attempts.

 

Append (+) for Headers

Important Note: The next two fields (Append + for Headers and Remove + for Headers) apply to the Pass through + character in the user part of URI feature. The prefix + cannot be used for routing. The feature simply adds, passes through, or removes the + prefix.

Use the Append (+) for Headers field to add the prefix + to any outgoing INVITE requests if the incoming INVITE does not have +. Click on one or more selections within the Append (+) for Headers field. The chosen selections (highlighted in blue) will have the prefix + appended to the outgoing INVITE. To highlight more than one choice, hold down the <Ctrl> key while clicking the selection.

 

Remove (+) for Headers

Use the Remove (+) for Headers field to remove the + prefix from an incoming message. The outgoing INVITE request will not include the + prefix. This feature can also be used in the case where the incoming side is not SIP. Click on one or more choices within the Remove (+) for Headers field. The chosen selections (highlighted in blue) will have the prefix + removed from the outgoing INVITE. To highlight more than one choice, hold down the <Ctrl> key while clicking the selection.

 

INFO for Spirou/ITX

The ITX/TXA messages are used in a Spirou (Signalisation Pour l'Interconnexion des Réseaux Ouverts/Signaling for the Interconnection of Open Networks) network for audio services that are paid for by either a flat rate calculation or time based calculation. The 2020 IMG supports sending both the ITX and TXA messages. The INFO for Spirou/ITX field enables or disables the sending of these messages. Refer to SPIROU/ITX in SIP INFO topic for more information.

Disable (Default) - Support for the Spirou Variant is disabled.

Enable - When enabled there are two scenarios. SS7 to SIP and SIP to SS7. See below.

 

Outgoing Fully Qualified Domain Name (FQDN)

The Fully Qualified Domain Name is a domain name which specifies an exact location of a piece of equipment within a Domain Name System. (Ex. myhost.example.com). The 2020 IMG allows user to input a FQDN in a number of different objects. The FQDN is entered in place of the IP address. If the Outgoing Fully Qualified Domain Name field is enabled, the 2020 IMG will include the FQDN in its outgoing requests and response messages. The feature is disabled by default and can be modified to send out the FQDN in place of IP addresses for the local SIP Signaling port, the local VoIP Module Port, or both. See Below.

Disable (Default) - Feature is disabled. Only IP Addresses are sent with outgoing requests and responses.

Signaling Only - The Fully Qualified Domain Name assigned to the local SIP Signaling port in the SIP Signaling object is inserted in the outgoing SIP messages. See SIP Fully Qualified Domain Name Support topic.

SDP c=line Only - The Fully Qualified Domain Name assigned in the VoIP Resource object is inserted in the outgoing SIP messages and responses.

Both - The Fully Qualified Domain Name assigned to both the VoIP Resource and SIP Signaling objects are inserted in the outgoing SIP messages.

 

Incoming Reason Header Cause Code

The Reason Header describes through the use of cause codes why a SIP request or response was issued. The Reason Header is issued in the BYE, CANCEL, 4xx, 5xx, and 6xx requests/responses. The Reason Header field provides the ability to propagate cause code information from SIP leg to TDM leg and/or TDM leg to SIP leg without having to configure SIP-T. The SIP Reason Header will provide additional information on why a call was disconnected. The cause codes implemented are based on ITU-T Recommendation Q.850. The interworking of cause code values are based on RFC 3326

Disable (Default) – The 2020 IMG will interwork of the release cause codes based on RFC 3398 ISUP to SIP Mapping.

Enable – The 2020 IMG will propagate the cause value from the first Reason Header with a valid cause value based on ITU-T Recommendation Q.850.

For more information refer to SIP Reason Header

 

Trusted:

The Trusted field applies to whether privacy information is allowed or stripped when passing information within a SIP Trusted Domain to a specific gateway. The Trusted field applies to SIP signaling only. When set to Yes then all SIP Privacy information will be sent within the trusted domain boundary. When set to No, there will be no SIP Privacy information exchanged. Refer to SIP Privacy topic for more information.

Yes (Default) - SIP Privacy information is sent to a specific gateway within the trusted domain.

No - SIP Privacy information will be stripped when sent to a specific gateway within a trusted domain

 

SIP PRIVACY

SIP Privacy field configures whether there will be SIP Contact information offered in the SIP messaging. SIP Privacy is configured in two separate objects in ClientView as described below.

Note: If any of the external SIP gateways being configured in the Web GUI are going to have SIP Privacy enabled then the first global setting must be enabled.

In order to configure SIP Privacy on the individual gateways the next few steps must be followed. This will allow configuring SIP Privacy on some gateways and not others.

 

Allow 180 after 183

In a normal call flow the 183 Session Progress message indicates whether the calling user agent should provide alerting or not. Once the 183 has been sent then a 180 Ringing message is sent dependent on the specific call flow. The Allow 180 after 183 field can be configured either to allow or suppress the 180 Ringing message. See Below

Yes (Default) - 2020 IMG will send a 180 Ringing message after sending a 183 Session Progress message if the specific call flow requires.

No - The 2020 IMG will not send a 180 Ringing message if a 183 Session Progress with SDP has already been sent to the remote SIP side.

 

INF0 Keep Alive Support

Disabled (Default)

Enabled

Refer to SIP INFO Method-Long Call Duration topic for more information

 

Acceptable Inbound Call Type

The Acceptable Inbound Call Type field is for inbound calls only and is applicable if an external gateway communicating with 2020 IMG is configured to use TLS. The field is used to specify whether non-TLS inbound calls will be accepted or rejected by the 2020 IMG from this gateway. (i.e. UDP or TCP call attempts) The Acceptable Inbound Call Type field enforces the use of TLS as a preference or a requirement for a specific SIP profile assigned to an external gateway. See Below

Make encrypted calls-accept all calls (Default) -  If a non-encrypted call is received from an external gateway, the 2020 IMG server port will accept the call.

Make and accept only encrypted calls - If a non-encrypted call is received from an external gateway, the 2020 IMG server port will not accept the call.

 

Enable SIPS

SIP provides a secure URI called SIPS URI. If an external gateway and the 2020 IMG are configured to use TLS security, then this field is used to select the URI scheme sips or sip. If TLS is not configured on the 2020 IMG then the Enable SIPS field will be ignored. If TLS is configured on 2020 IMG then the selections below are valid. See example below.

True (Default) - When set to true the SIP URI scheme is formatted as follows:

sips:alice@atlanta.com;transport=tcp  

 

False - When set to false the SIP URI scheme is formatted as shown below:

sip:alice@atlanta.com;transport=tcp

 

SIP-T Pass On

When SIP-T is enabled on the 2020 IMG, it is enabled globally. If however there is an external gateway that SIP-T is either not supported on or not enabled, the 2020 IMG can disable SIP-T to that gateway. In the SIP-T Pass On field there is a drop down menu where you can select yes or no.

Yes - If Yes is selected, SIP-T will be enabled and any ISUP messaging will be sent between SIP and SS7.  

No - If No is selected, SIP-T will be disabled and no SIP-T messaging will be sent between SIP and SS7.

Note: If no is selected and the external gateway sends the IMG SIP-T messaging, the 2020 IMG will not transfer the SIP-T ISUP information. The 2020 IMG will operate as if SIP-T were not enabled and pass only the SIP messaging.

 

Hold/UnHold Propagation

Use this field to configure the 2020 IMG to either propagate or not propagate a SIP INVITE Hold message (c=IN IP4 0.0.0.0) to the outbound SIP INVITE message. See Below.

Note: The Call Flows below display a SIP to SIP call. The Hold/Unhold Propagation feature supports SIP to SS7 and SS7 to SIP as well

Enable (Default) - When the Hold/UnHold Propagation field is set to enable then the SIP INVITE that contains the Hold message will be propagated to the remote leg of the call.

CF_SIP_Hold_Unhold_Propagation_Enable.png

Disable: When the Hold/UnHold Propagation field is set to disable then the SIP INVITE that contains the Hold message WILL NOT be propagated to the remote leg of the call.

CF_SIP_Hold_Unhold_Propagation_Disable.png

 

Retry After Support

The 2020 IMG supports sending and receiving the Retry Header in the event there is SIP congestion. When the Retry after support field is set to enable, the 2020 IMG would determine the level of SIP congestion. If it is determined that SIP congestion levels are acceptable, the call will go through. If however congestion levels are high, the 2020 IMG will send a 503 Service Unavailable along with a Retry Header indicating time to wait before re-sending INVITE back to 2020 IMG. Refer to SIP Retry-After-(Transmit) and SIP Retry-After-(Receive) for more information.

Enable (Default) - The 2020 IMG will respond with a Retry-After Header in its response if the Channel Group is congested.

Disable - The 2020 IMG will not send a Retry-After Header in its response if Channel Group is congested.

 

Clear Channel Override

The 2020 IMG supports the Clear Channel Codec as described in RFC 4040.

Disable (Default) - Clear Channel Override is disabled. The Outgoing Codec will not be forced to Clear Channel even if the incoming parameters dictate the correct conditions. See Clear Channel Codec for more information.

Enable - If the Bearer Capability value of the incoming call matches a certain set of requirements and the 'Clear Channel Override' field in the SIP SGP Profile pane on the outgoing side is set to enable then the 2020 IMG will force the outgoing Codec to be clear channel. See Clear Channel Codec for more information.

 

Phone Context Support

The Phone-Context Parameter (RFC 3966) is supported on the 2020 IMG for outgoing INVITE requests only. Select from drop down menu one of the following choices. See SIP Phone Context Parameter for more information.

Disable (Default) - Phone Context support is by default disabled.

Include in To: Header - Include the Phone Context Parameter in the To: Header only.

Include in From Header - Include the Phone Context Parameter in the From: Header only.

Include in both To: and From: Headers - Include the Phone Context Parameter in both the To: and From: Headers.

 

Phone Context String

If Phone Context Support field above is set to Disable then the Phone Context String field cannot be modified. To be able to modify the Phone Context String field, change the Phone Context Support field to one of the choices other than Disabled. Once accomplished, click in the Phone Context String field and enter the Phone Context String which can be one of two formats. The two formats are either by digit string or by domain name. Max number of characters is 64. Below are a few examples:

Digit String = 1508862

Domain Name = hyannis.dialogic.com

 

Allow NOTIFY w/o Subscription

Choose from a drop down menu the following selections:

Disallow (Default) - Do not allow the 2020 IMG to accept a NOTIFY message without a subscription.

Allow - Allow the 2020 IMG to accept a NOTIFY message without a Subscription. The Notify message will be accepted without a subscription only if the parameters Content Type = application/simple-message-summary and Event = message summary are in the SIP NOTIFY message. Select Allow when configuring the Message Waiting Indicator feature.

 

Outbound Delayed Media

Disabled (Default) - Delayed media feature is disabled. Outgoing INVITEs from 2020 IMG shall contain offer (SDP), normal call scenario.

Enabled - Delayed media feature is enabled. 2020 IMG generates INVITE without offer (SDP) and expects offer (SDP) from the remote end either in reliable provisional response or in the final response (200 OK). If the offer is received in reliable provisional response, then 2020 IMG generates answer (SDP) in PRACK. Also in this scenario, the final  response must either contain no offer or have the offer same was in the reliable provisional response else the call will be released. If the offer is received in the final response, then 2020 IMG generates answer (SDP) in ACK.

Refer to SIP Delayed Media Calls-Outbound topic for more information.