SIP Profile

Description:

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

 

 

WARNING: 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:

SIP Features

 

ClientView Pane:  GCEMS Software 10.5.1:

sc_sip_prack_pane_sgp_1051.png

ClientView Pane:  GCEMS Software 10.5.1_ER1:

sc_sip_sgp_profile_10.5.1_er1.png

 

 

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:

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

 

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

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 LNP Routing for more information.

NPDI = The NPDI tag is used to indicate whether an LNP query has been performed. See LNP Routing 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 SIP Carrier Identification Code 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 SIP Redirection 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.

 

**Note:  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.

 

 

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.

 

 

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

 

 

Note: The next two fields apply to the Pass through ‘+’ sign in the user part of URI feature

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.

sc_sip_profile_append.png

 

 

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.

sc_sip_profile_append.png

 

 

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 Support for 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 (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. See Call Trace.

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

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

 

See 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 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 Configuring SIP Privacy and 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.

 

Note: 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.

 

 

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 SIP REFER link in Related Topics above.

 

 

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.

 

 

INF0 Keep Alive Support (10.5.1):

Disabled (Default)

 

Enabled

 

See SIP INFO Method-Long Call Duration

 

 

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.

 

Note: 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.

 

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

 

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