(Page 1 of 1 in this chapter) Version

Chapter 7

DPNSS Supplementary Feature Descriptions

7.1 Introduction
7.2 About DPNSS Connection States
7.3 Call Diversion Immediate and Busy
7.3.1 Call Diversion (Immediate/Busy) to Another PBX
7.3.2 Call Diversion (Immediate/Busy) on the Same PBX
7.4 Call Diversion on Ring No Reply
7.4.1 Call Diversion (RNR) to Another PBX
7.4.2 Call Diversion on the Same PBX
7.4.3 Diversion Validation
7.5 Call Hold
7.6 Enquiry Call
7.7 Call Transfer
7.7.1 Transit Working
7.8 Add-On/Conference
7.9 Executive Intrusion
7.9.1 Intrusion Without Prior Validation
7.9.2 Intrusion With Prior Validation
7.9.3 Intrusion Withdrawal
7.10 Non-Specified Information (NSI)
7.11 Text
7.12 Trunk ID (TID)

7.1 Introduction

This chapter explains how the supported DPNSS supplementary features are implemented in the CT Access DPNSS service, and how they affect the DPNSS connection state of a call.

The full specification for each of these features is given in the official BT Network Requirement (BTNR) 188 documents, issue 6, January, 1995. This chapter does not attempt to describe the features fully. Instead, it describes how each of these features is implemented within the CT Access DPNSS service.

7.2 About DPNSS Connection States

When a call is connected and certain supplementary features are active, the call enters one of several auxiliary states, called DPNSS connection states. The DPNSS connection state can change according to the DPNSS feature message content exchanged. The DPNSS supplementary features that can affect a call's DPNSS connection state are:

The application can determine the DPNSS connection state by calling dpnGetCallStatus. The DPN_CALL_STATUS structure returned by this function contains the DPNSS connection state, in the dpnconstate field. (For more information about this function, see Chapter 5.) If the call is not connected, the value of this field is identical to the call state given in the state field in the structure. If the state of the call is Connected and one of the DPNSS features mentioned above is activated, dpnconstate can be any one of the following:

The states are described in the following sections.

7.3 Call Diversion Immediate and Busy

Call diversion immediate and busy are available for incoming and outgoing calls. A diversion can be performed to the same PBX or to another PBX. See BTNR 188 Sections 11.1 and 11.2.

In the following sections, call diversion immediate and busy is described from the perspectives of three different types of applications:

7.3.1 Call Diversion (Immediate/Busy) to Another PBX

This section describes how a diverting application on one PBX directs an originating application on another PBX to divert a call to yet another PBX, because the original call destination was busy or set up to divert all calls automatically.

Figure 15 illustrates the sequence of function calls and events that pass between the different PBX applications in this situation.

Originating Application Perspective

When a remote application requests that a call be diverted, the DPNSS service at the originating PBX receives a DPNEVN_REMOTE_ALERTING event with a DPNSIS_DIVERT_IMM or DPNSIS_DIVERT_BSY SIS identifier. When the originating PBX receives this event, it clears the call, and sends a DPNEVN_CALL_DISCONNECTED event to the originating application. The DPN_RECEIVED_SIS list returned with the event contains:

sisid: DPNSIS_DIVERT_IMM or DPNSIS_DIVERT_BSY
(sisparam: The number of the party the call is to be diverted to.)



The originating application can then try to contact the new number. It must notify the new number that the call has been diverted. To do so, the application sets up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_DIVERTING_IMM or DPNSIS_DIVERTING_BSY
(sisparam: The number of the party the call has been diverted from.)


The originating application then places the call using dpnPlaceCall. The SIS identifier is sent with this function call.


 Diverting Application Perspective



To instruct an incoming call to divert on busy or divert immediate, the diverting application sets up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_DIVERT_IMM or DPNSIS_DIVERT_BSY 
(sisparam: The number of the party the call is to be diverted to.)


The diverting application then accepts the call using dpnAcceptCall. The SIS identifier is sent with this function call.



When the remote application receives this message, it clears the call.


 Divert-to Application Perspective



When an application receives a call diverted from elsewhere, it receives the following DPN_RECEIVED_SIS list returned with the DPNEVN_INCOMING_CALL event:


