Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

IMG 1010 - Interworking from ISUP to SIP

Description:

The IMG supports SIP to ISUP and ISUP to SIP Interworking that complies with RFC 3398 (ANSI) and Q.1912.5 (03/2004) (ITU-T). The object below is used when configuring SS7 to SIP interworking. If configuring SIP to SS7 interworking, refer to the IMG 1010 - Interworking from SIP to ISUP topic. The SIP ISUP IW object configuration allows a customer to decide what message is sent upon receipt of the 183 Session Progress message if they don't want to follow the rules according to RFC 3398 or Q.1912.5 (03/2004) (ITU-T). Use the information below to decide which type of mapping/interworking will be applied.

Accessing this Pane

Dialogic IMG EMS > Routing Configuration > Channel Groups > Channel Group > ISUP Group > SIP ISUP IW

Maximum Objects:

One SIP ISUP object per ISUP Group object

ClientView Pane

(RFC 3398)

(Q.1912.5)

Call Flow Diagram

Field Descriptions (ANSI -  RFC 3398)

Use the Call Flow diagram above for reference when reading descriptions below.

183 ISUP Mapping Procedure and 183 Mapping Condition

The table below displays the scenarios for both RFC 3398 and Q.1912.5. The first two columns display the settings as displayed in ClientView. The 1st and 2nd response columns describe the response the IMG receives from SIP network and the Mapping of 18x to SIP messaging column displays how the IMG maps the first and second 18x responses into the SS7 network.

183 ISUP Mapping Procedure

183 Mapping Condition

1st response = 18x

2nd response = 183

Mapping of 18x to SIP messaging

 
 
Default (RFC 3398)

 
 
Default

180 Ringing

183 Session Progress

first 180 -> ACM

second 183 -> CPG

183 Session Progress

183 Session Progress

first 183 -> ACM

second 183 -> CPG

Default (RFC 3398)

183 is not interworked if ACM has been sent

180 Ringing

183 Session Progress

first 180 -> ACM

second  183 is NOT interworked to SS7 side

183 Session Progress

183 Session Progress

first 183 -> ACM

second  183 is NOT interworked to SS7 side

183 is not interworked if ACM has NOT been sent

183 Session Progress

Not Applicable

183 is NOT interworked

Default (RFC 3398)

183 is not interworked if ACM has been sent
 
-and-
 
183 is not interworked if ACM has NOT been sent

Don't Care

Don't Care

183 is not interworked. No ISUP messages are sent to SS7 side.

 

183 ISUP Mapping Procedure

183 Mapping Condition

1st response = 18x

2nd response = 183

SIP SIDE

Q.1912.5 procedure

Default (183 is not interworked)

Don't Care

Don't Care

183 is not interworked. No ISUP messages are sent to SS7 side.

Q.1912.5 procedure

183 to ACM (no indication) If ACM has NOT been sent

183 Session Progress

Not Applicable

183 -> ACM

180 Ringing

183 Session Progress

first 180 -> ACM

 

second 183 is NOT interworked to SS7 side

183 Session Progress

183 Session Progress

first 183 -> ACM

 

second 183 is NOT interworked to SS7 side

183 to CPG (progress) If ACM has been sent

180 Ringing

183 Session Progress

first 180 -> ACM

second 183 -> CPG

Q.1912.5 procedure

183 to ACM (no indication) If ACM has NOT been sent
 
-and-
 
183 to CPG (progress) If ACM has been sent

180 Ringing

183 Session Progress

first 180 -> ACM

second 183 -> CPG

183 Session Progress

183 Session Progress

first 183 -> ACM

second 183 -> CPG

Propagate Suspend/Resume

The settings below determine whether the IMG will send a re-invite message on SIP side when receiving a Suspend/Resume message from ISUP side.

False (Default) - If the IMG receives a SUSPEND or RESUME message on ISUP side, do not send re-invite message to SIP side.

True - If the IMG receives a SUSPEND or RESUME message, send a re-invite message to the SIP side

SIP On Hold

After receiving a Re-INVITE message from the SIP side, the IMG can put a call on hold by either sending a CPG message or a SUSPEND/RESUME message. Select from drop down menu which message to send to the SS7 side to put a call on hold and then resume the call. Refer to the IMG 1010 - SIP Call Hold topic for call flow information

CPG- After call is in an answered state, and after receiving a SIP Re-INVITE message with connection address equal to 0.0.0.0, the IMG will send a CPG with the notification indicator set to remote hold. When call is to resume, the remote SIP side sends a Re-INVITE with the connection address equal to a valid IP address. The IMG sends a CPG message with the notification indicator set to remote hold released to the remote SS7 ANSI side and the call is released.

SUS / RES- After call is in an answered state, and after receiving a SIP Re-INVITE message with the connection address equal to 0.0.0.0. The IMG will send a SUSPEND message to put Remote SS7 side on hold. When call is to resume, the remote SIP side sends a Re-INVITE with the connection address equal to a valid IP address. The IMG sends a RESUME message to the remote SS7 ANSI side and the call is released.

Remove Leading 0 in Redirecting Number

During the Interworking of the SIP Diversion Header to the SS7 Redirecting Number, the IMG can be configured to remove the leading zero from the interworked SS7 Redirecting Number. See below.

Disable (Default) - The leading zero character in the SIP Diversion Header will be interworked to the SS7 Redirecting Number.

Enable - The leading zero character in the SIP Diversion Header will be stripped and NOT interworked into the SS7 Redirecting Number.

Additional Information

  • This feature does not affect the logging of the SIP Diversion Header in RADIUS. The Diversion Header is logged in RADIUS with the leading zero regardless of the setting of the Remove Leading 0 in Redirecting Number field.

  • When there are multiple Diversion Headers in the SIP INVITE message, the leading zero will be stripped from only the top-most Diversion Header.

  • The Remove Leading 0 in Redirecting Number feature should be applied to the outgoing SS7 Channel Group only.

  • No labels