Ptc331 Form B (additional Isup Questionnaire)

Transcript

PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 PTC331 Form B Additional ISUP Compatibility Questionnaire Introduction Please answer the following questions by completing this form and returning it to Spark. To complete the PDF version of this form click the icon in the toolbar, select “T” (Add Text Comment) in the right hand “Comment” pane and type the changes into the form. Alternatively an MS WORD version can be supplied on request. Save the completed form under a new name and supply a copy to Spark. Before answering the questions shown in Form B, please refer to the end of this Form for explanations pertaining to each question. The explanations are numbered using the same numbers as the questions. If, for any reason, you are having difficulty completing this form, please contact your Spark account manager as soon as possible. Please note that in this form, your network is referred to as the “Other Network”. Form B I certify that the information given in Form B is accurate and complete and is consistent with applicable agreement/documents. I also understand that any errors or omission found on this form at a later stage could lead to re-scoping of the test schedule and/or re-configuration of the test environment and/or alteration of an applicable agreement or document. This as a result could directly or indirectly bring on additional costs and/or delays to the PTC331 compliance and testing process. Name of company seeking interconnection based on PTC331 conformance ..................................................... Name of person responsible for submitting this form ...... Name of contact person for arranging testing (if different from the above)................................................................ Contact’s phone number ................................................. Contact ‘s e-mail.............................................................. The associated FORM A Questionnaire for this compliance request....................... Date: Has already been submitted to Spark Is being submitted together with this FORM B ........... / ........... / ........... (day/month/year) Thank you for taking the time to complete this form. Page 1 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 PTC331 Form B Additional Information Required For PTC331 No.7 Signalling (MTP + ISUP) Network Interconnect Testing for the purpose of interconnecting with the Spark PSTN/ISDN BASIC CALL CONTROL QUESTIONS Item & Description Description 1 2 3 4 1 2 3 (a) Non-ISDN originated 3.1 kHz audio No interworking (SS7; ISUP) Actions taken by Other Network for the Call Directions Shown Call Direction: SparkOther Network 1 Call answered successfully (b) Non-ISDN originated 3.1 kHz audio Interworking encountered (Not-SS7; Not-ISUP) ISDN originated speech No interworking (SS7; ISUP) ISDN originated 3.1 kHz audio No interworking (SS7; ISUP) Call answered successfully ISDN originated 64 kbit/s unrestricted digital data No interworking (SS7; ISUP) Call answered successfully Call released (Cause = 88) Call released (Cause = 65) Call answered successfully Call answered successfully Call Direction: Call Dir: SparkOther NetworkSpark 3 2 Other NetworkSpark The following calls can be generated: FCI & TMR passed unchanged Non-ISDN 3.1 kHz SS7 ISUP USI Mapped to Non-ISDN 3.1 kHz Not-SS7 Not-ISUP USI Non-ISDN 3.1 kHz Not-SS7 Not-ISUP USI Non-ISDN call not generated Non-ISDN 3.1 kHz Not-SS7 Not-ISUP USI Sent as Non-ISDN 3.1 kHz Not-SS7 Not-ISUP USI Non-ISDN call with Interworking not generated Non-ISDN call not generated The following calls can be generated: ISDN Speech SS7 ISUP USI ISDN Speech call not generated The following calls can be generated: ISDN 3.1 kHz audio ISUP Non-ISDN 3.1 kHz audio Not-SS7 Not-ISUP USI ISDN 3.1 kHz call not generated The following calls can be generated: ISDN 64k UDI ISUP 64k UDI call not generated Fill in this column if your answer to Form A, Question 6(b) was “Yes”. Fill in this column if your answer to Form A, Question 6(a) was “Yes”. Fill in this column if your answer to Form A, Question 6(f) was “Yes”. Page 2 FCI, TMR & USI passed unchanged Mapped to Non-ISDN 3.1 kHz Not-SS7 Not-ISUP USI FCI, TMR & USI passed unchanged Mapped to Non-ISDN 3.1 kHz Not-SS7 Not-ISUP USI FCI, TMR & USI passed transparently Call Released (Cause = 88) Call Released (Cause = 65) PTC331 Form B (Additional ISUP Questionnaire) Description 5 6 7 4 (a) User service information (USI) parameter for ISDN originated speech and 3.1 kHz audio calls Call Direction: SparkOther Network 1 Call answered successfully (USI and USI calls can both be received from Spark) February 1, 2015 Call Direction: Call Dir: SparkOther NetworkSpark 3 2 Other NetworkSpark USI sent for all ISDN Speech and 3.1kHz audio USI passed transparently calls. USI discarded; Speech/3.1kHz audio call No USI sent for all non-ISDN calls mapped to Non-ISDN 3.1 kHz audio Not-SS7 Not-ISUP (b) USI for 64kbit/s data calls Call answered successfully (USI can be received from Spark) Call released (cause 88) TMR=64 kb/s and USI=“64k UDI” sent for all ISDN 64k UDI calls TMR=64 kb/s and USI=“64k UDI, V.110, User Rate=56 kb/s” sent for all ISDN 64k UDI calls that interwork with 56 kbit/s networks TMR=64 kb/s calls not sent Bit A=“National” sent for all calls (a) FCI Bit A: National/International Indicator Call answered successfully (Bit A=“National” and Bit A=“International” can both be received from Spark) (b) FCI Bit I: Orig Access Call answered successfully (Bit I = Orig ISDN or Orig Non-ISDN can be received from Spark) Orig Non-ISDN sent for all non-ISDN calls Orig ISDN sent for all ISDN calls (c) FCI Bits HG Call answered successfully (Bits HG = “ISUP Not Required”, “ISUP Preferred” or “ISUP Required” can be received from Spark) “ISUP Required” call is released (as Other Network does not support ISUP all the way to the destination exchange) (a) Calling party number: Nature of Address (NOA) and Address Digits Call answered successfully (NOA=“National” & “International” can be received from Spark) Bit HG=“ISUP Not Required” sent for all nonISDN originated calls. Bit HG=“ISUP Preferred” sent for all ISDN originated calls. Bit HG=“ISUP Preferred” sent for all non-ISDN originated calls. Bit HG=“ISUP Required” sent for special calls that require ISUP for proper functioning of an applicable supplementary service. NOA=“National” sent and Address Digits do not contain leading prefix; Example: “49871234” or “271234567” Calling party number parameter not included in IAM4 NOTE that if a Calling Party Number is not included in the IAM some services will not operate correctly and some calls may fail. Page 3 USI passed transparently Call released (cause 88) Call released (cause 65) FCI Bit A passed transparently Bit A=“International” sent on o/g circuit to Spark for transit calls from International NetworkOther NetworkSpark Bit I Passed transparently Bit I mapped to Non-ISDN on o/g circuit to Spark (valid when call converted to Not-ISUP Not-SS7). Bit HG passed transparently Bit HG mapped to “ISUP Not Required” (valid when call converted to Not-SS7 Not-ISUP; Ref. Q.2, Q.3 and Q.4) NOA and address digits passed transparently Calling party number parameter discarded4 NOA= “International” sent on o/g circuit to Spark for transit calls from International NetworkOther NetworkSpark PTC331 Form B (Additional ISUP Questionnaire) Description 7 (ctd) (b) Calling party number: Maximum address digits (c) Calling party number: Presentation restriction (CLIR) indicator (d) Calling party number: Screening indicator 8 (a) Called party number: NOA and Address Digits (b) Called party number: Maximum address digits (c) Called party number: “ST” and overlap operation February 1, 2015 Call Direction: SparkOther Network 1 Up to 24 digits received successfully Up to ............ (please specify) digits received successfully Call Direction: Call Dir: SparkOther NetworkSpark 3 2 Other NetworkSpark A national number of at least 8 digits can be Up to 24 digits can be passed transparently generated in IAM Up to ............ (please specify) digits can be A maximum ............ (please specify) digit passed transparently national number can be generated Calling party number parameter discarded4 Calling party number parameter not included in IAM4 CLIR indicator respected; Number not CLIR generated when applicable CLIP/CLIR indicators passed transparently. displayed to called party. CLIP/CLIR services not supported; Number All calls converted to CLIR ie. CLIR sent on o/g CLIP/CLIR services not supported; Number always sent as CLIP circuit to Spark cannot be displayed to called party CLIP/CLIR services not supported; Number Calling party number parameter discarded4 always sent as CLIR Calling party number parameter not included in IAM4 Call answered successfully “Network provided” calling party number sent Screening indicator passed transparently (Clg Scrn Ind=“user provided verified and for all PSTN calls Calling party number parameter discarded4 passed” or “network provided’” can be “Network provided” calling party number may received from Spark) be sent for ISDN originated calls “User provided verified and passed” clg party numbers may be sent for ISDN orig. Calls Calling party number parameter not included in IAM4 Call answered successfully NOA=“Unknown” sent and Address Digits may NOA=“Unknown” sent on outgoing circuit to NOA=Unknown can be received from Spark contains zero prefixes; Examples: Spark. Address digits may contain zero and Address Digits may contains zero “0061287654321” for international calls, prefixes; Examples: prefixes; Examples: “056748021234” for toll bypass calls & “0061287654321” for international calls, “0061287654321” for international calls, “048021234” for local & toll calls “056748021234” for toll bypass calls & “056748021234” for toll bypass calls & “048021234” for local & toll calls “048021234” for local & toll calls Up to 24 digits received successfully Up to 24 digits including “ST” can be generated Up to 24 digits including “ST” passed Up to ............ (please specify) digits Up to ............ (please specify) digits including transparently received successfully “ST” can be generated Up to ............ (please specify) digits including “ST” passed transparently “ST” recognised and processing/routing of call is started upon receipt of IAM from Spark. “ST” always sent to Spark for all calls Page 4 “ST” always sent on outgoing circuit to Spark PTC331 Form B (Additional ISUP Questionnaire) Description 9 10 ACM procedure when the called party is free (a) BCI Bit I: Interworking indicator (b) BCI Bit K: ISUP indicator (c) BCI Bit M: ISDN access ind. 11 (a) CPG Event = Alerting Call Direction: SparkOther Network 1 ACM “subscriber free” (and ringing tone) sent when Dest = Non-ISDN ACM “subscriber free” (and ringing tone) sent when Dest = ISDN ACM sent early with “no indication” when Dest = ISDN followed by CPG with Event=“Alerting” (and ringing tone). “No working” sent for all calls “Interworking” sent for all calls “No interworking” sent for most calls but “Interworking” sent when ............................... Please supply details on separate sheet. “ISUP used all the way” sent for all calls “ISUP not used” sent for all calls “ISUP used all the way” sent for most calls but “ISUP not used” sent when ........................... Please supply details on separate sheet. “Terminating Access ISDN” sent when called party is ISDN “Terminating Access Non-ISDN” set when called party is Non-ISDN CPG not generated (incoming calls generate ACM with called party status=subscriber free) CPG sent with Event=Alerting when Q.931 ALERT received from ISDN user-networkinterface (or equivalent) February 1, 2015 Call Direction: Call Dir: SparkOther NetworkSpark 3 2 Other NetworkSpark Late ACM (and ringing tone) can be received ACM passed transparently from Spark when Dest=Non-ISDN ACM mapped to Not-SS7 Not-ISUP Non-ISDN Early ACM and CPG with Event=“Alerting” (and ACM sent early with Not-SS7 Not-ISUP ringing tone) can be received from Spark when Non-ISDN Dest=ISDN Ringing tone sent by destination node is received by caller “No interworking” and “Interworking Encountered” can be received from Spark. Bit I passed transparently Bit I converted to “Interworking Encountered” (valid when call converted to Not-SS7 or when Early ACM used). “ISUP used all the way” and “ISUP not used” can be received from Spark. Bit K passed transparently Bit K converted to “ISUP not used” (valid when call converted to Not-ISUP or when Early ACM used). “Term Access ISDN” and “Term Access NonISDN” can be received from Spark. Bit M passed transparently Bit M converted to “Term Access non-ISDN” (valid when call converted to Not-SS7 Not-ISUP or when Early ACM used). CPG passed transparently CPG discarded Event Info parameter in CPG passed transparently; other parameters discarded Ringing tone sent by destination node is received by caller Able to receive CPG Event=Alerting and connect the speech circuit for receiving ringing tone from Spark. Page 5 PTC331 Form B (Additional ISUP Questionnaire) Description 11 (b) CPG Event = Progress (ctd) 12 (a) Release message (REL) (b) Cause values: 16 Normal call clearing 17 User busy 01 Unallocated number 18 No user responding 19 No answer from user 21 Call rejected 27 Dest out of service 28 Invalid number format 34 No circuits available 42 Switch. Equip congest. 63 Serv/opt not available 65 Bearer cap not impl. 88 Incompatible dest. (c) Cause location February 1, 2015 Call Direction: Call Direction: Call Dir: SparkOther NetworkSpark 3 1 2 SparkOther Network Other NetworkSpark CPG not generated (incoming calls generate Other network able to receive CPG CPG passed transparently ACM with called party status=no indication) Event=Progress and connect the speech circuit CPG discarded (valid when call converted to CPG sent with Event=Progress when Q.931 for receiving call progress tones or Not-ISUP/Not-SS7; Ref. Q.2, Q,3 and Q.4) PROGRESS received from ISDN userannouncements Event Info parameter in CPG passed network-interface transparently ; other parameters discarded CPG sent with Event=Inband Information Ringing tone sent by destination node is when further call progress information is received by caller available inband. REL (cause 16) sent when called party REL (cause 16) sent when calling party hangs REL (cause 16) passed transparently hangs up first up first REL (cause 16) can be received when REL (cause 16) can be received when called calling party hangs up first party hangs up first and Disconnect tone applied to calling party’s line. Cause values (cv) sent in REL to Spark: Tones applied when cv received in REL from Spark: Cv sent in REL message to Spark: Disc tone Cv=16 sent when clg or cld party hangs up Busy tone Passed transparently Cv=17 sent when called party is busy Number unobtainable tone applied Passed transparently Cv=01 sent when unallocated number Appropriate tone applied: ........................... Passed transparently dialled Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=18 sent Cv Not Generated Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=19 sent Cv Not Generated Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=21 sent Cv Not Generated Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=27 sent Cv Not Generated Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=28 sent Cv Not Generated Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=34 sent Cv Not Generated Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=42 sent Cv Not Generated Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=63 sent Cv Not Generated Appropriate tone applied: ........................... Passed transparently Mapped to ........... Cv=65 sent Cv Not Generated Passed transparently Mapped to ........... Cv=88 sent Cv Not Generated Cause locations sent in REL to Spark: Cause locations: LN, RLN, USER, LPN, RPN, Pass transparently LN sent for call clearing by PSTN user TN & INTL may be received from Spark and TN if call cleared by transit network RLN sent for call clearing by PSTN user appropriate tone as shown in (b) applied to INTL if call cleared by international network USER sent for call clearing by ISDN user calling party. (International NetworkOther LPN sent for call clearing by ISDN user NetworkSpark or SparkOther RPN sent for call clearing by ISDN user NetworkInternational Network) Other ................ (please specify) Page 6 PTC331 Form B (Additional ISUP Questionnaire) Description 12 (c) (ctd) (d) Signalling point code parameter February 1, 2015 Call Direction: Call Direction: 1 SparkOther Network Other NetworkSpark 2 Cause locations: LN, RLN, USER, LPN, Cause locations sent in REL to Spark: RPN, TN & INTL may be received from LN sent for call clearing by PSTN user Spark and appropriate tone as shown in (b) RLN sent for call clearing by PSTN user applied to calling party. USER sent for call clearing by ISDN user LPN sent for call clearing by ISDN user RPN sent for call clearing by ISDN user Sent in all REL messages Parameter able to be received Not sent (e) Automatic congestion level (ACL) parameter 13 14 15 Sending of ACL parameter in REL to Spark: Sending of ACL parameter in REL to Spark: Sent when congestion level exceeds Sent when congestion level exceeds predefined threshold. predefined threshold. Not sent Not sent Receipt of ACL parameter in REL: Receipt of ACL parameter in REL: Traffic reduced to Spark Traffic reduced to Spark ACL ignored (traffic levels remain ACL ignored (traffic levels remain unchanged) unchanged) (f) REL (cv=17; busy) after Not generated; cv=16 always sent after ANM REL cv=17 (busy) can be received after ANM ANM Cv=17 (busy) may be generated after ANM and busy tone applied to calling party Specify the other action (not Busy Tone) taken .................................................................. ....... if REL cv=17 (busy) is received after ANM (a) ATP sent in forward direction Call answered successfully ATP may be generated from ISDN users (ATP can be received from Spark) ATP not generated (all calls are Non-ISDN) (b) ATP sent in backward direction (a) UUI sent in forward direction (b) UUI sent in backward direction (a) Suspend (SUS) and Resume (RES) messages sent in forward direction (b) Suspend (SUS) and Resume (RES) messages sent in backward direction ATP may be generated from ISDN users ATP not generated (all calls are PSTN) Call answered successfully (UUI can be received from Spark) UUI may be generated from ISDN users UUI not generated (service is not supported) SUS/RES can be received from Spark Call answered successfully (ATP can be received from Spark) UUI may be generated from ISDN users UUI not generated (service is not supported) Call answered successfully (UUI can be received from Spark) SUS/RES may be generated from ISDN users SUS/RES not generated SUS/RES may be generated from ISDN users SUS/RES not generated SUS/RES can be received from Spark Page 7 Call Dir: SparkOther NetworkSpark 3 Parameter passed transparently Parameter discarded; not included in REL to Spark Sending of ACL parameter in REL to Spark: Sent when congestion level in TN exceeds predefined threshold. Not sent Receipt of ACL parameter in REL: Traffic reduced to Spark ACL ignored (traffic levels remain unchanged) REL and Cause 17 (busy) passed transparently after ANM ATP passed transparently ATP discarded (valid when call converted to Not-ISUP/Not-SS7; Ref. Q.2, Q,3 and Q.4) [covered in Q.13 a] UUI passed transparently UUI discarded [covered in Q.14 a] SUS/RES passed transparently SUS/RES discarded (valid when call converted to Not-ISUP/Not-SS7; Ref. Q.2, Q,3 and Q.4) [covered in Q.15 a] PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 Call Forwarding Description 16 17 18 19 19 (ctd) Action taken by Other Network when forwarding occurs in the other network: Call forwarding parameters IAM sent to Spark has all of the following call parameters present: in IAM Calling party number parameter (ref. Form B Question 7) Redirecting number parameter (ref. Form B Question 17) Original called number parameter (ref. Form B Question 18) Redirection information parameter (ref. Form B Question 19) Redirecting number IAM sent to Spark has redirecting number parameter set as follows: NOA=“National” sent and Address Digits does not contain leading zero prefix; Examples: “49871234” or “25123456” Numbering Plan = “ISDN (Telephony) E.164” Original called number IAM sent to Spark has original called number parameter set as follows: NOA=“National” sent and Address Digits does not contain leading zero prefix; Example: “49871234” or “25123456” NOA=“Unknown” sent and Address Digits may contain leading zero prefix; Examples: “049871234” or “025123456” for toll calls & “9871234” for local calls. Numbering Plan = “ISDN (Telephony) E.164” INN indicator = “Routing to internal network number allowed” Presentation indicator = “allowed” Presentation indicator = “restricted” can be sent (a) Redirection information IAM sent to Spark contains: Redirection information parameter (b) Redirection counter IAM sent to Spark has redirection counter incremented by 1 and the maximum that can be sent is 5. maximum that can be sent is ................. (please specify) When counter exceeds the maximum value, please state the cause value used to release the call: CFU: REL sent immediately with cause value ...................... CFB: REL sent immediately with cause value...................... CFNA: REL sent after ringing timeout with cause value .............. (c) Redirecting reason IAM sent to Spark has redirecting reason set to: “user busy” for CFB at the last diverting exchange “no reply” for CFNR at the last diverting exchange “unconditional” for CFU at the last diverting exchange Page 8 Action taken by Other Network (transit exchange) and Other Network is not involved in the forwarding of the call Calling party number parameter passed transparently Redirecting number parameter passed transparently Original called number parameter passed transparently Redirection information parameter passed transparently Ref. Q.16 Ref. Q.16 Ref. Q.16 Ref. Q.16 REL passed on transparently Ref. Q.16 PTC331 Form B (Additional ISUP Questionnaire) Description (d) Original redirection reason 20 Other ISUP parameters: Action taken by Other Network when forwarding occurs in the other network: IAM sent to Spark has redirection original reason set to: “user busy” for CFB at first diverting exchange; unchanged on subsequent diversions. “no reply” for CFNR at first diverting exchange; unchanged on subsequent diversions. “unconditional” for CFU at first diverting exchange; unchanged on subsequent diversions. A call from Spark which diverts back to Spark Action taken by Other Network (transit exchange) and Other Network is not involved in the forwarding of the call Ref. Q.16 A call from Spark returns to Spark via the Other Network: (a) FCI FCI passed transparently by diverting exchange FCI passed transparently by transit exchange (b) TMR TMR passed transparently by diverting exchange TMR passed transparently by transit exchange (c) USI USI passed transparently by diverting exchange USI passed transparently by transit exchange (d) Calling party number Calling party number passed transparently by diverting exchange Calling party number passed transparently by transit exchange (e) ATP Access Transport Parameter passed transparently by diverting exchange User-to-user Information passed transparently by diverting exchange Both the Redirecting number parameter and Original called number is sent in the IAM Only Original called number is sent in the IAM. Redirecting number parameter is not present in IAM. Length of the Redirection information parameter is 1 octet. Length of the Redirection information parameter is 2 octets. END OF FORM B Access Transport Parameter passed transparently by transit exchange (f) UUI 21 February 1, 2015 (a) When the redirection counter is set to 1: (b) When the redirection counter is set to 1 Page 9 User-to-user Information passed transparently by transit exchange Ref. Q.16 Ref. Q.16 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 Explanations to Questions in Form B Key to abbreviations used in Form B Abbreviation 3.1 kHz 64k UDI A-Law A-Law ATP BICC BCI cause or cv cct cld clg CLIP CLIR Dest FCI Gen i/c ind Interwkg or i/w INTL ISDN ISUP LN LPN No Interwkg NOA Non-ISDN Not Gen Not-ISUP Not-SS7 o/g Orig R2MFC RLN RPN SIP Speech TA TMR TN UDI UID UNI USI USI UUI Description TMR = 3.1 kHz audio TMR = 64 kbit/s UDI USI parameter octet 3 (User info. layer 1 protocol) = A-Law USI parameter octet 3 (User info. layer 1 protocol) not present; A-Law assumed Access Transport Parameter Bearer Independent Call Control signalling protocol (ref. ITU-T recommendation Q.1901 etc.) Backward Call Indicator parameter of ISUP Cause Value circuit Called party number Calling party number Calling line identity presentation allowed (clg parameter presentation ind = allowed) Calling line identity presentation restricted (clg parameter presentation ind = restricted) Destination Forward Call Indicator parameter of ISUP Signal or Call Type can be generated incoming indicator FCI Bit D = Interworking Encountered or BCI Bit I = Interworking Encountered International Network (Integrated Services Digital Network). FCI Bit I = Orig Access ISDN or BCI Bit M = Term Access ISDN Uer Part (of SS7). FCI Bit F = ISUP used all the way or BCI Bit K = ISUP used all the way Local Network Local Private Network FCI Bit D = No Interworking or BCI Bit I = No Interworking Nature of Address FCI Bit I = Orig Access Non-ISDN or BCI Bit M = Term Access Non-ISDN Signal or Call Type is not support and cannot be generated FCI Bit F = ISUP not used all the way or BCI Bit K = ISUP not used all the way FCI Bit F = ISUP not used all the way and FCI Bit D = Interworking Encountered or BCI Bit K = ISUP not used all the way and BCI Bit I = Interworking Encountered outgoing Origination Multi-Frequency Compelled signalling system R2 (ref. ITU-T recommendations Q.421, Q.440 etc.) Remote Local Network Remote Private Network Session Initiation Protocol (ref. IETF RFC 3261) TMR = Speech ISDN Terminal Adaptor Transmission medium requirement Transit Network Unrestricted digital information User Interactive Dialog ISDN User-Network Interface, ie DSS1/Q.931 User service information USI parameter not present in IAM User-to-user information Text Text that are shown in light italics typeface represent options that which may be acceptable in some cases, are generally not preferred. Spark recommends that you avoid selecting this option whenever possible. All other abbreviations are as used in the ITU standards Q.76X and Q.850. Page 10 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 Valid ISUP settings In accordance with the relevant ITU-T procedures, the ISUP parameters passed on the PTC331 interface need to be populated appropriately to reflect the call characteristics, and only certain combinations of parameter settings are valid. Invalid settings can adversely impact service or cause call failure in some situations. The questions in FORM B seek to confirm that your network is configured to send and receive valid ISUP signalling for the call types supported on the PTC331 interface. The following text provides guidance on the expected ISUP parameter settings for typical call scenarios. Interworking with Not-ISUP network signalling systems The ISUP FCI and BCI parameters passed on the PTC331 interface need to reflect any interworking with other network signalling systems encountered on either side of the interface. Typically these signalling systems will be:  SIP (for VOIP based networks)  BICC (for mobile networks)  R2MFC (for older technologies, as used in some parts of Spark’s network). The FCI (carried in the IAM) indicates any interworking encountered upstream (i.e. on the call origination side) of the PTC331 interface. The BCI (carried in ACM or CPG) indicates any interworking encountered downstream (i.e. on the call destination side) of the PTC331 interface. Interworked Signalling System Indicated in ISUP parameters as: FCI bit D FCI bit F BCI bit I BCI bit K [1=SS7 i/w] [0=no SS7 i/w] [1=all ISUP] [0=not all ISUP] [1=SS7 i/w] [0=no SS7 i/w] [1=all ISUP] [0=not all ISUP] SS7 TUP* SS7 but Not-ISUP 0 0 0 R2MFC or older system Not-SS7 and Not-ISUP 1 0 1 SIP Not-SS7 and Not-ISUP 1 0 1 SIP-I Treated as SS7 ISUP 0 1 0 BICC Treated as SS7 ISUP 0 1 0 (No interworking) SS7 ISUP 0 1 0 *Very rarely encountered and only on international calls. Unlikely on the PTC331 interface. 0 0 0 1 1 1 NOTE: Interworking also determines the validity of other ISUP parameter values. E.g. downstream from a Not-ISUP signalling stage the Originating Access must always be coded as “Non-ISDN”, TMR must be coded as 3.1kHz audio and the USI parameter must not be present in the IAM. Originating and Terminating Access ISUP identifies the type of customer end points in a call as either “ISDN” or “Non-ISDN” only, and encodes that information into the FCI (for the originating access) and BCI (for the terminating access) parameters passed on the PTC331 interface.  PSTN (i.e. analog CPE) is always identified as “Non-ISDN” Access.  ISDN (BRA or PRA based CPE using DSS1 access signalling) is always identified as “ISDN” Access.  Mobile CPE may be identified as either “ISDN” or “Non-ISDN” Access depending on the characteristics of the host mobile network. It is common for Mobile CPE to be identified as “ISDN” Access.  VOIP based CPE may be identified as either “ISDN” or “Non-ISDN” Access depending on the characteristics the host VOIP network. It is most common for VOIP CPE to be identified as “Non-ISDN” Access. NOTE: As only ISUP (or equivalent) signalling can convey information about whether the access is ISDN, if there is a Not-ISUP stage of signalling between an ISDN access and the PTC331 interface then the FCI or BCI, as applicable, carried on the interface will default to “Non-ISDN”. Page 11 PTC331 Form B (Additional ISUP Questionnaire) Type of Access PSTN ISDN Explanation analog CPE BRA or PRA based CPE using DSS1 access signalling emulating ISDN other emulating ISDN other Mobile VOIP Identified in ISUP as: February 1, 2015 FCI bit I BCI bit M [1=ISDN orig.] [0=non-ISDN orig.] [1=ISDN term.] [0=non-ISDN term.] Non-ISDN ISDN 0 1 0 1 ISDN Non-ISDN ISDN Non-ISDN 1 0 1 0 1 0 1 0 Coding of TMR PSTN and other “Non-ISDN” originated calls can include speech and voice-band data (modem & G3 fax traffic) and the later will terminate successfully to some ISDN CPE only if the bearer capability delivered in DSS1 (mapped from TMR/USI in ISUP) is set to “3.1 kHz audio”. TMR = 3.1 kHz audio is therefore the only value applicable to a Non-ISDN originating access. Ref (1): Ref (2): ITU. Recommendation I.530, Section 5.1, Note 2 which states that 3.1kHz audio is the standard TMR for non-ISDN Access (e.g. PSTN) originated calls used for the purpose of speech information transfer and for 3.1 kHz audio information transfer (analog modem & G3 fax). PTC331 Part C Section 3.54: 3.1 kHz audio; set for ISDN audio and all PSTN calls. “ISDN” originated calls can include speech, voice-band data (modem & G3 fax traffic) or unrestricted 64kbit/s data. The TMR must identify which transmission medium is required for the call in order to ensure successful call delivery. A wrongly coded TMR will not terminate successfully to some ISDN CPE which checks the bearer capability delivered in DSS1 (mapped from TMR/USI in ISUP), or may result in the call being delivered to CPE that does not support the required service. Coding of USI The USI parameter is used to enable an originating ISDN subscriber to advise the terminating subscriber the transmission protocol used and is coded directly from the ISDN access Q.931 Bearer Capability information element. Ref PTC331 Part C Section 3.57. USI is carried in the ISUP IAM. Accordingly, the USI should not be included in the IAM for non-ISDN originated calls, or beyond a stage of NotISUP (or equivalent) network signalling. For ISDN originated calls, the USI must be specified and the information transfer capability of the USI should be set to the same value as the TMR. In addition, the USI may also indicate the layer 1 user information protocol (octet 3; ref. TNA.134 and Q.931 Section 4.5.5 and PTC331 Section 3.57). This is an optional sub-field of the USI. If present, it should be set to: (a) A-Law for ISDN speech and ISDN 3.1 kHz audio calls. For these calls, if this sub-field is not present, A-Law will be assumed. Use of any other value other than A-Law will result in call failure or distortion of speech. (b) ITU standardized rate adaption V.110 and X.30 for 64 kbit/s unrestricted data calls. If this sub-field is present a user rate should also be specified (octet 5a). For 64 kbit/s unrestricted data calls sent to 56 kbit/s networks, a user rate of 56 kbit/s or lower should be used. On transit calls, the USI parameter should be passed transparently (ref. PTC331 Part C Section 3.57.1) by all networks. Page 12 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 Question 1 1(a) & 1(b) Other NetworkSpark: For Non-ISDN originated calls either of the following two possible valid combinations of the relevant ISUP parameters are expected to be used, as shown in the following table. The abbreviation shown is used in the questions to indicate the combination of parameter settings in the table. Abbreviation used to indicate Call Type ISUP parameter setting used with given Call Type TMR USI FCI Bit D FCI Bit F FCI Bit I Non-ISDN 3.1kHz audio SS7 ISUP USI 3.1 kHz audio Not present Non-ISDN3.1kHz audio Not-SS7 Not-ISUP USI 3.1 kHz audio Not present No SS7 interworking encountered SS7 interworking encountered ISUP used all the way ISUP not used all the way Orig Access Non-ISDN Orig Access Non-ISDN In your answer to questions 1(a) & 1(b), please tick one or more of the boxes shown to indicate which call type(s) will be generated in your network and sent to Spark, and confirm that both call types can be received from Spark. Normally a network would be expected to generate only one call type. However, more complex networks which use a mixture of different network signalling systems may generate more than one call type (e.g. Non-ISDN originated calls in a given network may use (a) ISUP all the way to the POI, or (b) a combination of R2MFC and ISUP, or SIP and ISUP). 1(a) SparkOther NetworkSpark: The action taken by your network when a PSTN 3.1 kHz audio call is received from Spark will either be to pass the signalling content unchanged or default to fixed parameter values as described below. Please indicate the option used by your network. Call treatment Signalling passed unchanged Mapped to Non-ISDN 3.1 kHz audio Not-SS7 Not-ISUP USI 1(b) TMR  3.1 kHz audio USI N.A. Not present FCI Bit D  SS7 interworking encountered FCI Bit F  ISUP not used all the way FCI Bit I  Orig Access Non-ISDN For Q1(b) the only valid treatment is to send the call as “Non-ISDN 3.1 kHz Not-SS7 Not-ISUP USI” which is the same as received from Spark. Question 2 ISDN originated speech calls are calls that connect for speech transfer only (and not for 3.1 kHz audio information transfer such as analog modem or G3 fax). Ref. PTC331 Part C Section 3.54 and ITU Recommendation I.530. Spark expects to send such calls to your network. Other NetworkSpark: If ISDN Speech calls are generated by your network, confirm that they are signalled to Spark as shown. Alternatively, tick the “ISDN Speech calls not generated” box if your network does not support ISDN speech. Call type ISDN Speech SS7 ISUP USI TMR Speech USI Speech FCI Bit D No interworking FCI Bit F ISUP used all the way ISDN Speech call not generated N.A. N.A. N.A. N.A. Page 13 FCI Bit I Orig Access ISDN N.A. PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 SparkOther NetworkSpark: The action taken by your network when an ISDN Speech call is received from Spark will either be to pass the signalling content unchanged or default to fixed parameter values as described. Please indicate the option used by your network. Question 3 Coding of TMR ISDN originated TMR=3.1 kHz audio calls are calls that connect for 3.1 kHz audio information transfer. This call type is used to communicate with PSTN terminal equipment such as telephones, G3 fax machines and analog data modems located in the PSTN (or in the ISDN where a Terminal Adaptor is used). ISDN originated TMR=3.1kHz audio is not set when the originating terminal knows for certain that the call is to be connected for speech transfer (ISDN orig.TMR=Speech is used in this case, ref. Q.2 above for details). Other NetworkSpark: If ISDN 3.1kHz audio calls are generated by your network, confirm that they are signalled to Spark as shown. Alternatively, tick the “ISDN 3.1kHz calls not generated” box if your network does not support ISDN originated 3.1kHz. Call type TMR ISDN 3.1 kHz audio SS7 ISUP 3.1 kHz audio USI 3.1 kHz audio FCI Bit D No interworking Non-ISDN 3.1kHz audio NotSS7 Not-ISUP USI 3.1 kHz audio Not present interworking Encountered ISDN 3.1kHz audio call not generated N.A. N.A. N.A. FCI Bit F ISUP used all the way FCI Bit I Orig Access ISDN ISUP not Orig used all the Access way Non-ISDN N.A. N.A. SparkOther NetworkSpark: The action taken by your network when an ISDN 3.1kHz audio call is received from Spark will either be to pass the signalling content unchanged or default to fixed parameter values as described. Please indicate the option used by your network. Question 4 ISDN originated TMR=64 kbit/s unrestricted digital data calls are calls that connect for 64 kbit/s unrestricted digital data information transfer (64k UDI transfer). The 64k UDI capability allows calls from ISDN terminal equipment to communicate with other 64k UDI terminals in the ISDN. Some overseas networks may still use SS7 TUP (Telephone User Part), not ISUP, to support a pre-ISDN version of 64k UDI capability, and calls originating from such sources could be delivered to other networks via the Spark POI exchange. Such cases are now very rare or non-existent. Spark network uses only ISUP SS7 for call control so this case does not arise with calls to or from the Spark PSTN where data communication must use 3.1 kHz audio analog data information transfer. Ref. PTC331 Part C Section 3.54. Page 14 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 SparkOther Network: Tick one box only. Tick the “Call is released (cause = 88 or 65)” if your network does not support ISDN 64k UDI data calls. If this applies, these 64k UDI calls should be released at the entry point to your network at which the call was received. Other NetworkSpark: Tick the box to indicate whether or not ISDN 64k UDI ISUP calls will be generated in your network and sent to Spark. Call type ISDN 64k UDI ISUP ISDN 64k UDI call not generated TMR 64 kbit/s unrestricted N.A. USI 64 kbit/s UDI N.A. FCI Bit D No interworking N.A. FCI Bit F ISUP used all the way N.A. FCI Bit I Orig Access ISDN N.A. SparkOther NetworkSpark: Tick the box that best describes the action taken by your network when an ISDN 64k UDI call is received from Spark. Question 5 The USI parameter is used to enable the originating ISDN subscriber to advise the terminating subscriber the transmission protocol used and is coded directly from the ISDN access Q.931 Bearer Capability information element. Ref PTC331 Part C Section 3.57. Accordingly, the USI should not be sent for non-ISDN originated calls. For ISDN originated calls, the USI must be specified and the information transfer capability of the USI should be set to the same value as the TMR. In addition, the USI may also indicate the layer 1 user information protocol (octet 3; ref. TNA.134 and Q.931 Section 4.5.5 and PTC331 Section 3.57). This is an optional sub-field of the USI. If present, it should be set to: (a) A-Law for ISDN speech and ISDN 3.1 kHz audio calls. For these calls, if this sub-field is not present, A-Law will be assumed. Use of any other value other than A-Law will result in call failure or distortion of speech. (b) ITU standardized rate adaption V.110 and X.30 for 64 kbit/s unrestricted data calls. If this sub-field is present a user rate should also be specified (octet 5a). For 64 kbit/s unrestricted data calls to 56 kbit/s networks, a user rate of 56 kbit/s or lower should be used. On transit calls, the USI parameter should be passed transparently (ref. PTC331 Part C Section Paragraph 3.57.1) by all networks. Question 6 (a) FCI Bit A (Ref. PTC331 Part C Section 3.23.4 Bit A) indicates whether the call is an international call or a national call. On the PTC331 interface between Spark and Other Network: SparkOther Network: Bit A will be set to “National” International NetworkSparkOther Network: Bit A will be set to “International” Other NetworkSpark: Bit A should be set to “National” International NetworkOther NetworkSpark: Bit A should be set to “International” Page 15 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 SparkOther NetworkSpark: Bit A should be set to “National” International NetworkSparkOther NetworkSpark: Bit A should be set to “International” (b) FCI Bit I (Ref. PTC331 Part C Section 3.23.4 Bit I) indicates whether the call is originated from an ISDN line or a Non-ISDN line (ie. PSTN line or not known). (c) FCI Bits HG (Ref. PTC331 Part C Section 3.23.4 Bits HG) indicates the type of signalling that should be used by transit networks when routing the call to its destination. As stated in PTC331, “ISUP not required” is used for all PSTN originated calls and “ISUP preferred” is used for most ISDN originated calls. Question 7 (a) Ref. PTC331 Part C Section 3.10.4. In accordance with ITU Recommendation Q.763 and the E.164 numbering plan, the NZ national network calling party number is always coded with “Nature of Address” set to “National (significant) number”, and the address digits in E.164 national number format (ie. commencing with area code and with no prefix/access code digits). For calls originated from overseas, the calling party number is always coded with “Nature of Address” set to “International number”, and the address digits in E.164 international number format (ie. commencing with country code and with no prefix/access code digits) on the PTC331 interface. Example No.1 A call originated by Wellington Directory Number 765 4321 will carry the ISUP calling party number parameter coded as NOA=“National”. Digits = “47654321” Example No.2 A call originated in the “027” mobile network will carry the ISUP calling party number parameter coded as NOA=“National”. Digits = “276543210” Example No.3 A call originated by Sydney directory number 8765 4321 will carry the ISUP calling party number parameter coded as NOA=“International”. Digits = “61287654321”. (b) ITU Recommendation E.164 and references to Time-T (31.12.1996) state that the international number may be of variable length and the maximum number length shall be 15 digits after Time-T. This length does not include prefixes, language digit, address delimiters (eg. End-of-address signals, etc.) since these items are not part of the international number. The Spark network is able to receive calling party numbers up to a maximum of 24 digits including address delimiters. If your network has implemented a different maximum address length, please write the maximum number provided in the space provided for part (b) of this question. Note that the maximum length of the calling party number may be less than the maximum length of the called party number (ref. Question 8b) as the calling party number does not contain prefixes or the endof-address “ST” signal which are used in the called party number. (c) The calling party number presentation indicator (Ref. PTC331 Part C Section 3.10.4 (e) and the appropriate Calling Party Number Agreement) are used to protect the privacy of the calling party. SparkOther Network If your network offers non-transit calls such as local interconnect service (where calls from Spark terminate on customer lines located within the your network), respecting the calling party number presentation restriction subfield (CLIR) means that if your network offers a “caller display” service, the calling party number will not be displayed on the called party’s terminal if the calling party number’s presentation indicator field is set to “restricted” in the IAM sent from Spark. Page 16 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 Transit Calls: SparkOther NetworkSpark If your network offers transit calls such as toll bypass, 0800AB or call forwarding service, the calling party number presentation indicator subfield should be passed on unchanged on a transit call. If this capability does not exist in your network, it may be acceptable by bilateral agreement, to always set presentation indicator to “restricted” with outgoing calls to the Spark network, Please tick the appropriate check boxes for this question to indicate your proposed method of working. (d) The calling party number screening indicator (SI) (Ref. PTC331 Part C Section 3.10.4 (f)) is used to indicate whether the calling party number was supplied by the network or the calling user. If the number was supplied by the calling user, the SI also states that the network has checked that the number supplied by the user was a valid number from within the range of numbers allocated to the user (e.g. for a PBX). A Spark originating exchange checks any calling party number supplied by an ISDN user hosted on that exchange and if valid sets the SI as “user provided, verified and passed”. If the number is found to be invalid, it is replaced by a “Network provided” number (typically a PBX Pilot Number) registered to the calling user in the Calling party Number parameter sent in the IAM to the Other Network. A PSTN calling party does not have the capability to supply a calling party number and hence a “Network provided” number is sent for all PSTN originated calls. It is essential that the calling party number screening indicator is set correctly as it is used by network equipment to confirm the validity of the caller as a fraud prevention measure. Question 8 (a) Ref. PTC331 Part C Section 3.9.2 (b) and (d). The NZ national network always uses the “Unknown” Nature of Address (NOA) format as defined in Q.763 for the coding of the called party number which means that the type of number (be it local, national or international) is not indicated by the NOA field in the called party number but by the presence or otherwise of prefix(es) (eg. “0”) inserted at the front of the national number address digits. NOA “unknown” (0000010) is termed “Spark Specific” in some documentation. This does not indicate a Spark proprietary signal, it is simply a local term for the ITU-T defined value “unknown”. With NOA=Unknown, the format of called party number that may be sent in the IAM in various formats, e.g. as follows: i) Full Prefix + Full National Number From Spark to Other Network: eg. For a national toll bypass call: “0567 42201981” eg. For a mobile call: “021 654321”, “025 654321”,“029 654321” From Other Network to Spark: eg. For a call terminating in the Spark network: “04 2201981” iii) Full Prefix + Full International Number From Spark to Other Network: eg. For an international toll bypass call: “0567 61 2 87654321” From Other Network to Spark: eg. For an international call: “00 61 2 87654321” The formats in the examples shown above are normally the only formats used on the PTC331 interface. (b) ITU Recommendation E.164 and references to Time-T (31.12.1996) state that the international number may be of variable length and the maximum number length shall be 15 digits after Time-T. This length does not include prefixes, language digit, address delimiters (eg. End-of-address signals, etc.) since these items are not part of the international number. To allow for the use of prefixes for network and service selection (eg. “00” and “05XY”) and the mandatory “ST” signal as the last “digit” of the called party number it is necessary that networks support greater than 15 digits. Page 17 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 Spark has chosen to implement a maximum of 24 digits international number including prefixes and address delimiters. If your network has implemented a different maximum address length, please write the maximum number provided in the space provided for part (b) of this question. (c) As the Spark network uses only en-bloc delivery of the called party number the called party address digits must always include the “ST” (stop signal or end-of-address signal; Binary value “1111” or “F” hex) as the last digit. Ref. PTC331 Part C Section 4.16 (SAM not supported) and ITU Q.764 Section 2.1.2. This signal is used to indicate to the exchange receiving the IAM that all digits of the called party have been sent and that the exchange receiving the IAM should not expect to receive any more digits and should continue to route or connect the call to the destination exchange or called party respectively. Question 9 Ref. PTC331 Part C Sections 3.5, 3.21, 4.2 and 4.4 When an IAM is sent to a terminating subscriber’s line, alerting indication can be returned in one of 2 ways: (i) ACM with the called party status indicator in the Backward Call Indicator (BCI) parameter set to “subscriber free”. This sequence is generally known as Late ACM. (ii) CPG with event indicator in the Event Information parameter set to “alerting”. The CPG message normally follows an ACM with called party status set to “no indication”. This sequence is generally known as Early ACM. ITU Recommendation Q.764 Sections 2.1.4 states that when terminating access is non-ISDN Late ACM should be used, and when the terminating access is ISDN either Early ACM (ACM sent with called party status = “no indication”) or Late ACM (ACM sent with called party status = “subscriber free”) may be used. . SparkOther Network (ie ACM direction is Other NetworkSpark) Please indicate which ACM generation procedure is used by your network for calls terminating to PSTN and, if applicable, ISDN lines. The two ACM generation procedures are illustrated in Figures 9.1 and 9.2 below. [NOTE: protocol X=PTC331 ISUP; protocol Y=the customer access protocol used by the Other Network] Figure 9.1 Early ACM in Incoming Call to Other Network Figure 9.2 Late ACM on Incoming Call to Other Network Other NetworkSpark (ie ACM direction is SparkOther Network) Confirm that your network can accept both Early and Late ACM sent by Spark. SparkOther NetworkSpark Normal ACM handling for a transit call is to pass the ACM transparently as illustrated in Figure 9.3. Mapping of the ACM BCI parameter to Not-ISUP or Not-SS7 or use of Early ACM may be used in certain cases. If you ticked the check boxes associated with Not-ISUP, Not-SS7 or Early ACM, please supply additional details of the conditions and reasons when Not-ISUP, Not-SS7 or Early ACM is used on separate sheet. Figure 9.4 illustrates the Early ACM option for transit calls. Page 18 PTC331 Form B (Additional ISUP Questionnaire) Figure 9.3 Transparent handling of ACM on Transit Call February 1, 2015 Figure 9.4 Early ACM on Transit Call [NOTE: protocol X=PTC331 ISUP; protocol Y=the internal protocol used by the Other Network] Question 10 (a) BCI Bit I (Ref. PTC331 Part C Section 3.5.2 Bit I) is set to “1” when interworking with a Not-SS7 signalling system (eg. R2MFC) is encountered (b) BCI Bit K (Ref. PTC331 Part C Section 3.5.2 Bit K) is set to “0” when ISUP is not used all the way back from the terminating exchange. The combination Bit K=1 (ISUP) and with I=1 (Not-SS7) is invalid. (c) BCI Bit M (Ref. PTC331 Part C Section 3.5.2 Bit M) indicates whether the call terminates on an ISDN line (Bit M=1) or a Non-ISDN line (ie. PSTN line or not known) (Bit M=0). The setting Bit M=1 is invalid if either Bit I=1 (Not-SS7) or Bit K=0 (Not-ISUP). Question 11 (a) This question is closely related to Question 9 (ref. to Q.9 for detailed explanation) and describes more specifically the Early ACM case when CPG is received after ACM and possibly even after a previous CPG has already been sent (normally occurs with call forwarding services). (b) Please refer to the following ITU Q.764 paragraphs for a complete description: 2.1.4.1 (2) (a) NOTE 2.1.5 “Call progress (basic call)” 2.1.5.1 “Actions required at the destination exchange” 2.1.4.7 “Through connection and awaiting answer indication at the destination exchange” When a call terminates to an ISDN private network and interworking occurs in the private network, the terminating exchange may return a CPG message with “progress” event indicator instead of “alerting” as described in the explanation for part (a) of this question. This signal is mapped from the Q.931 PROGRESS message and the CPG may also carry Access Transport parameter. Non-transit Calls For calls sent from your network to the Spark network, your network should be able to receive the progress signal as described above and through-connect in the backward direction as described in Q.764 section 2.1.4.7 (paragraph 3). If your network supports ISDN and ISDN private network interworking occurs as described above, your network should generate the CPG (with progress event) message. Page 19 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 Transit Calls For transit calls, your network should pass the progress indicator transparently so that the appropriate conditions can be set up across the network and calling party notified via inband tones as to the status of the called party. Question 12 (a) Ref. PTC331 Part C Section 3.12 and 4.14 The Spark network uses symmetrical release procedures (ie. REL message is sent after ANM when called party hangs up first and when calling party hangs up first). The network initiated SUS message is not supported. (b) Please confirm that the following cause values are supported (ie. they can be generated within your network and if received from Spark on a transit call, the cause values will be passed on unchanged) by ticking the appropriate check box. Cause 16 Sent when the calling or called party goes on hook (generally during ringing or after answer). Cause 17 Sent when the called party’s phone is busy Cause 1 Sent when the called party number does not exist (unallocated) in the destination network Cause 18 Sent when no response is received from the terminating ISDN terminal equipment Cause 19 Sent after ringing timeout (No answer from user after the user has been alerted) Cause 21 Sent from some ISDN telephones that have “Do Not Disturb” feature. Cause 27 Sent when the terminating line is out of service (NT or ISDN CPE powered down) Cause 28 Sent when insufficient called party address digits have been received. Cause 34 Sent when there are no circuits available towards the destination exchange Cause 42 Sent when there are no routes available towards the destination exchange Cause 63 Sent when a supplementary service, option or facility has stopped the call from successfully completing (eg. Enhanced Terminating Restrict service, line disconnected due to non payment of bill, etc). Cause 88 & 65 Sent when the call is offered to an incompatible ISDN terminal or destination line/exchange (eg. TMR=64kbit/s call attempted to PSTN line). If your network does not support a particular cause value (and does not send it to Spark), please tick the “Cv not generated” box. However, your network should be able to receive the cause value from Spark and apply an acceptable/appropriate tone to the calling party. On a transit call, the cause value should be passed transparently or mapped to an appropriate cause value. Note that mapping the received cause value to a different value can cause confusion to the caller and is not preferred but exceptions will be considered on a case-by-case basis. (c) Please confirm that your network correctly handles the cause location field including the consistent use of cause location field values sent in REL messages. Based on PTC331 Part C Section 3.12.2 and ITU recommendation Q.850 Section 3, the location where the release is generated is specified in the cause location field in the REL message. (i) This means that if the REL message is generated within your network (and not as a result of receiving a REL on an interconnected circuit of a transit call), the cause location field should be set to “Local network” or “Transit Network” (whichever is applicable). (ii) If the REL message is received from other network on an interconnected circuit of a transit call, the cause location should be set in accordance to the rules shown in Section 3 of Q.850. In the most general circumstance, the cause location may be passed on unchanged by the transit network or converted to a more appropriate cause location as described in Q.850 Section 3. (d) The Spark network always includes the signalling point code parameter (ref. PTC331 Part C Section 3.50) in all REL messages as a method of identifying the exchange responsible for releasing the call. Other Network exchanges are expected to behave the same way, and also to transit the parameter when applicable. Page 20 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 The cause location parameter and the signalling point code parameter are both used by network operations personnel for fault finding and analysis of failed calls when a fault condition is reported or detected. Incorrect coding of these parameters can cause incorrect analysis of fault conditions and lead to extended fault-fix times. (e) The Spark network will include the Automatic Congestion Control (ACL) Parameter in all REL messages if it is in an overloaded condition (Ref. ITU Q.764 Section 2.11 and PTC331 Part C Section 3.4). The parameter is independent of call direction and has significance only to adjacent exchanges, so is not transited. NOTE that the primary ISUP-level congestion control mechanism used in the Spark network is OLM/TTB (see FORM A Question 11 e)), and ACL is sent only if overload persists after OLM/TTB is invoked. Please tick the “Sent....” boxes if your network sends ACL parameter when it becomes overloaded, and tick the “Traffic reduced” boxes if your network reduces traffic to an overloaded Spark exchange on receipt of this parameter as described in ITU Q.764 section 2.11. (f) For calls from the Other Network to Spark, the call may be intercepted by the Spark Intelligent Network before delivered to the terminating line. These calls include 0800, 0900 and calling card calls. In instances where the Intelligent Network service requires to collect information from the calling party before connecting the call, announcements will be used to prompt the calling party to key in DTMF digits. Examples include: Calling card: “Please enter your card number”, “Please enter your PIN”. 0800/0900 HelpDesk or Information Service type numbers: “Please press 1 for Sales, 2 for Faults, etc” For these calls, an ANM may5 be sent prior to prompting and collecting digits from the calling party. The ANM will guarantee that the speech path will be through connected by the terminal equipment or private network equipment that originated the call for successful sending of announcement and receiving of DTMF digits keyed in by the calling party. When the call is subsequently delivered to the terminating exchange, in some cases the called line will be busy. In this case the Spark network will return to the calling party’s exchange a REL message with cause value 17 (user busy) so that the appropriate busy tone can be connected to the calling party’s line. Other NetworkSpark Please confirm that on receiving REL cause 17 after previously receiving ANM your network will correctly apply busy tone to the PSTN calling party. Transit Calls: SparkOther NetworkSpark REL cause 17 should be passed transparently. This will allow the originating exchange to correctly apply busy tone to the calling party’s line. Question 13 The Access Transport Parameter or ATP (Ref. PTC331 Part C Section 3.3) is used to carry signalling information between the ISDN calling and ISDN called parties. ATP is not generated by PSTN originated calls. If sent from an ISDN originated call to a PSTN destination, the ATP should be discarded at the destination exchange. The PTC331 and ITU Recommendation Q.764 Para 2.2.1.1 state that transit exchanges should pass the ATP on transparently. 5 Whether ANM is sent in this situation depends on whether the call is using the User Interactive Dialog procedures (see FORM A Q.10e)). If the UID capability indicators parameter has been received in the IAM, then instead of sending an ANM at this point in the call, the UID action parameter may be sent in the ACM or CPG, requesting that the speechpath be through-connected and timer T9 stopped. The ANM will be sent subsequently if the true called party answers. Page 21 PTC331 Form B (Additional ISUP Questionnaire) February 1, 2015 Question 14 The User-to-User Information parameter or UUI (Ref. PTC331 Part C Section 3.61) is used to transport information directly between the ISDN calling and ISDN called parties. UUI is not generated by PSTN originated calls. If sent from an ISDN originated call to a PSTN destination, the UUI should be discarded at the destination exchange. The PTC331 and ITU Recommendation Q.764 state that transit exchanges should pass the UUI on transparently. Question 15 This question only refers to ISDN user-initiated SUS and RES messages (Ref. PTC331 Part C Section 3.52). These messages are described in PTC331 Part C Sections 4.20 and 4.21. *** Page 22