sisid: DPNSIS_DIVERTING_IMM or DPNSIS_DIVERTING_BSY
(sisparam: The number of the party the call has been diverted from.)


Figure 15 illustrates the sequence of function calls and events that pass between the different PBX applications during a Call Diversion operation (Immediate or Busy) to another PBX.





Figure 15.	 Call Diversion (Immediate/Busy) to Another PBX






7.3.2	 Call Diversion (Immediate/Busy) on the Same PBX





This section describes the case where both the diverting user and the divert-to user are on the same PBX. In this case, the diverting application need only inform the originating application that the call has been diverted.



Figure 16 illustrates the sequence of function calls and events that pass between the different PBX applications in this situation.


 Originating Application Perspective



When a remote application has diverted a call to another user on the same PBX, a DPNEVN_REMOTE_ALERTING event is returned to the originating application. The DPN_RECEIVED_SIS list returned with the event contains:


sisid: DPNSIS_DIVERTED_IMM or DPNSIS_DIVERTED_BSY 
(sisparam: The number of the party the call has been diverted to.)

 Diverting/Divert-to Application Perspective




To inform a remote application of an on-PBX diversion, the application sets up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_DIVERTED_IMM or DPNSIS_DIVERTED_BSY 
(sisparam: The number of the party the call has been diverted to.)


The application then accepts the call using dpnAcceptCall. The SIS identifier is sent with this function call.



Figure 16 illustrates the sequence of function calls and events that pass between the different PBX applications during a Call Diversion operation (Immediate or Busy) on the same PBX.





Figure 16.	 Call Diversion (Immediate/Busy) on Same PBX






7.4	 Call Diversion on Ring No Reply





Ring No Reply (RNR) diversion is available for both incoming and outgoing calls. See BTNR 188 Section 11.3.



In the following sections, call diversion (RNR) is described from the perspectives of three different types of applications:






7.4.1	 Call Diversion (RNR) to Another PBX





This section describes how a diverting application on one PBX directs an originating application on another PBX to divert a call to yet another PBX, because the original call destination did not pick up the call.



Figure 17 illustrates the sequence of function calls and events that pass between the different PBX applications in this situation.


 Originating Application Perspective



When a remote application requests that a call be diverted, the DPNSS service at the originating PBX receives a DPN_INCOMING_INFO event with:


sisid: DPNSIS_DIVERT_RNR 
(sisparam: The number of the party the call is to be diverted to.)


The originating application may choose either of the following:




When the originating application tries to contact the new number, it must notify the new number that the call has been diverted. To do so, the originating application sets up the following SIS identifier, using dpnSetExtendedArgs:


sisid: DPNSIS_DIVERTING_RNR 
(sisparam: The number of the party the call has been diverted from.)


The originating application then places the call using dpnPlaceCall. The SIS identifier is sent with this function call.


 Diverting Application Perspective



To instruct an incoming call to RNR divert to another PBX, the diverting application first accepts the call using dpnAcceptCall. It then sets up the following SIS identifier, using dpnSetExtendedArgs:


sisid: DPNSIS_DIVERT_RNR 
(sisparam: The number of the party the call is to be diverted to.)


The diverting application then calls dpnSendFeatureMessage. The SIS identifier is sent with this function call.



If the diversion is successful, the originating application clears the call.



RNR diversion should only take place following dpnAcceptCall and before call connection is performed using dpnAnswerCall.


 Divert-to Application Perspective



When an application receives a call diverted from elsewhere, it receives the following DPN_RECEIVED_SIS list returned with the DPNEVN_INCOMING_CALL event:


sisid: DPNSIS_DIVERTING_RNR 
(sisparam: The number of the party the call has been diverted from.)


Figure 17 illustrates the sequence of function calls and events that pass between the different PBX applications during a Call Diversion operation (Ring-No-Reply) to another PBX.





Figure 17.	 Call Diversion (Ring-No-Reply) to Another PBX






7.4.2	 Call Diversion on the Same PBX 





This section describes the case where both the diverting user and the divert-to user are on the same PBX. In this case, the diverting application need only inform the originating application that the call has been diverted.



Figure 18 illustrates the sequence of function calls and events that pass between the different PBX applications in this situation.


 Originating Application Perspective



When a remote application has diverted a call to another user on its PBX, a DPNEVN_INCOMING_INFO event is returned to the originating application. The DPN_RECEIVED_SIS list returned with the event contains:


