Call Processing Functions in C#

Reader Quick Response Code in C# Call Processing Functions

Part 2:

initial system access (eg, registration) 1 REGNOT [TRANSCAP=Local SPINI] regnot [SPINIPIN, SPINITriggers] origination [digits=international number] prompt for PIN digits 3 call proceeds 2

Figure 126 An example of local SPINI feature handling by the serving system: (1) The subscriber registers in a local SPINI-capable serving system The HLR provides the subscriber s SPINI PIN and call origination triggers to the serving system (2) The subscriber enters an international phone number and presses the SEND key The call origination to an international destination trigger is set; therefore, the serving system connects the call to a system capable of user interaction (eg, an interactive voice response unit), prompts the subscriber for a PIN, collects the digits entered by the subscriber, and verifies that they match SPINI PIN digits received from the HLR (3) The serving system allows the call origination to proceed

2 Feature control The CNIR feature may be activated or deactivated on a per-call origination basis, using the per-call feature control procedure described in Feature Control Services later in this chapter 3 Feature invocation, such as marking the subscriber s CNI information to indicate the status of the CNIR feature for the call For the purpose of the third function, each of the following ANSI-41 number identification parameters includes a CNIR indicator field (ie, presentation allowed or presentation restricted):

Downloaded from Digital Engineering Library @ McGraw-Hill (wwwdigitalengineeringlibrarycom) Copyright 2004 The McGraw-Hill Companies All rights reserved Any use is subject to the Terms of Use as given at the website

12:

CallingPartyNumberDigits1 CallingPartyNumberDigits2 CallingPartyNumberString1 CallingPartyNumberString2 RedirectingNumberDigits RedirectingNumberString

When the called party is an MS served by a system connected to the subscriber s serving system using ANSI-41, the subscriber s CNI parameters can be conveyed to the serving system by using ANSI-41 messages (see Figure 127); otherwise, a call control protocol with number identification support (eg, the SS7 ISDN user part, ISUP) is required between the subscriber s system and the called party s system to transport the CNI information

Figure 127 Methods of conveying calling number identification (CNI) information: (1) The CNI information can be sent from the originating system (ie, MS-A s serving system) to the terminating system (ie, MS-B s serving system) using ANSI41 parameters in the normal call delivery

call origination [digits] LOCREQ [digits, CNI] ROUTREQ [MS-B ID, CNI] 1 routreq [TLDN] locreq [TLDN] call setup message to TLDN, including CNI

terminating system using an appropriate call control protocol (eg, ISUP)

Finally, ANSI-41 supports a nonstandard (ie, not defined from a stage-1 perspective in ANSI-664) capability whereby a legally authorized called subscriber (eg, an emergency services operator) can override

Downloaded from Digital Engineering Library @ McGraw-Hill (wwwdigitalengineeringlibrarycom) Copyright 2004 The McGraw-Hill Companies All rights reserved Any use is subject to the Terms of Use as given at the website

Part 2:

the calling subscriber s CNIR feature and gain access to the CNI information even when CNIR is activated for the calling subscriber This is referred to as the CNIR override feature

The calling name restriction (CNAR) feature was initially defined in TIA/EIA/IS-764 and will be incorporated in ANSI-41-E This feature allows a subscriber to prevent the presentation of the subscriber s calling name identification (CNA) information to the call-terminating party CNAR is analogous to CNIR in its operation In fact, the CNAR feature control codes may be the same as those of CNIR, allowing the subscriber to turn off both number and name presentation to the called party via a single feature code request

Message-waiting notification (MWN) is not solely a call origination feature; in fact, the MWN feature supports call origination, call termination, and non call-associated notification options For notification at the time of call origination or termination, the MWN pip tone option is used A pip tone consists of an audible tone (ie, four 100-ms bursts of a 480-Hz signal) applied by the serving system on the voice path to the MS when the subscriber attempts to originate or terminate a call The MWN pip tone feature may be deactivated on a per-call origination basis by using the per-call feature control procedure; this capability can be used to ensure that a modem-driven data call is not interrupted by the pip tone There are two options for notification when the MS is idle (ie, not involved in a call):

An alert pip tone nominally consisting of the same four signal bursts as the pip tone, but generated by an audible annunciator in the MS under the command of the serving system A message-waiting indication on the MS it may be a simple message-waiting lamp or a digital display of the number of messages waiting for retrieval that is driven based on signaling messages from the serving system

Downloaded from Digital Engineering Library @ McGraw-Hill (wwwdigitalengineeringlibrarycom) Copyright 2004 The McGraw-Hill Companies All rights reserved Any use is subject to the Terms of Use as given at the website