IMG 1010 - SIP Profile - 10.5.1

Owned by Kelli Higdon
Last updated: Apr 01, 2024
11 min read

 

 

Description:

Use this pane to configure various SIP features on the IMG.

Making changes to a SIP Profile that is assigned to active calls may result in call failure or other adverse effects. Stop all traffic to gateways or channel groups that use a SIP Profile before you make changes.

Accessing this Pane:

Dialogic IMG EMS -> Profiles -> SIP SGP

Maximum Objects:

16 per IMG EMS object

Related Topics:

 IMG 1010 - Overview of SIP

ClientView Pane:  GCEMS Software 10.5.1:

ClientView Pane:  GCEMS Software 10.5.1_ER1:

Field Descriptions:

SIP Profile ID:

The IMG supports configuring ID's 0-15. ID:0 is the default SIP profile. When ID:0 is selected, none of the other fields within the SIP SGP pane can be changed. If however the ID is changed to a value other than 0 then the fields below it can be changed.

Once a custom SIP Profile is created, the custom profile can then be assigned to one of the entities shown below:

  • SIP Signaling object -> Remote IMG's SIP Profile field -or-

  • External Gateway Object --> SIP Profile field

Once a custom SIP profile is selected, the user will be unable to revert to the default SIP profile without creating a new SIP SGP Profile with a value of 0 as the ID.

SIP Profile Name:

A unique name entered into ClientView to identify the profile.

PRACK Support:

There 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 IMG to use PRACK transactions during call setup.

PRACK Timer (sec):

The PRACK Timer is used to request an “extension” of the transaction at proxies in case the INVITE transaction takes some time to generate a final response (RFC 3262 page 3). When the PRACK Refresh Timer expires the IMG will send out a 1xx reliable response.

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

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

CODEC Priority:

This feature allows you to configure whether the IMG or the remote gateway takes priority when selecting a codec.

Local- IMG takes priority

Remote- Remote gateway takes priority

Example:

If the IMG has a CODEC list of:

  • g711u

  • g729

  • g711a

Remote gateway offers:

  • g729

  • g711u

If Codec Negotiation Priority is set to Local, the IMG will answer with g711u.

If Codec Negotiation Priority is set to Remote, the IMG will answer with g729.

Outbound Modem Triggers Re-INVITE (10.3.3 ER2+):

Disable (default) - Feature is disabled

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

R-URI Header Tags:

To access the selections, click on the field and a Select Multiple Items Box will appear. Highlight the selection and select OK. If selected, the tag will be added into the R-URI of the outgoing INVITE in the “sip_uri_enc” method.

RN - The RN tag is used to convey the location routing number. See IMG 1010 - Local Number Portability (LNP) for more information.

NPDI - The NPDI tag is used to indicate whether an LNP query has been performed. See IMG 1010 - Local Number Portability (LNP) for more information.

CIC and DAI - 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 IMG 1010 - CIC and DAI Codes - SS7 ISUP to SIP for more information.

3xx Redirect Support:

Enable (default)- Send a new 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. The IMG will release the call when it receives a 3xx response from a redirect server and map the 3xx code to 4xx code.

See IMG 1010 - SIP Redirect Server Support for more information.

SIP Loop Detection:

When IMG detects that the sent-by value in the Via header field matches a value placed in a previous request then the IMG would detect that it is in a loop. The SIP loop detection field allows the IMG to do one of three things when a loop is detected.

Enable (Default)- If a loop is detected the IMG will reject the request with a 482 (Loop Detected) response. If the values differ then call processing will resume as normal.

Disable- IMG will initiate the check to see if there are similar sent-by values but will not reject the request if similar values are found

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

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

SIP INVITE Retransmission Attempts (UDP):

This feature allows you 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 ).

Apply the OTG to the outbound SIP Invite:

(In 10.5.1 ER1 this field was moved to the SIP TrunkGroup Selection object which is created under the SIP SGP Profile object):