sisid: DPNSIS_DIVERTED_RNR 
(sisparam: The number of the party the call has been diverted to.)

 Diverting/Divert-to Application Perspective




To inform the remote application of an on-PBX diversion, the application first accepts the call using dpnAcceptCall. It then sets up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_DIVERTED_RNR 
(sisparam: The number of the party the call has been diverted to.)


The application then sends the message using dpnSendFeatureMessage.



Figure 18 illustrates the sequence of function calls and events that pass between the different PBX applications during a Call Diversion (Ring-No-Reply) on the same PBX.





Figure 18.	 Call Diversion (Ring-No-Reply) on Same PBX






7.4.3	 Diversion Validation





Diversion validation is available for both incoming and outgoing calls. Diversion validation should only be used with virtual calls. See BTNR 188 Section 11.



In the following sections, diversion validation is described from the perspectives of the following types of applications:




To generate a diversion validation request, an application sets up the following the SIS identifier, using dpnSetExtendedArgs:


sisid: DPNSIS_DIV_VALIDATION 
(sisparam: none.)


The originating application then calls dpnPlaceCall. The SIS identifier is set with this function call.



The remote application responds by clearing the call. The originating application receives one of the following SIS identifiers with a DPNEVN_CALL_DISCONNECTED event:


sisid: DPNSIS_MSG_ACK, to acknowledge validation 
(sisparam: none.)

- OR -

sisid: DPNSIS_MSG_REJECT, to reject validation 
(sisparam: none.)


If the remote application did not understand the request, the sisid field will contain neither the acknowledge or the rejection SIS identifier.


 Granting/Denying Application Perspective



When a diversion validation request is detected, the remote application receives the DPNSIS_DIV_VALIDATION SIS identifier with a DPNEVN_INCOMING_CALL event or DPNEVN_INCOMING_INFO event. The remote application must respond to a diversion validation request by setting one of the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_MSG_ACK, to acknowledge validation 
(sisparam: none.)

- OR -

sisid: DPNSIS_MSG_REJECT, to reject validation
(sisparam: none.)


The remote application then clears the call using dpnRejectCall. The SIS identifier is sent with this function call.






7.5	 Call Hold





Call hold may be initiated by the application or remote party. See BTNR 188 Section 12.



In the following section, call hold is described from the perspectives of the following types of applications:




Figure 19 illustrates putting a call on hold.


 Initiating Application Perspective



Call hold may only be initiated on a call if the call is in the Connected state. 



To initiate a call hold request, the application sets up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_HOLD_REQ
(sisparam: none.)


The application then calls dpnSendFeatureMessage. The SIS identifier is sent with this function call.



The application receives the response with a DPNEVN_INCOMING_INFO event. The DPNSIS_RECEIVED_SIS list returned with the event contains:


sisid: DPNSIS_HOLD_ACK 
(sisparam: none.)

- OR -

sisid: DPNSIS_HOLD_REJECT 
(sisparam: none.)


If Call Hold is not supported at the remote PBX, the following is returned:


sisid: DPNSIS_HOLD_NOT_SUPPORTED
(sisparam: none.)


If the hold request was accepted, the DPNSS connection state (dpnconstate within the DPN_CALL_STATUS structure) becomes DPN_CONSTATE_HOLDING. The call remains in this state until the application requests reconnection, or the holding or held party clears. 



To reconnect the held party, the initiating application sets up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_RECONNECT
(sisparam: none.)


The application then calls dpnSendFeatureMessage. The SIS identifier is sent with this function call.



If either party clears, normal call clearing applies.


 Granting/Denying Application Perspective



Call hold may only be initiated on a call if the call is in the Connected state. 



When a remote call hold request is received, the application receives a DPNEVN_INCOMING_INFO event. The DPN_RECEIVED_SIS list returned with the event contains:


sisid: DPNSIS_HOLD_REQ 
(sisparam: none.)


The application must respond to the request by setting up the following SIS identifiers:


sisid: DPNSIS_HOLD_ACK 
(sisparam: none.)

- OR -

sisid: DPNSIS_HOLD_REJECT 
(sisparam: none.)


The application then calls dpnSendFeatureMessage. The SIS identifier is sent with this function call.



