SIP 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 object described in this topic and the SIP Profile - Advanced Settings object a user can configure these attributes/features. Once configured, the SIP Profile can be added to the SIP Signaling object, the External SIP Gateways object and External ENUM Server Sets object. The SIP 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 Profile object, there are also multiple objects that can be configured under the SIP Profile that add additional features/attributes.

Web GUI Page

Dialogic > IMG 2020 > Profiles > SIP Profiles > New SIP Profile

Open

Maximum Objects

Up to 16 SIP Profile objects can be created per Profiles object.

Related Topics and Dependencies

When creating the SIP Profile object, the first SIP profile created is a Default profile and the individual fields within this object cannot be modified. To create a SIP Profile that can be modified, right click on the SIP Profiles object again and select New SIP Profile. The second SIP Profile object created can now be modified.

SIP Profiles

Configure SIP Profile Options

Field Descriptions

Name

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

PRACK Support

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

Disabled (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 2020 to use PRACK transactions during call setup.

PRACK Timer (s)

If User Agent Server (IMG 2020) is not able to answer an INVITE immediately the IMG 2020 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- RFC 3261 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.

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

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

Precondition Support

The Precondition Support field is by default shaded green and cannot be modified. To be able to modify the Precondition Support field, the PRACK Support field must first be configured to either "Supported" or "Required". Once configured, the Precondition Support field can be modified. Precondition functionality is supported on the incoming leg of a call only. Refer to the Precondition and P-Early-Media Header Support topic for more information.

Disabled (Default)- Precondition support is disabled. If the Require or Supported Header in the incoming INVITE message contain the precondition option-tag, the option-tag will be discarded.

Required- Precondition support is enabled on a limited basis. Precondition was added to work in conjunction with feature F-6294 Precondition, P-Early-Media Support and is used for a specific application. Refer to the Precondition and P-Early-Media Header Support  topic for information on how Precondition is utilized for this application.

Relay- Precondition will be interworked with the remote leg.

Wait for fulfilled- IMG will wait for precondition fulfilled before initiating the remote leg. This mode will automatically set the Early 183 to "Enabled".

Precondition Loose Validation

This flag activates the loosening of the precondition validation for SIP UPDATE and SIP PRACK. Required and supported headers will not be validated.

Disabled (Default)- Precondition Loose Validation is disabled.

Enabled- Precondition Loose Validation is enabled.

Early 183

When Precondition Support field is set to "Relay" or "Wait for fulfilled", this parameter will indicate if IMG shall immediately send a 183 to start SDP negotiation for precondition on reception of INVITE.

CODEC Priority

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

Local- IMG 2020 takes priority when negotiating for CODEC.

Remote- Remote gateway takes priority when negotiating for CODEC.

Example: See table below.

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 IMG 2020 will try communicating with each of the contacts one at a time until the call is completed. IMG 2020 will send a maximum of 10 call attempts. The IMG 2020 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.

Disabled- Do Not send an 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.

Refer to SIP Redirect for more information.

Loop Detection

A loop is a situation where a request that arrives at the IMG 2020 is forwarded, and later arrives back at the same IMG 2020. 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 2020 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 2020 can be configured to employ a loop detection algorithm. This algorithm affects the way the IMG 2020 builds the via-branch field. When the IMG 2020 detects that the sent-by value in the Via header field matches a value placed in a previous request, the IMG 2020 would determine that it is in a loop situation. The SIP loop detection field allows the IMG 2020 to do one of three things when a loop is detected.

Enabled (Default)- If a loop is detected and the sent-by value in the via header are identical, the IMG 2020 is determined to be in a loop condition, the IMG 2020 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.

Disabled- The IMG 2020 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 2020 will determine this as a loop but will not reject the request if similar values are found.

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

Loop Detection 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.

INVITE Retransmission Attempts (UDP)

If there is no response to a SIP INVITE request then the INVITE is re-transmitted. This fields allows the IMG 2020 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.

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.

Privacy

SIP Privacy field configures whether there will be SIP Contact information offered in the SIP messaging. SIP Privacy is configured in Profiles objects in the Web GUI as described below.

• SIP Privacy is configured is under the Profiles object in the Web GUI. Set the Privacy Info field in the External Gateway object according to what is supported by the SIP Proxy to which the IMG 2020 is connected.

• To enable Privacy for an ISDN Group or an ISUP Group, set the Discard Privacy Info field in the ISDN Group page, SS7 - Destination - ISUP Group - ANSI or SS7 - Destination - ISUP Group - ITU pane to Yes.

Refer to SIP Privacy topic for more information.

INF0 Keep-Alive Support

Disabled (Default)

• When a SIP INFO message is received the IMG 2020 will respond as per RFC 3261.

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

• When a SIP INFO message is received, the dialog is valid, and configuration does not match, the IMG 2020 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 2020 will respond with a 200 OK message.

• When a SIP INFO message is received and the dialog is not found the IMG 2020 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 2020 will respond with a 200 OK.

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

Outbound Delayed Media

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

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

Refer to SIP Delayed Media Outbound topic for more information.

SRTP Mode

The SRTP Mode field configures how the IMG 2020 will react when receiving or transmitting a SIP INVITE that may or may not include any SRTP information in its SIP SDP. The functionality that is enabled differs depending on whether the INVITE message is on the incoming or outgoing leg of the IMG 2020. The information below is split up into INCOMING INVITE and OUTGOING INVITE to display the behavior on each leg.

INCOMING INVITE

Click on the SRTP Mode Flowchart - Incoming to view a flowchart of the table displayed above.

OUTGOING INVITE

Click on the SRTP Mode Flowchart - Outgoing to view a flowchart of the table displayed above.

180 Ringing Behavior

When the IMG 2020 receives a 180 Ringing message from the egress or B leg of a call, the user has a choice of whether to propagate and generate a 183 Session Progress message with SDP or propagate and generate a 180 Ringing message with ring tone but without SDP to the ingress or A leg of the call. Select from drop down menu below. For either selection below to function correctly, the SIP Profile must be associated with the External Gateway communicating with the egress or B leg of the call.

Send 183 Session Progress w/SDP (Default)- When selected from the drop down menu, if a 180 Ringing or 183 Session Progress with or without SDP is received on the egress or B leg of a call, a 183 Session Progress with SDP is generated and transmitted out the ingress or A leg of the call.

Refer to Call Trace - 183 Session Progress for more information.

Send 180 Ringing- When selected from the drop down menu, if a 180 Ringing or 183 with or without SDP is received on the egress or B leg of a call, a 180 Ringing without SDP along with ring tone will be generated and transmitted out the ingress or A leg of the call.

Refer to Call Trace - 180 Ringing for more information.

Ring Back Tone on 180 Ringing after183

When receiving a 180 Ringing after a 183, the IMG will generate a local ring back tone. 

Disabled (Default)- No local ring back tone is generated.

Enabled- IMG 2020 will force a local ring back tone.

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

Use Preferred Payload Size- If set to "Use Preferred Payload Size", the ptime value sent from the IMG 2020 in the SDP answer will be the Preferred Payload Size value for the selected codec in the IP Profile. This method allows the IMG 2020 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.

Force Digit Relay Setting For Answer

Disabled (Default)- If set to "Disabled", the IMG 2020 will abide by the DTMF setting the remote side sends in its SDP offer.

Enabled- If set to "Enabled", the IMG 2020 will ignore the DTMF setting in any incoming SDP offer and use the Digit Relay setting in the IP Profile for its own SDP answer and transmitted streams.

Allow SDP empty 'S' line

Disabled (Default)- if empty s-line (s=) is present, the call is rejected by IMG with 488.

Enabled- IMG 2020 will accept empty s-line (s=) in SDP and process the SIP message.