DO NOT SHARE THESE DOCS WITH CUSTOMERS!
This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.
In this section:
The SBC Core acts as SIP-I Back-to-Back User Agent (B2B UA) for packet-to-packet calls supporting SIP-I Embedded Integrated Service Digital Network User Part (ISUP) interworking which is explained in the following section. The SBC supports to populate the encapsulated ISUP calling party even when it is not mapped to P-Asserted-Identity in the INPUT DATA that is sent to the PSX.
SIP to SIP-I Interworking
The SBC supports the ability to take the tef-callref parameter received in the R-URI header of an INVITE message and convert it into the ISUP network call reference parameter with the parameter code 0xf4. The parameter is stored in the CDR and mapped into the SIP-I signaling on the egress side. The length of the added field is fixed at seven bytes (including type/length).
Example message:
INVITE sip:+457912345678;tgrp=garps;trunk-context=rfi.com;tef-callref=7AF0731E04@srsbc1sip.maqueta;user=phone SIP/2.0
SIP-I Embedded ISUP Interworking
The SBC supports interworking between standard versions and country variants of the ISUP MIME body embedded within SIP-I. The following main SIP-I variants are supported:
- ITU
- ANSI
- TTC
- ETSI
- UK ISUP. Scenario:
- ISUP (Country variant) — GSX9000 — GW-GW — SBC — SIP(I) — Peer switch
The SBC SIP-I implementation supports the ISUP base values defined in RFC 3204. All the other ISUP variants supported by Ribbon can be supported as Specific Content Type versions.
ISUP Super Generic Digits
The SBC supports processing Super Generic Digits (SGD) received in 'sgd' parameter of P-Sig-Info header of SIP INVITE message, and mapping them to Generic Digits parameter of Number Type 25 in SIP mime, and vice-versa. This applies to both SIP-SIP and GW-GW call flows.
The maximum length of SGD digits supported in P-Sig-Info header is 160 characters (0-9, a-f, A-F) which maps to 80 octets in SIP-I mime with a Binary encoding scheme, and vice-versa.
The PSX IPSP flag “Map SGD in P-Sig-Info Header” controls sending the “sgd” parameter in P-Sig-Info header in the outgoing SIP message. The CLI syntax to configure ISUP Signaling Profile to allow Super Generic Digits in the egress mime is shown below:
The interworking of SGD parameter and SIP P-Sig-Info header is not applicable when the SBC is configured for ERE mode.
% set profiles signaling isupSignalingProfile <profile name> allowSGDinGenericDigits <supported | unSupported>
Bit H of Backward Call Indicator
The SBC is configurable to allow the insertion of the BIT H parameter in the outgoing Address Complete Message (ACM) MIME of the 18x response using the ingress IP attributes flag, set-cut-through-indication-in-OBCI, for IP Signaling Profile attached to the ingress trunk group.
The ACM message sends Backward Call Indicators (BCI) to signal information about the call setup. Most of the fields contained in the Backward Call Indicators are the same as those in the Forward Call Indicators (FCI), which are contained in the IAM. While the FCI signals the call indicators in the forward direction to provide information on the call setup to the terminating access (and intermediate nodes), the BCI signals similar information in the backward direction to the originator.
Bit H of the Backward Call Indicator (in ANSI) allows a network node to temporarily halt call set-up and play tones or announcements, or both, and collect additional in-band information from the calling user before routing the call further.
Example:
% set profiles signaling ipSignalingProfile MyProfile ingressIpAttributes flags set-cut-through-indication-in-OBCI enable
ISUP Mime Enhancements
The SBC Core SIP Message Manipulation (SMM) allows for direct manipulation of the ISUP parameters within the ISUP MIME message body of a SIP message. Currently, this enhancement applies to Japan and ITU ISUP variants.
These rules are only intended to be used by someone who is familiar with the ISUP message/parameter formats. If in doubt on how to write the syntax for a specific operation, please contact Ribbon Support for more assistance.
Three different ISUP parameter formatting types exist as depicted in the table below.
Table 1: ISUP Parameter Formatting Types
| ISUP Formatting Type | Description | Example |
|---|---|---|
| Mandatory fixed | This type has a fixed size. It must be present in the message, and can only appear once in the message. | Nature of connection parameter in IAM |
| Mandatory variable | This type has a variable size. It must be present in the message, and can only appear once in the message. | Called party number in IAM |
| Optional | This type can be of a fixed or variable size, and can appear one or more times in the message. |
Three different ISUP parameters types exist within the SMM rules as described in the table below:
Table 2: ISUP Parameter Types Within SMM Rules
| ISUP Parameter Type Within SMM Rules | Description | Examples |
|---|---|---|
| Single instance | Parameters that can only appear once in an ISUP message. These are identified by a parameter code. | called party number |
| Repeatable parameters | Parameters that can appear in an ISUP message multiple times. Each of these parameters contains a parameter field (subtype) to identify a specific instance of the parameter. These are identified by a parameter code and parameter sub type. | generic digits = type of digits generic number = number qualifier generic notification = notification indicator |
| Embedded parameters | The access transport parameter can contain a list of other parameters. These are identified by a parameter code and embedded ISUP parameter code. | called / calling sub-address information |
SMM Operations/Actions
The SMM provides the capabilities to perform the following operations:
Table 3: SMM Operations/Actions
| Operation | Description |
|---|---|
| Exists | This operation allows for the operator to check whether a parameter is present based on message code, parameter code, subtype or embedded parameter code. It is also possible to provide a pattern of bytes to match on the parameter, the length of the pattern needs to be less than or equal to the length of the parameter in the message. The parameter code is mandatory in this operation. |
| Add | This operation allows for a parameter to be added into the message, in this case the parameter or embedded parameter needs to be created in an SMM variable. In the case of embedded parameters if the access transport parameter does not already exist within the message then it is automatically created in order to populate the embedded parameter. |
| Add digits | This operation only applies to parameters calling party number, called party number, called IN number, location number, redirection number, original called number, redirecting number, connected number of generic number. This operation can be used to either add or replace the digits within these parameters. The operator needs to create a variable containing the ASCII string of characters; this can either be hardcoded or populated based on the contents of a SIP header, e.g. R-URI. As part of this operation, the ASCII string of digits are converted into Binary Coded Decimal (BCD) format so the odd/even indicator field within the ISUP parameter is set correctly. If the parameter already contains digits, they are replaced with the new information. These parameters can be created in two step:
If the addDigits operation is attempted and the associated parameter does not already exist in the message then it will fail. If the ASCII string contains a + then this will be dropped as part of the conversion as there is no mapping into the ISUP parameter. |
| Delete | This operation allows for a parameter to be deleted based on the message code, parameter code, subtype or embedded parameter code. It is also possible to provide a pattern of bytes to match on the parameter, the length of the pattern needs to be less than or equal to the length of the parameter in the message. The parameter code is mandatory in this operation. In the case of embedded parameters within the access transport, when the last embedded sub parameter within the access transport is deleted then the access transport parameter is also deleted from the message. Only optional parameters can be deleted. |
| Get Digits | This operation only applies to parameters calling party number, called party number, called IN number, location number, redirection number, original called number, redirecting number, and connected number of generic number. The operation is used to convert ISUP BCD format to regular number format (i.e., can be used to retrieve the digits in ASCII string format for the specified parameter to a variable). |
| Modify | This operation allows the contents of an existing parameter to be swapped with new information. The operator needs to read the whole parameter into an SMM variable they can then edit the contents of the variable using bitwise operators e.g. AND, OR to update the contents of the specific bits in the specific bytes of the ISUP parameter. The updated parameter contents can then be swapped into the ISUP message again. |
Clicking on an operation in the above table which includes a hyperlink takes you to an example later in this section.
| Legend |
|---|
bitOR – Bitwise OR operation bitAND – Bitwise AND operation bitXOR – Bitwise eXclusive OR operation bitNOT – Bitwise NOT operation that is, inverts the bit from its current value. binaryToAsciiStore – This operation converts hexadecimal binary data into the equivalent ASCII string for example, the number "0x12, 0x34" into the string “1234”. binaryToAsciiAppend – This operation converts hexadecimal binary data into the equivalent ASCII string for example, the number "0x12, 0x34" into the string “1234” and appends it to the end of an existing ASCII variable. asciiToBinaryStore – This operation converts an ASCII string of hexadecimal digits into an array of hexadecimal binary bytes for example, “1234” is converted to "0x12, 0x34". asciiToBinaryAppend – This operation converts an ASCII string of hexadecimal digits into an array of hexadecimal binary bytes and appends them to an existing binary variable. |
Parameter Descriptions
Parameter | Possible Completion/ Range | Default Value | Description |
|---|---|---|---|
| isupMessageType | 00-ff | 00 | Hex value representing 16-bit ISUP message code. For example, 0x01 for Initial Address Message (IAM), 0x02 for Subsequent Address Message (SAM), and 0x06 for Address Complete (ACM). |
| paramCode | 00-ff | 00 | Primary parameter hex code of ISUP parameter. |
| paramSubType | 00-ff | ff | Secondary parameter hex code of repeatable ISUP parameter. |
| paramEmbeddedCode | 00-ff | 00 | Secondary parameter hex code of embedded ISUP parameter. |
| length | all/1-255 | all | The number of bytes from selected offset byte for binary manipulation. |
| offset | whole/0-254 | whole | The position of first byte for binary manipulation. |
Example ISUP MIME Capabilities
Example ISUP MIME capabilities, based on the syntax above, including the SMM rules to facilitate them, are provided in this section. For each example, the ISUP MIME data is shown before and after the rules are applied.
Change the value of the end to end information element in the FCI parameter
#check if isup message exist set profiles signaling sipAdaptorProfile fci rule 1 criterion 1 type message message methodType invite messageTypes request set profiles signaling sipAdaptorProfile fci rule 1 criterion 2 type messageBody messageBody messageBodyType isup isupMessageType 01 condition exist #save fci param set profiles signaling sipAdaptorProfile fci rule 1 action 1 type isupParameter operation store set profiles signaling sipAdaptorProfile fci rule 1 action 1 type isupParameter from type isupParameter paramCode 07 set profiles signaling sipAdaptorProfile fci rule 1 action 1 to type variable variableValue var1 #create the bitmask set profiles signaling sipAdaptorProfile fci rule 1 action 2 type variable operation asciiToBinaryStore set profiles signaling sipAdaptorProfile fci rule 1 action 2 from type value value "10" set profiles signaling sipAdaptorProfile fci rule 1 action 2 to type variable variableValue var2 #enable end-to-end bit set profiles signaling sipAdaptorProfile fci rule 1 action 3 type variable operation bitOR set profiles signaling sipAdaptorProfile fci rule 1 action 3 from type variable variableValue var2 offset 0 set profiles signaling sipAdaptorProfile fci rule 1 action 3 to type variable variableValue var1 offset 0 #update the fci set profiles signaling sipAdaptorProfile fci rule 1 action 4 type isupParameter set profiles signaling sipAdaptorProfile fci rule 1 action 4 from type variable variableValue var1 set profiles signaling sipAdaptorProfile fci rule 1 action 4 to type isupParameter paramCode 07 set profiles signaling sipAdaptorProfile fci rule 1 action 4 operation modify
ISUP-Before-SMM: 01 10 60 00 0a 03 02 05 03 03 90 f1 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 00 ISUP-After-SMM: 01 10 70 00 0a 03 02 05 03 03 90 f1 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 00
Create the network call reference parameter based on the contents of tef-callref parameter in SIP header
#check if tef-callref and isup present in the request set profiles signaling sipAdaptorProfile callref rule 1 criterion 1 type message message methodType invite messageTypes request set profiles signaling sipAdaptorProfile callref rule 1 criterion 2 type header header condition exist name "request-line" set profiles signaling sipAdaptorProfile callref rule 1 criterion 3 type parameter parameter paramType userinfo name "tef-callref" condition exist set profiles signaling sipAdaptorProfile callref rule 1 criterion 4 type messageBody messageBody messageBodyType isup condition exist set profiles signaling sipAdaptorProfile callref rule 1 criterion 4 type messageBody messageBody messageBodyType isup isupMessageType 01 #store the tef-callref parameter in to variable var1 set profiles signaling sipAdaptorProfile callref rule 1 action 1 type parameter set profiles signaling sipAdaptorProfile callref rule 1 action 1 paramType userinfo set profiles signaling sipAdaptorProfile callref rule 1 action 1 operation store set profiles signaling sipAdaptorProfile callref rule 1 action 1 from type parameter value "tef-callref" set profiles signaling sipAdaptorProfile callref rule 1 action 1 to type variable variableValue var1 #convert value to binary and store into variable var2 set profiles signaling sipAdaptorProfile callref rule 1 action 2 type variable operation asciiToBinaryStore set profiles signaling sipAdaptorProfile callref rule 1 action 2 from type variable variableValue var1 set profiles signaling sipAdaptorProfile callref rule 1 action 2 to type variable variableValue var2 #now reshuffle. so use regular store/append #store var2[2] -> var3[0] set profiles signaling sipAdaptorProfile callref rule 1 action 3 type variable operation store set profiles signaling sipAdaptorProfile callref rule 1 action 3 from type variable variableValue var2 offset 2 length 1 set profiles signaling sipAdaptorProfile callref rule 1 action 3 to type variable variableValue var3 #store var2[1] -> var3[1] set profiles signaling sipAdaptorProfile callref rule 1 action 4 type variable operation append set profiles signaling sipAdaptorProfile callref rule 1 action 4 from type variable variableValue var2 offset 1 length 1 set profiles signaling sipAdaptorProfile callref rule 1 action 4 to type variable variableValue var3 set profiles signaling sipAdaptorProfile callref rule 1 action 5 type variable operation append set profiles signaling sipAdaptorProfile callref rule 1 action 5 from type variable variableValue var2 offset 0 length 1 set profiles signaling sipAdaptorProfile callref rule 1 action 5 to type variable variableValue var3 set profiles signaling sipAdaptorProfile callref rule 1 action 6 type variable operation append set profiles signaling sipAdaptorProfile callref rule 1 action 6 from type variable variableValue var2 offset 4 length 1 set profiles signaling sipAdaptorProfile callref rule 1 action 6 to type variable variableValue var3 set profiles signaling sipAdaptorProfile callref rule 1 action 7 type variable operation append set profiles signaling sipAdaptorProfile callref rule 1 action 7 from type variable variableValue var2 offset 3 length 1 set profiles signaling sipAdaptorProfile callref rule 1 action 7 to type variable variableValue var3 #add to isup set profiles signaling sipAdaptorProfile callref rule 1 action 8 type isupParameter from type variable variableValue var3 set profiles signaling sipAdaptorProfile callref rule 1 action 8 to type isupParameter paramCode F4 set profiles signaling sipAdaptorProfile callref rule 1 action 8 operation add
ISUP-Before-SMM: 01 10 60 00 0a 03 02 05 03 03 90 f1 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 00 ISUP-After-SMM: 01 10 60 00 0a 03 02 05 03 03 90 f1 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 f4 05 73 f0 7a 04 1e 00
Delete the parameter with parameter code F3 from the message
#check if parameter f3 present set profiles signaling sipAdaptorProfile deleteparam rule 1 criterion 1 type message message methodType invite messageTypes request set profiles signaling sipAdaptorProfile deleteparam rule 1 criterion 2 type messageBody messageBody messageBodyType isup isupMessageType 01 condition exist set profiles signaling sipAdaptorProfile deleteparam rule 1 criterion 3 type isupParameter isupParameter paramCode f3 condition exist #delete parameter set profiles signaling sipAdaptorProfile deleteparam rule 1 action 1 type isupParameter operation delete set profiles signaling sipAdaptorProfile deleteparam rule 1 action 1 type isupParameter to type isupParameter paramCode f3
ISUP-Before-SMM: 01 10 60 00 0a 03 02 05 03 03 90 f1 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 f3 05 73 f0 7a 04 1e 00 ISUP-After-SMM: 01 10 60 00 0a 03 02 05 03 03 90 f1 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 00
Update the called party address digits based on the contents of SIP header
#check the message set profiles signaling sipAdaptorProfile modifyCalled rule 1 criterion 1 type message message methodType invite messageTypes request set profiles signaling sipAdaptorProfile modifyCalled rule 1 criterion 2 type header header condition exist name "request-line" set profiles signaling sipAdaptorProfile modifyCalled rule 1 criterion 3 type messageBody messageBody messageBodyType isup condition exist set profiles signaling sipAdaptorProfile modifyCalled rule 1 criterion 3 type messageBody messageBody messageBodyType isup isupMessageType 01 set profiles signaling sipAdaptorProfile modifyCalled rule 1 criterion 4 type isupParameter isupParameter paramCode 04 condition exist
#save called digit into var1 set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 1 type token operation store set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 1 from type token tokenValue uriusername set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 1 to type variable variableValue var1 #create fixed part in called party parameter set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 2 type variable operation asciiToBinaryStore set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 2 from type value value "0390" set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 2 to type variable variableValue var2 #modify the ISUP param set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 3 type isupParameter from type variable variableValue var2 set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 3 to type isupParameter paramCode 04 set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 3 operation modify #add digits to ISUP param set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 4 type isupParameter from type variable variableValue var1 set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 4 to type isupParameter paramCode 04 set profiles signaling sipAdaptorProfile modifyCalled rule 1 action 4 operation addDigits
ISUP-Before-SMM: 01 10 60 00 0a 03 02 05 03 03 90 f1 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 f3 05 73 f0 7a 04 1e 00 ISUP-After-SMM: 01 10 60 00 0a 03 02 0a 08 83 90 37 42 41 44 05 01 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 f3 05 73 f0 7a 04 1e 00
Associate the Adaptor Profile to SIP Trunk Group
set profiles signaling sipAdaptorProfile <sipAdaptorProfile name> state enabled delete addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> signaling messageManipulation outputAdapterProfile set addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> signaling messageManipulation outputAdapterProfile <sipAdaptorProfile name>
Get the Digits From ISUP Parameter and Add Them to "Called-Party-Number" Header
In this example, SMM obtains the digits from ISUP parameter with code 0x04 (73241444501) and adds them to "Called-Party-Number" header.
set profiles signaling sipAdaptorProfile getDigits rule 1 criterion 1 type message message methodType invite messageTypes request set profiles signaling sipAdaptorProfile getDigits rule 1 criterion 2 type header header condition exist name "request-line" set profiles signaling sipAdaptorProfile getDigits rule 1 criterion 3 type messageBody messageBody messageBodyType isup condition exist set profiles signaling sipAdaptorProfile getDigits rule 1 criterion 3 type messageBody messageBody messageBodyType isup isupMessageType 01 set profiles signaling sipAdaptorProfile getDigits rule 1 criterion 4 type isupParameter isupParameter paramCode 04 condition exist set profiles signaling sipAdaptorProfile getDigits rule 1 action 1 type isupParameter to type variable variableValue var1 set profiles signaling sipAdaptorProfile getDigits rule 1 action 1 from type isupParameter paramCode 04 set profiles signaling sipAdaptorProfile getDigits rule 1 action 1 operation getDigits #add to sip set profiles signaling sipAdaptorProfile getDigits rule 1 action 2 type header operation add set profiles signaling sipAdaptorProfile getDigits rule 1 action 2 from type variable variableValue var1 set profiles signaling sipAdaptorProfile getDigits rule 1 action 2 to type header value "Called-Party-Number" set profiles signaling sipAdaptorProfile getDigits rule 1 action 2 headerPosition last
PDU:
INVITE sip:73241444501;tef-callref=7AF0731E04@10.7.16.120:5060 SIP/2.0 Via: SIP/2.0/UDP 10.7.6.40:12127;branch=z9hG4bK0dB0002147a6a9d1186 From: <sip:73241444501@10.7.16.118:5060>;xxx=rrr;ddd;pstm=rrrr To: <sip:73241444501@10.7.16.118:5060> Call-ID: _call_test_cadse_80 CSeq: 10 INVITE Allow: UPDATE,OPTIONS, INVITE, CANCEL, ACK, BYE Contact: <sip:73241444501@10.7.6.40:12127> Accept: application/sdp Session-Expires: 190; refresher=uac P-Preferred-Identity: Sonus Networks <sip:9803456789@10.34.10.82:7056> P-Asserted-Identity: <sip:12345@10.34.10.82:7056> P-Sig-Info: uui=0001020304 X-AUT: fd01fc06 Privacy: id Content-Type: multipart/mixed;boundary=sonus-content-delim MIME-Version: 1.0 l: 456 --sonus-content-delim Content-Disposition: session; handling = required Content-Type: application/sdp v=0 o=GBL-calling 5129 10 IN IP4 xxx.com s=jay c=IN IP4 10.7.6.40 t=0 0 m=audio 90 RTP/AVP 0 90 a=rtpmap:0 PCMU/8000 a=rtpmap:90 CLEARMODE/8000 --sonus-content-delim Content-Disposition: signal; handling = required Content-Type: application/isup; version=itu-t92+; base=itu-t92+ <ISUP part: 01 10 60 00 0a 03 02 0a 08 83 90 37 42 41 44 05 01 0a 07 03 13 07 89 70 52 86 1d 03 90 90 a3 31 02 00 18 c0 08 06 03 13 07 89 70 52 86 39 04 31 90 c0 84 f3 05 73 f0 7a 04 1e 00>
--sonus-content-delim--
ISUP MESSAGE = [ IAM ]
Nature of Connection Indicators - Parameter Code [0x06]
- - - - - - 0 0 0x0 | Satellite indicator 0x0 - No Satellite Circuit
- - - - 0 0 - - 0x0 | Continuity Check Indicator 0x0 - Continuity Check Not Required
- - - 1 - - - - 0x1 | Echo Control Device Indicator 0x1 - Outgoing Echo Control Device Included
0 0 0 - - - - - 0x0 | Spare
Forward Call Indicators - Parameter Code [0x07]
- - - - - - - 0 0x0 | National/International CallIndicator 0x0 - Call Treated As National Call
- - - - - 0 0 - 0x0 | End To End Method Indicator 0x0 - No End To End Method Available
- - - - 0 - - - 0x0 | Interworking Indicator 0x0 - No Interworking Encountered
- - - 0 - - - - 0x0 | End To End Information Indicator 0x0 - No end-to-end information available
- - 1 - - - - - 0x1 | ISUP Indicator 0x1 - ISUP Used All The Way
0 1 - - - - - - 0x1 | ISUP Preference Indicator 0x1 - ISUP Not Required All The Way
- - - - - - - 0 0x0 | ISDN Access Indicator 0x0 - Originating Access Non ISDN
- - - - - 0 0 - 0x0 | SCCP Method Indicator 0x0 - No indication
- - - - 0 - - - 0x0 | Spare
0 0 0 0 - - - - 0x0 | Reserved For National Use
Calling Party's Category - Parameter Code [0x09]
0 0 0 0 1 0 1 0 0xA | Calling party's Category 0xA - Ordinary Calling Subscriber
Transmission Medium requirement - Parameter Code [0x02]
0 0 0 0 0 0 1 1 0x3 | Transmission Medium Requirement 0x3 - 3.1 kHZ Radio
Called Party Number - Parameter Code [0x04]
- 0 0 0 0 0 1 1 0x3 | Nature Of Address 0x3 - Subscriber National
1 - - - - - - - 0x1 | Odd/Even Indicator 0x1 - Odd Number Of Address Signals
- - - - x x x x Spare
- 0 0 1 - - - - 0x1 | Numbering Plan Indicator 0x1 - ISDN Numbering Plan
1 - - - - - - - 0x1 | Internal Network number Indicator 0x1 - Routing To Internal Network Number Not Allowed
Address Signals [ 73241444501 ]
Calling Party Number - Parameter Code [0x0A]
0 0 0 0 1 0 1 0 0xA | Calling Party Number Type
- 0 0 0 0 0 1 1 0x3 | Nature Of Address 0x3 - Unique National
0 - - - - - - - 0x0 | Odd/Even Indicator 0x0 - Even Number Of Address Signals
- - - - - - 1 1 0x3 | Screening Indicator 0x3 - Network Provided
- - - - 0 0 - - 0x0 | Address Presentation Restriced Indicator 0x0 - Presentation Allowed
- 0 0 1 - - - - 0x1 | Numbering Plan Indicator 0x1 - ISDN Numbering Plan
0 - - - - - - - 0x0 | Number Incomplete Indicator 0x0 - Complete
Address Signals [ 7098072568 ]
User Service Information - Parameter Code [0x1D]
- - - 1 0 0 0 0 0x10| Information Transfer Capability 0x10 - 3.1KHZ Audio
- 0 0 - - - - - 0x0 | Coding Standard 0x0 - ITU-T Standardized Coding
x - - - - - - - Extension
- - - 1 0 0 0 0 0x10| Information Transfer Rate 0x10 - 64 Kbits
- 0 0 - - - - - 0x0 | Transfer Mode 0x0 - Transfer Mode Circuit
x - - - - - - - Extension
0 0 0 0 0 0 1 1 0x3 | User Info Layer 1 0x3 - ALAW Speech
Propagation Delay Counter - Parameter Code [0x31]
0 0 0 0 0 0 1 0 0x2 | Propogation Delay Counter Length
Propogation Delay Value
0 0 0 0 0 0 0 0 0x0 |
0 0 0 1 1 0 0 0 0x18|
Generic Address - Parameter Code [0xC0]
0 0 0 0 0 1 1 0 0x6 | Number Qualifier Indicator 0x6 - Additional Calling Party Number
- 0 0 0 0 0 1 1 0x3 | Nature Of Address 0x3 - Subscriber National
0 - - - - - - - 0x0 | Odd/Even Indicator 0x0 - Even Number Of Address Signals
- - - - - - 1 1 0x3 | Screening Indicator 0x3 - Network Provided
- - - - 0 0 - - 0x0 | Address Presentation Restriced Indicator 0x0 - Presentation Allowed
- 0 0 1 - - - - 0x1 | Numbering Plan Indicator 0x1 - ISDN Numbering Plan
0 - - - - - - - 0x0 | Number Incomplete Indicator 0x0 - Complete
Address Signals [ 7098072568 ]
Unrecognised Parameter
1 1 1 1 0 0 1 1 0xF3| Unrecognized Parameter Code
0 0 0 0 0 1 0 1 0x5 | Unrecognized Parameter Length
Unrecognized Parameter Data
0 1 1 1 0 0 1 1 0x73|
1 1 1 1 0 0 0 0 0xF0|
0 1 1 1 1 0 1 0 0x7A|
0 0 0 0 0 1 0 0 0x4 |
0 0 0 1 1 1 1 0 0x1E|
Parameter Compatibility Ind - Parameter Code [0x39]
0 0 0 0 0 1 0 0 0x4 | Parameter Compatibility Length
Parameter Compatibility Info
0 0 1 1 0 0 0 1 0x31| Upgraded Parameter
Instruction Indicators 1
- - - - - - - 0 0x0 | Transit At Intermediate Exch Ind 0x0 - transit interpretation
- - - - - - 0 - 0x0 | Release Call Indicator 0x0 - do not release call
- - - - - 0 - - 0x0 | Send Notification Indicator 0x0 - do not send notification
- - - - 0 - - - 0x0 | Discard Message Indicator 0x0 - do not discard message(pass on)
- - - 1 - - - - 0x1 | Discard Parameter Indicator 0x1 - discard parameter
- 0 0 - - - - - 0x0 | Pass On Not Possible Indicator 0x0 - release call
1 - - - - - - - 0x1 | Extension
1 1 0 0 0 0 0 0 0xC0| Upgraded Parameter
Instruction Indicators 1
- - - - - - - 0 0x0 | Transit At Intermediate Exch Ind 0x0 - transit interpretation
- - - - - - 0 - 0x0 | Release Call Indicator 0x0 - do not release call
- - - - - 1 - - 0x1 | Send Notification Indicator 0x1 - send notification
- - - - 0 - - - 0x0 | Discard Message Indicator 0x0 - do not discard message(pass on)
- - - 0 - - - - 0x0 | Discard Parameter Indicator 0x0 - do not discard parameter(pass on)
- 0 0 - - - - - 0x0 | Pass On Not Possible Indicator 0x0 - release call
1 - - - - - - - 0x1 | Extension
==================================================================================
SONUS ITU LOGFILE DECODE END
==================================================================================
Mapping From Header to ISUP GAP Parameter
The SBC supports mapping the From header to ISUP Generic Address Parameter (GAP) using the SIP Trunk Group Calling Party flag Map From Header To ISUP GAP. The following scenarios are supported: The SBC maps the From header to ISUP under the following conditions: The SBC generates the GAP parameters only if the parameter, The SBC adds or modifies the GAP parameter in the ISUP message if it receives a SIP or SIP-I INVITE request under the following conditions:
Note
mapFromHeaderToIsupGap is enabled. The parameter mapFromHeaderToIsupGap takes precedence over the other flags while generating the GAP parameters.mapFromHeaderToIsupGap is enabled.
Figure 1: Call Flow - Mapping From Header to ISUP GAP Parameter
Mapping ISUP Calling Party Number to SIP From and PAI Headers
The SBC supports mapping the ISUP Calling Party Number to SIP From and PAI headers using the SIP Trunk Group Calling Party flag Map ISUP Cgpn To PAI. The SBC sends the ISUP calling party to the PSX in the policy request and uses the PSX returned Calling Party Number to create the PAI Header and process it to the Egress side. It sends the PRIVACY header on the egress side using the presentation indicator. The SBC supports only the following scenarios: The SBC maps the ISUP Calling Party Number to SIP From and PAI headers under the following conditions: The SIP PAI/PPI/RPID headers are not received. The ISUP MIME contains the Calling Party Number. The SIP variant used on Ingress side is either When the SBC receives the privacy information as "restricted", the PSX omits the The SBC sends the Calling Party Number in the ISUP, if it receives SIP-I INVITE under the following conditions:mapIsupCgpnToPAI is enabled on the ingress side.sonus or Q1912.
Note
Calling Party Number in the output data. To include the Calling Party Number, enable the PSX parameter: Don't Strip Calling Number For Restricted Presentation.mapIsupCgpnToPAI is enabled.
Figure 2: Call Flow - Mapping ISUP Calling Party Number to SIP From and PAI Headers
Charge Rate Information in J-ISUP to Non-Japanese ISUP Call Scenario
For call scenarios where the ingress leg is a J-ISUP variant and the egress leg is a non-Japanese ISUP variant, the SBC can be configured to retrieve charge rate information (CRI) from the PSX Charge Rate Profile table, rather than the Charge Rate Information Parameter table, when certain specific conditions are met. This enables use of different charge information for a call that involve payphones.
By default when setting up a J-ISUP variant to non-Japanese ISUP variant call, CRI is returned from the PSX Charge Rate Information Parameter table in the first backward Address Complete Message (ACM), Call Progress (CPG), or Charging Information (CHG) message during call setup. However you can enable the chargeRateInfoForCpcApc option in the ingress ISUP Signaling Profile to have the SBC check whether the call has specific characteristics required to trigger using values from the Charge Rate Profile table instead.
If the chargeRateInfoForCpcApc option is set to supported, the SBC checks for the following mandatory conditions:
- The ingress leg of the call must be a J-ISUP variant
- The egress leg of the call must be a non-Japanese ISUP variant
- The call request must include one of the following:
- The CPC (Calling Party's Category) in the incoming INVITE/IAM message has the value "pay phone"
- The APC (Additional Party Category) in the incoming INVITE/IAM message has the value "Pink" (00000010) or "train pay phone"(00000001).
If the call meets the above conditions, the SBC returns CRI taken from the PSX Charge Rate Profile table specified in the PSX Charge Band Profile associated with the ingress trunk group. The CRI is returned in the first backward ACM, CPG, or CHG message.
If the option is set to supported but the conditions are not met or Charge Rate Profile table data is not available, no charge information is returned in the ACM, CPG, or CHG messages.
When the option is set to the default value of unsupported, the SBC maintains its behavior of sending CRI values from the PSX Charge Rate Information Parameter table in the first backward ACM, CPG, or CHG message.
Note
The chargeRateInfoForCpcApc option is only configurable on Japan-based ISUP Signaling Profiles in which the revision value specifies either the nttfcc or nttcom ISUP variant.
The following table shows how Charge Rate Profile data is mapped to ACM / CPG charge information fields:
| ACM/CPG charge information field | PSX Charge Rate Profile field |
|---|---|
| Charge Information Type | Hardcoded value for "Charge Rate Transfer" |
| Charge Information - Unit Rate Indicator | Currency Scale/Currency Type fields |
| Charge Rate Information Category | Hardcoded value for "Flexible Charging Rate Indication (Payphone)" |
| Charge Information - Initial Lump Rate | Call Attempt Charge field |
| Charge Information - First Charging Period | Subtarriff1 Duration field |
| Charge Information - Second Charging Period | Subtarriff2 Duration field |
| Charge Information - Third Charging Period | Subtarriff3 Duration field |
| Charge Information - Fourth Charging Period | Subtarriff4 Duration field |
In a GW-GW scenario, the SBC SWe and Cloud platforms does not support this feature.
For parameter configuration, refer to:
Overview
Content Tools