If a hold request is acknowledged, the call enters DPNSS connection state DPN_CONSTATE_HELD. The call remainPlural thatheld until either party clears or the remote party instructs the application to reconnect. 



If the remote party requests reconnection, the application receives a DPNEVN_INCOMING_INFO event. The DPN_RECEIVED_SIS list returned with the event contains:


sisid: DPNSIS_RECONNECT
(sisparam: none.)


When the application receives this message, the application should reconnect its party to the traffic channel. 



If either party clears, normal call clearing applies.



Figure 19 illustrates putting a call on hold.





Figure 19.	 Call Hold






7.6	 Enquiry Call 





Enquiry call is supported for both incoming and outgoing calls. See BTNR 188 Section 13.



In the following section, call enquiry is described from the perspectives of the following types of applications:




Figure 21 illustrates establishing an enquiry call prior to performing a call transfer.


 Initiating Application Perspective



To make an enquiry call, the application must set up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_ENQUIRY
(sisparam: Calling Line Category of the held party.)


The application then establishes an outgoing call using dpnPlaceCall. The SIS identifier is set with this function call.


 Enquired Application Perspective



If an incoming call is an enquiry call, the application receives a DPNEVN_INCOMING_CALL event, with a DPN_RECEIVED_SIS list containing:


sisid: DPNSIS_ENQUIRY
(sisparam: Calling Line Category of the held party.)




7.7	 Call Transfer





Call transfer is supported by the NMS DPNSS service. See BTNR 188 Section 13.



In the following sections, call transfer is described from the perspectives of three different types of applications:




Figure 21 illustrates transferring a party.


 Controlling Application Perspective



Application-controlled call transfer uses two DPNSS channels. To perform a transfer, the application must first:




To initiate call transfer, the application sets up the following SIS identifiers to send to the original party, using dpnSetExtendedArgs:


sisid: DPNSIS_TRANSFER_O or DPNSIS_TRANSFER_T, to designate a party as the new originating or terminating party
(sisparam: none.)

sisid: DPNSIS_RECONNECT, to reconnect the held party
(sisparam: none.)


The application then calls dpnSendFeatureMessage, to send the message to the original party. If the function succeeds, the DPNSS connection state enters DPN_CONSTATE_TRANSIT.



The application also sets up the following SIS identifiers to send to the new party, using dpnSetExtendedArgs:


sisid: DPNSIS_TRANSFER_O or DPNSIS_TRANSFER_T, to designate a party as the new originating or terminating party. Note that this sisid must be the opposite of that sent to the original party (e.g., if the original party was sent DPNSIS_TRANSFER_O, the new party must be sent DPNSIS_TRANSFER_T).
(sisparam: none.)

sisid: DPNSIS_CLC_xxx, indicating the Calling Line Category of the original party
(sisparam: none.)

sisid: DPNSIS_CLI
(sisparam: Calling Line ID of the original party.)


The application then calls dpnSendFeatureMessage, to send the message to the new party. 



Following a call transfer, the DPNSS connection state becomes DPN_CONSTATE_TRANSIT. The application now serves as a message router, passing messages sent from one remote party to the other without acting on the message contents. The application must now call dpnSetTransitActive to relegate this message passing activity to the DPNSS service level (see Section 7.7.1).


 Original-Party Application Perspective



To transfer a call to the original party, the controlling application first places the original party on hold. When the transfer is complete, the original party application receives a DPNEVN_INCOMING_INFO event. The DPN_RECEIVED_SIS list returned with the event contains:


sisid: DPN_TRANSFERRED
(sisparam: none.)

sisid: DPNSIS_RECONNECT, reconnecting the held party
(sisparam: none.)


The original party returns to a normal call control state.



Subsequently, the original party receives another DPN_INCOMING_INFO with DPNSIS_TRANSFERRED_INFO, followed by DPN_SIS_CLI and DPN_SIS_CLC_xxx indicating the calling line category of the new party. This information is sent automatically by the new party's PBX.


 New-Party Application Perspective



To transfer a call to the new party, the controlling application first places an enquiry call to the new party. Then the application receives a DPNEVN_INCOMING_INFO event. The DPN_RECEIVED_SIS list returned with the event contains:


sisid: DPNSIS_TRANSFERRED
(sisparam: none.)