On an outgoing invite, the OTG (Outgoing Trunk Group) that was received from the incoming call will take precedence over the internal IMG incoming Channel group name if it was a SIP call (for any other inbound protocol, the OTG would be the incoming Trunk Group Name). This OTG is then appended in the “From” header of the outbound invite.

  • Enable

  • Disable (default)

Use the incoming OTG for incoming Channel Group Selection:

(In 10.5.1 ER1 this field was moved to the SIP TrunkGroup Selection object which is created under the SIP SGP Profile object):

When the OTG (Outgoing Trunk Group) field is included in the “From” header the IMG will use this trunk group as the incoming trunk group to determine which incoming DPE table and route table to use. The OTG will also be added to the “From” header in an outbound SIP invite and the OTG will have the A side trunk group name.  

The IMG extracts the OTG from the SIP "From" header and passes in the Initial Setup. If an OTG is found, the IMG will use that channel group instead of the one that came from the lookup table in the SIP process.

  • Enable

  • Disable (default)

Use the DTG for outgoing channel group selection:

(In 10.5.1 ER1 this field was moved to the SIP TrunkGroup Selection object which is created under the SIP SGP Profile object):

When the DTG is received in the request-URI the IMG will skip the mid-call router and use the DTG that was received as the outbound channel group. When the IMG is about to perform routing for the outbound side, it will look for the DTG from the same location as the Calling Party Number. If the DTG is valid, the call will then use the channel group that corresponds to that DTG instead of performing a routing lookup

  • Enable

  • Disable (default)

Append (+) for Headers:

Use this field to prefix ‘+’ to the user if the incoming INVITE does not have ‘+’. Select one or more headers to apply the "+" to. To access the selections, click on the field in ClientView and a Select Multiple Items Box will appear. Highlight your selection and hit OK.

Remove (+) for Headers:

Use this field to remove a "+" from an incoming INVITE if you do not want it included in the outgoing INVITE. This can also be used in the case that the incoming side is not SIP. To access the selections, click on the field in ClientView and a Select Multiple Items Box will appear. Highlight your selection and hit OK.

INFO for Spirou/ITX (10.3.3 ER1+):

