IMG 1010 - SIP Profile - 10.5.3

Description:

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

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

Open

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

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

• When 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.

CICand 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.

tty-ind - To be set when the Baudot Tone detection is enabled in IMG 1010 - IP Bearer Profile. When so, the IMG will use this tag within the SIP Re-INVITE R-URI header to indicate the remote SIP UA that the call is used by a Baudot tone device so G.711 codec must be used.

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.

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

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.

Open

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 Support for SPIROU/ITX in SIP INFO .

Outgoing Fully Qualified Domain Name (FQDN):

If this option is enabled and the Domain Name fields in the SIP signaling and VoIP Module ( Facilty 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 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 ISDN Group pane or the 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. 

Allow 180 after 183:

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:

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

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 :

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.

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.

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.

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.

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 IMG 1010 - 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 IMG 1010 - Clear Channel Codec for more information.

Phone Context Support:

Select from drop down menu one of the following choices. See IMG 1010 - 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 IMG 1010 - 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 Mode SDP content and IMG behavior for Outgoing Calls

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.