Subsequently, the new party receives another DPN_INCOMING_INFO with DPNSIS_TRANSFERRED_INFO followed by DPN_SIS_CLI and DPN_SIS_CLC_xxx indicating the calling line information for the original party. This information is sent automatically by the original party's PBX.






7.7.1	 Transit Working 





Transit working is a requirement of BTNR 188. Following certain call scenarios (such as call transfer), the local must serve as a message router between two remote parties, passing messages sent from one remote party to the other without acting on the message contents. This role is called transit working.



When appropriate, the controlling application must request the DPNSS service to perform this message routing. Once transit working has been established at the DPNSS service level, all messages from one party are redirected to the other without requiring any action from the application. (See Figure 20.)



Once the DPNSS service is in transit working mode, it can pass messages from one party to another even if the messages are not recognized by the controlling party software. For example, messages such as Route Optimization are normally rejected by the controlling application's signaling software, as this feature is not directly supported by the DPNSS service. However, if the service is acting as a transit node between two transferred calls, the Route Optimization messaging is simply passed between the two parties via the DPNSS service. The messages are only relevant to the two end PBXs and not the transit PBX.



To request the DPNSS service to enter transit mode, the controlling application calls dpnSetTransitActive with the CTA handles (ctahd) of the two remote parties. Note that the two CTA handles must have been created on the same queue. This function associates the two parties' channels, and causes the server to begin transit working.



Once the service has entered transit working mode, the DPNSS connection state changes to DPN_CONSTATE_TRANSIT_ACTIVE. The call remains in this state until the call has been cleared either by the application or one of the two end parties. After a call has been placed in DPN_CONSTATE_TRANSIT_ACTIVE, the only call control function you can use on that call is dpnReleaseCall. 



Note that the application can direct the DPNSS service to enter transit working mode at any time, following a call transfer or any other operation.



Figure 20 illustrates transit working.





Figure 20.	 Transit Working




Figure 21 illustrates transferring a party.





Figure 21.	 Call Transfer






7.8	 Add-On/Conference 





Following establishment of an enquiry call, the application may form a conference. Refer to BTNR 188 Section 13 Subsection 2.3.9.



In the following sections, Add-On/Conference is described from the perspectives of two different types of applications:




Figure 22 illustrates adding on a party to form a conference. 


 Controlling Application Perspective



To create a conference, the application must first establish an enquiry call to the third party (as described in Section 7.6). The enquiry call must be in Alerting or Connected state. 



To establish a conference, the controlling application sends an Add On request to both remote parties. The application initiates each Add On request by setting up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_ADD_ON_VALIDATION
(sisparam: none.) 


The application then calls dpnSendFeatureMessage. The SIS identifier is sent with this function call.



If a remote party permits conferencing, the application receives a DPNSIS_INCOMING_INFO event with the following SIS identifiers:


sisid: DPNSIS_ADD_ON_ACK
(sisparam: none.)

sisid: DPNSIS_CLC_xxx, indicating the Calling Line Category of the original party
(sisparam: none.)

sisid: DPNSIS_CLI
(sisparam: Calling Line ID of the original party.)


The application may proceed to form a three party conference. 



If the application instead receives DPNSIS_ADD_ON_REJECT, the remote PBX has rejected the Add On request. The application must abandon conference establishment. If the application receives DPNSIS_ADD_ON_NOT_ SUPPORTED, the remote PBX does not support call conference. The application must abandon conference establishment. If the application receives no response at all within a given time (suggested 5 seconds), it should abandon conference establishment. Timer maintenance is the responsibility of the application.



If the application is permitted to form the three party conference, it informs both remote parties of Conference establishment by setting up the following SIS identifiers, using dpnSetExtendedArgs:


sisid: DPNSIS_ADDED_ON
(sisparam: none.) 


The application then calls dpnSendFeatureMessage once for each remote party. The SIS identifier is sent with each function call.


Note:  It is the application's responsibility to provide the relevant voice channel switching during call conferencing.


In DPNSS connection state DPN_CONSTATE_CONFERENCE, the application may send any of the following SIS identifiers:




  • DPNSIS_ADD_ON_CLEARDOWN - Requests all parties involved in the 