Use this field to enable the sending of the SS7 ITX message based on a SIP INFO message received from a SIP Application. This allows a SIP application to interwork with the SPIROU standard (Signalisation Pour l'Interconnexion des Réseaux Ouverts/Signaling for the Interconnection of Open Networks). See IMG 1010 - SPIROU-ITX in SIP INFO.

Outgoing Fully Qualified Domain Name (FQDN) (10.3.3 ER2+):

If this option is enabled and the Domain Name fields in the SIP signaling and VoIP Module (IMG 1010 - Facility pane) objects are filled with FQDNs, then all the outgoing request and response SIP messages will include FQDNs instead of IP addresses (Local IMG Signaling and VoIP Module IP addresses)

Disable - Disable Feature

Signaling Only- Only the FQDN of the local IMG signaling IP address is inserted in the outgoing SIP messages. 

SDP c=line Only- Only the FQDN of the local IMG VoIP IP address is inserted in the outgoing SIP messages. 

Both- The FQDNs of the local IMG signaling IP address and the local IMG VoIP address are inserted in the outgoing SIP messages. 

See IMG 1010 - Fully Qualified Domain Name Support for more information.

Incoming Reason Header Cause Code:

The Reason Header field provides the ability to propagate cause code information from SIP to TDM and TDM to SIP without having to configure SIP-T. The SIP Reason Header provides additional information on why a call was disconnected. This can include the Q.850 reason value and reason text.

Disable (Default) – The IMG will use RFC 3398 for interworking of the release cause.

Enable – The IMG will propagate the cause value from the first Reason Header with a valid Q.850 cause value.

See IMG 1010 - SIP Reason Header

Trusted:

This field applies to SIP signaling only. When this is set to Yes then all SIP Privacy information will be sent within the trusted domain boundary. When set to No then there will be no SIP Privacy information exchanged. See IMG 1010 - Configuring SIP Privacy and IMG 1010 - SIP Privacy Overview

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.

  • The first object in ClientView that will enable SIP Privacy is under the SIP Signaling Stack. (Physical IMG > Signaling > SIP Signaling). This will enable SIP Privacy for the entire GCEMS. The SIP Privacy is set globally in the SIP Signaling Pane on the IMG as either "On" or "Off". All calls will be handled according to this setting regardless of other SIP Privacy settings on an individual External Gateway or ISDN/ISUP Group.

  • The second place that SIP Privacy is configured is under the Profiles object in ClientView (Cantata IMG EMS > Profiles > SIP SGP). Set the Privacy Info field in the External Gateway object according to what is supported by the SIP Proxy to which the IMG is connected.

  • To enable Privacy for an ISDN Group or an ISUP Group, set the Discard Privacy Info field in the IMG 1010 - ISDN Group pane or the IMG 1010 - ISUP Group pane to Yes. 

If any of the external SIP gateways being configured in ClientView 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.

  • SIP Privacy must be set to "ON" under SIP Signaling Stack

  • A profile must be set under Cantata IMG EMS > Profiles > SIP SGP which has SIP Privacy "On"

  • Under the gateway object in ClientView the profile must be selected in the SIP Profile field 

REFER SUPPORT (10.5.1):

This is a drop down menu where the SIP REFER feature is enabled and disabled. When enabled, contact information such as the URI INFO is passed in the Refer-To Header field. The default is Disable. See  IMG 1010 - SIP REFER Call Transfer

Allow 180 after 183 (10.5.1):

The field is a drop down menu. Select either Yes or No. See below

Yes (Default)- The IMG will operate normally. The IMG will send a 180 Ringing following it sending a 183 Session Progress message if call flow requires

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

INFO Keep Alive Support (10.5.1):

Disabled (Default)

  • When a SIP INFO message is received the IMG will respond as per RFC3261. See below.

  • When a SIP INFO message is received and the dialog is unknown or there is no dialog the IMG will answer with a 415 message

  • When a SIP INFO message is received, the dialog is valid, and configuration does not match, the IMG will answer with a 488 message

  • When a SIP INFO message is received and SIP-T is enabled a 200 OK will be sent. In addition an INFO message will be sent to L4

  • When a SIP INFO message is received and it has invalid dialog information then a 481 message will be sent. If none of the previous conditions are met, a 200 OK will be sent

Enabled

  • When a SIP INFO message is received and the dialog is found the IMG will respond with a 200 OK message.

  • When a SIP INFO message is received and the dialog is not found the IMG will respond with a 481 Call Leg/Transaction Does Not Exist.

  • When a SIP INFO message is received and the content length of the SIP INFO message is 0, the IMG will respond with a 200 OK
     

See IMG 1010 - SIP INFO Method - Long Call Duration Auditing

Acceptable Inbound Call Type:

This field is for inbound calls only and applicable if an external gateway is configured to use TLS. The field is used to specify whether non-TLS inbound calls will be accepted or rejected by the IMG from this gateway, i.e. UDP or TCP call attempts. Therefore the field enforces the use of TLS as a preference or a requirement for a specific SIP profile assigned to an external gateway.

Make encrypted Calls, Accept all calls (Default)-  If a non-encrypted call is received from an external gateway, the 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 IMG server port will not accept the call.

Enable SIPS: (10.5.1):

SIP provides a secure URI, called a SIPS URI. If an external gateway is configured to use TLS security, then this field is used to select the URI scheme sips or sip. See example below.

Disabled (Default)- When disabled the SIP URI scheme is formatted as shown below:  

 sip:alice@atlanta.com;transport=tcp

Enabled- When enabled the SIP URI scheme is formatted as follows:

sips:alice@atlanta.com;transport=tcp  

SIP-T Pass On: (10.5.1):

When SIP-T is enabled on the IMG, it is enabled globally. If however there is an external gateway that SIP-T is either not supported on or not enabled the 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 sent between SIP and SS7.  

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

 

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

Hold/UnHold Propagation (10.5.1_ER1+):

Use this field to configure the 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.

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. See Call Flow Diagram below.

 

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.

Return to Documentation Home I Return to Sangoma Support