SIP Profile

Description:

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

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

sc_sip_sgp_profile_1053.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 (seconds):

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.

isub/isub-encoding - The IMG will interwork ISDN Subaddresses to SIP isub and isub encoding parameters and the isub and isub encoding parameters will be interworked into ISDN Subaddresses. The parameters mapping is accomplished between the R-URI SIP To Header and the ISDN Calling Party Subaddress isub/isub-encoding parameters.

 

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:

A loop is a situation where a request that arrives at the IMG is forwarded, and later arrives back at the same 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 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 IMG can be configured to employ a loop detection algorithm. This algorithm affects the way the IMG builds the via-branch field. When the IMG detects that the sent-by value in the Via header field matches a value placed in a previous request, the IMG would determine that it is in a loop situation. 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 and the sent-by value in the via header are identical, the IMG is determined to be in a loop condition, the 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 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 IMG will determine this as a loop 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 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):

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 created under the SIP SGP 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 created under the SIP SGP 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 created under the SIP SGP 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.

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

Note: In software 10.5.3 the SIP Refer object was moved from being a field in the SIP SGP object to being a child object of the SIP SGP object. To access the SIP Refer functionality in software 10.5.3 and beyond simply right click on the SIP SGP object pane and select New SIP Refer Support. See SIP Refer Support link for more information.

 

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)

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: sip:alice@atlanta.com;transport=tcp

Enabled - When enabled the SIP URI scheme is formatted as: 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:

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

 

Retry-After Support:

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

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

 

Multiple Codecs Support:

Not supported as of 10.5.2.

 

Clear Channel Override:

Disable (Default) - Feature 1261 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 IMG will force the outgoing Codec to be clear channel. See Clear Channel Codec for more information.

 

Phone Context Support:

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:

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 IMG to accept a NOTIFY message without a subscription.

Allow - Allow the 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 INVITE's from IMG shall contain offer (SDP), normal call scenario.

Enabled - Delayed media feature is enabled. 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 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 IMG generates answer (SDP) in ACK.

See SIP Delayed Media Calls - Outbound.

 

SRTP Mode:

Disable (Default) - The SDP content  within the outgoing SIP INVITE will not contain SRTP information. Incoming SIP INVITE messages with SDP that only contain media entry with SRTP information will be rejected with 488 Unacceptable Media.

Mandatory - The SDP content within the outgoing SIP INVITE will contain the SRTP information as per SGP configuration. Incoming SIP INVITE message must include satisfying  SRTP information in its SDP. Otherwise, The INVITE will be rejected with 488 Unacceptable Media.

RTP fallback - For incoming SIP INVITE message, IMG first analyses SRTP information present in the SDP. If the SRTP information does not comply with the current SGP configuration or if it is  simply not present, the IMG will fall back to the RTP information, regardless of the SRTP content. For outgoing SIP INVITE, SRTP information Will be first sent as per SGP configuration. In the case of a 488 response, the IMG will send another INVITE without SRTP information.

SRTP mode SDP content and IMG behavior for Incoming Calls

SRTP Configuration Value

Incoming SDP content

IMG Behavior

Disabled

RTP Only

Analyze RTP SDP content

SRTP Only

Reject the call with 488 - Unacceptable Media

RTP and SRTP

Analyze RTP SDP content

SRTP Mandatory

RTP Only

Reject the call with 488 - Unacceptable Media

SRTP Only

Analyze SRTP SDP content

RTP and SRTP

Analyze SRTP SDP content

SRTP with RTP Fallback

RTP Only

Analyze RTP SDP content

SRTP Only

Analyze SRTP SDP content

RTP and SRTP

Analyze SRTP SDP content. If not satisfying then Analyze RTP content

SRTP Mode SDP content and IMG behavior for Outgoing Calls

SRTP Configuration Value

Outgoing SDP content

IMG Behavior

Disabled

RTP Only

Current Behavior

SRTP Mandatory

SRTP only

The SDP will contain the crypto-suites selected in the SIP SGP. The IMG will accept only SDP answer which content is compatible with its SRTP configuration.

STRP with SDP Fallback

First INVITE with SRTP only

The SDP will contain the crypto-suites selected in the SIP SGP. IMG will accept only SDP answer that are compatible with its SRTP configuration. On 488 response generate an IMVITE with RTP

Second INVITE RTP only

IMG will accept SDP answer which content is compatible with its SRTP configuration.

 

Re-attempt Outgoing Call On MID:

Disabled (Default) - The re-attempt outgoing call on MID is disabled.

Enabled - The re-attempt outgoing call on MID is enabled. This will trigger the re-attempt of the call when MID is received.

 

Ptime Source For SDP Answer:

Match Remote (Default) - If set to "Match Remote", the backwards compatible behavior holds. If a valid ptime is received in the SDP offer from the remote side, this same value will be used in the SDP answer from the IMG.

Use Preferred Payload Size - If set to "Use Preferred Payload Size", the ptime value sent from the IMG in the SDP answer will be the Preferred Payload Size value for the selected codec in the IP Profile. This method allows the IMG to independently specify the payload size it prefers to receive, allowing the possibility of asymmetric ptime/packet sizes. This is allowed per RFC 3264 and is the definition for the ptime value in an SDP. However, not all SIP clients interoperate with asymmetric ptime values.