conference to clear down. On receiving this request, the remote PBX 
initiates call clearing. (Refer to BTNR 188 Section 13 Subsection 2.3.12.)

    

    

    If the application simply wishes to clear from the conference, it can call dpnReleaseCall.
    

 Remote Party Application Perspective
    


    To create a conference:
    

    

    Each remote party application then receives a DPNEVN_INCOMING_INFO event. The DPN_RECEIVED_SIS list returned with the event contains:
    

sisid: DPNSIS_ADD_ON_VALIDATION
    (sisparam: none.) 
    

    To validate the add-on request, a remote party application sets up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_ADD_ON_ACK
    (sisparam: none.)
    
sisid: DPNSIS_CLC_xxx, indicating the Calling Line Category of the party
    (sisparam: none.)
    
sisid: DPNSIS_CLI
    (sisparam: Calling Line ID of the party.)
    

    The application then calls dpnSendFeatureMessage.
    


    A remote party application can instead send DPNSIS_ADD_ON_REJECT to reject the Add On request, or send DPNSIS_ADD_ON_NOT_ SUPPORTED to indicate that it does not support call conference. If the controlling application receives either of these messages, or does not receive any response at all within a given time (suggested 5 seconds), it abandons conference establishment. 
    


    If the conference is permitted by both remote parties, each remote party application then receives a DPNEVN_INCOMING_INFO event. The DPN_RECEIVED_SIS list returned with the event contains:
    

sisid: DPNSIS_ADDED_ON
    (sisparam: none.) 
    
(The remote party application on hold also receives a DPNSIS_RECONNECT SIS identifier, that releases it from hold.)
    

    At this point, each remote party enters DPN_CONSTATE_CONFERENCE.
    


    In DPNSS connection state DPN_CONSTATE_CONFERENCE, the application may receive the following SIS identifiers:
    

    

  • DPNSIS_ADD_ON_CLEARDOWN - The controlling application is 
requesting all parties involved in the conference to clear down. On 
receiving this request the remote party should initiate call clearing. (Refer to 
BTNR 188 Section 13 Subsection 2.3.12.)

    

    

    Figure 22 illustrates adding on a party to form a conference. 
    




    Figure 22.	 Adding on a Party to Form a Conference
    

    



    Figure 23.	 A Party Leaves a Conference
    

    • 

    

    7.9	 Executive Intrusion
    

    


    The NMS DPNSS service supports the Executive Intrusion supplementary service: the ability for a user with sufficient clearance to interrupt, or intrude upon an existing active call. Refer to BTNR 188 Section 10.
    


    In the following sections, the Executive Intrusion feature is described from the perspectives of three different types of applications:
    

    

    In DPNSS, each user is given two values, which determine the user's Executive Intrusion capabilities:
    

    

    To successfully intrude on an existing active call, a user's ICL must be greater than the IPL numbers of both the wanted party and the unwanted party. The wanted party application performs this comparison, called the intrusion validation. Intrusion validation can take place in either of two situations:
    

    

    

    7.9.1	 Intrusion Without Prior Validation
    

    


    When an application placing a call receives a busy signal, it can attempt to intrude on the active call. Refer to BTNR 188 Section 10 Subsection 2.3.1.
    


    Figure 24 illustrates Executive Intrusion without prior validation.
    

 Intruding Application Perspective
    


    If an application encounters a busy remote party when establishing an outbound call, the application can request Executive Intrusion. The application initiates an intrusion request by setting up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_INTRUSION_REQ
    (sisparam: the Intrusion Capability Level of the intruding party.)
    
sisid: DPNSIS_CLI
    (sisparam: the address of the requesting party.)
    

    The application then places the call using dpnPlaceCall. The SIS identifier is sent with this function call.
    


    In response to the intrusion request the application will receive one of the following events:
    

    

    If the application receives DPNEVN_REMOTE_ALERTING with sisid DPNSIS_INTRUSION_ACK (as described above), it can expect one of the following SIS identifiers:
    

    

    Once intrusion is active, the intruding party may withdraw, or the wanted party may clear. If the wanted party clears and is subsequently called by the remote PBX, the application is sent feature message DPNSIS_STATE_OF_DEST_FREE. In this case, the call continues as regular call, waiting for remote party to answer. 
    

 Wanted Party Application Perspective
    


    When a remote party requests Executive Intrusion, the application receives a DPNEVN_INCOMING_CALL event with the following DPN_RECEIVED_SIS list:
    

sisid: DPNSIS_INTRUSION_REQ
    (sisparam: the Intrusion Capability Level of the intruding party.)
    
sisid: DPNSIS_CLI
    (sisparam: the address of the requesting party.)
    

    When the application receives such request, it first determines the Intrusion Protection Level of the party it is currently connected to (the "unwanted" party). To do so, it sets up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_IPL_REQ
    (sisparam: none.)
    

    The application then calls dpnSendFeatureMessage. The SIS identifier is sent with this function call.
    


    The unwanted party application responds with a DPNEVN_INCOMING_INFO event with the following DPN_RECEIVED_SIS list:
    

sisid: DPNSIS_IPL_RSP
    (sisparam: the Intrusion Protection Level of the "unwanted" party.)
    

    The application compares the ICL number of the intruding party with the IPL numbers of the wanted and unwanted parties. Intrusion should be permitted only if the ICL is greater than both IPLs.
    


    The wanted party application informs the intruding application of the outcome of the intrusion request in one of the following ways:
    

    

    If the application elects to acknowledge the intrusion request (as described above), the application then does either of the following:
    

    

    Once the intruding party is connected to the wanted party, the intruding party may request withdrawal, or the wanted party may hang up.
    

 Unwanted Party Application Perspective
    


    If a third party wishes to intrude on a remote party connected to the application via DPNSS, the application will be requested to provide its Intrusion Protection Level. The application's Intrusion Protection Level is used by the remote PBX to determine if intrusion can proceed. An Intrusion Protection Level Request will only be received when an application controlled call is connected to a remote party.
    


    When an Intrusion Protection Level request is received, the application receives a DPNEVN_INCOMING_INFO event. The DPN_RECEIVED_SIS list returned with the event contains:
    

sisid: DPNSIS_IPL_REQ
    (sisparam: none.)
    

    At this point, the unwanted party application can:
    

    

    To respond with IPL information, the application sets up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_IPL_RSP
    (sisparam: the protection level of the application's party.)
    

    The application then calls dpnSendFeatureMessage. The IPL information is sent with this function call.
    


    Figure 24 illustrates Executive Intrusion without prior validation.
    




    Figure 24.	 Executive Intrusion without Prior Validation
    

    

    

    7.9.2	 Intrusion With Prior Validation
    

    


    An application can optionally include intrusion validation information when it first places a call. In this case, if the wanted party is busy, the wanted party application automatically indicates whether intrusion is possible or not. Refer to BTNR 188 Section 10 Subsection 2.3.2.
    


    Figure 25 illustrates Executive Intrusion with prior validation.
    

 Intruding Application Perspective
    


    To request intrusion validation at call setup, the application first sets up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_PV_INTRUSION
    (sisparam: the Intrusion Capability Level of the application's party.) 
    

    The application then places the call using dpnPlaceCall. The SIS identifier is sent with this function call.
    


    The application may then receive one of the following events:
    

    

    If the application receives DPNEVN_REMOTE_ALERTING with sisid DPNSIS_INTRUSION_ACK (as described above), it can request intrusion. To do so, it sets up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_INTRUSION_REQ
    (sisparam: the Intrusion Capability Level of the intruding party.)
    

    The application then calls dpnSendFeatureMessage. The SIS identifier is sent with this function call.
    


    In response to the intrusion request, the application will receive one of the following responses:
    

    

    When a remote party requests intrusion validation on call setup, the wanted party application receives a DPNEVN_INCOMING_CALL event with the following DPN_RECEIVED_SIS list:
    

sisid: DPNSIS_PV_INTRUSION
    (sisparam: the Intrusion Capability Level of the application's party.) 
    

    When the application receives such request, it first determines the Intrusion Protection Level of the party it is currently connected to (the "unwanted" party). To do so, it sets up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_IPL_REQ
    (sisparam: none.)
    

    The application then calls dpnSendFeatureMessage. The SIS identifier is sent with this function call.
    


    The unwanted party application responds with a DPNEVN_INCOMING_INFO event with the following DPN_RECEIVED_SIS list:
    

sisid: DPNSIS_IPL_RSP
    (sisparam: the Intrusion Protection Level of the "unwanted" party.)
    

    The application compares the ICL number of the intruding party with the IPL numbers of the wanted and unwanted parties. Intrusion should be permitted only if the ICL is greater than both IPLs.
    


    The wanted party application informs the intruding application of the outcome of the intrusion request in one of the following ways:
    

    

    If a third party wishes to intrude on a remote party connected to the application via DPNSS, the application will be requested to provide its Intrusion Protection Level. The application's Intrusion Protection Level is used by the remote PBX to determine if intrusion can proceed. An Intrusion Protection Level Request will only be received when an application controlled call is connected to a remote party.
    


    When an Intrusion Protection Level request is received, the application receives a DPNEVN_INCOMING_INFO event. The DPN_RECEIVED_SIS list returned with the event contains:
    

sisid: DPNSIS_IPL_REQ
    (sisparam: none.)
    

    At this point, the unwanted party application can:
    

    

    To respond with IPL information, the application sets up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_IPL_RSP
    (sisparam: the protection level of the application's party.)
    

    The application then calls dpnSendFeatureMessage. The IPL information is sent with this function call.
    


    Figure 25 illustrates Executive Intrusion with prior validation.
    




    Figure 25.	 Executive Intrusion with Prior Validation
    

    

    

    7.9.3	 Intrusion Withdrawal
    

    


    And intruding application may temporarily withdraw from intrusion without clearing the call. Refer to BTNR 188 Section 10 Subsection 2.3.3. 
    


    Figure 26 illustrates Executive Intrusion withdrawal.
    

 Intruding Application Perspective
    


    To invoke an intrusion withdrawal, the intruding application sets up the following SIS identifiers, using dpnSetExtendedArgs:
    

sisid: DPNSIS_INTRUSION_WITHDRAW
    (sisparam: none.)
    

    The application then calls dpnSendFeatureMessage. The SIS identifiers are sent with this function call.
    


    The intruding application receives a DPNSIS_INCOMING_INFO event, with one of the following SIS identifiers:
    

    

    If the intruding application withdraws successfully, it can later re-enter intrusion by calling dpnSendFeatureMessage with the following SIS identifiers:
    

sisid: DPNSIS_INTRUSION_REQ
    (sisparam: the Intrusion Capability Level of the Intruding party.)
    
 Unwanted Party Application Perspective
    

    

    The unwanted party application is not involved in executive withdrawal.
    


    Figure 26 illustrates Executive Intrusion withdrawal.
    




    Figure 26.	 Executive Intrusion Withdrawal
    

    

    

    7.10	 Non-Specified Information (NSI) 
    

    


    At any point during a call the application or remote party may generate Non- Specified Information (DPNSIS_NSI) as defined in BTNR 188 Section 15. sisparam sent with this identifier is an array of IA5 characters with the following format:
    


    suffix*Nsi_Id*Nsi_string
    

    

    For example, the following string:
    


    Z*C*NSI STRING
    


    ... has this meaning:
    

    

    

    7.11	 Text
    

    


    Text may be sent and received at any point during a call. (Refer to BTNR 188 Section 16.) Text is sent and received using the DPNSIS_TEXT identifier. sisparam sent with this identifier consists of the text to be sent or received, and a parameter indicating the string type. This information is formatted as follows:
    


    string*txt_type
    

    

    For example, the following string:
    


    NMS*1
    


    ... has this meaning:
    

    

    This is valid for both incoming and outgoing text messages.
    

    

    

    7.12	 Trunk ID (TID) 
    

    


    To identify a trunk, the DPNSIS_TID identifier is used in conjunction with DPNSIS_CLC_xxx. (Refer to BTNR 188 Section 16.) sisparam sent with the DPNSIS_TID identifier consists of a PBX ID, a trunk group ID, and a trunk member ID. This information is formatted as follows:
    


    PBX_ID*group_ID*member_ID
    

    

    For example, to send PBX identifier "1", trunk group identifier "2", and trunk member "3" the sisparam sent with DPNSIS_TID would be:
    


    1*2*3
    


    This is valid for both incoming and outgoing calls.
    

    

    


    
 
    (Page 1 of 1 in this chapter)  Version
    


    
 



    
tech_support@nmss.com

    

Copyright © 1999, Natural MicroSystems, Inc.   All rights
reserved.