Call Suppression (L2 resilience conflict)

Call Suppression (L2 resilience conflict)

Background 

Scenario occurs when using L2 resilience and Call Suppression features:

1.    Duplicate calls, call1 and call2, are being processed.
2.    A user makes an API request to call2 to suppress the call.
3.    call2 is suppressed, call1 is not.

  • When an API request is used to suppress a call, the calling application should not need to have knowledge that this call is being recorded in duplicate but both calls should be treated identically


Feature Description

This is a bug fix for the Call Suppression feature on the future platform  

Business Case Summary

  • Currently when duplicate calls captured from a collector pair (L2 resilience ) are processed for deduplication, If the user has made a call suppression request to suppress parts of a calls captured by the collector pair; after deduplication the same call captured from one of the pair of collectors will not be suppressed could be retained and not discarded. Therefore we need a solution that ensures calls captured are suppressed upon a suppression request by the user after the deduplication process. 


1.

Use Case Title:
[L2 and Suppression conflict]
Description To ensure the user's suppression request on call is achieved during the deduplication process for PCI DSS compliance(Payment Card Industry Data Security Standard).  
Trigger Customer triggers request to suppress a  call.
Primary Actors (Personas)


Secondary Actors 
Stakeholders 


Preconditions 
  1. User has suppression permissions 
  2. Device is enabled for suppression
Flow (Main success Scenario)


  • User makes a suppression request to suppress parts of a call captured by L2 resilience 
  • Suppression API receives the suppression request 
  • Suppression request is then processed 
Alternative flowsN/A
Post-conditions 

Post-Call: Call is captured by collector pair (L2 resilience)

  1. Success End condition
    • During deduplication call captured by:
      -Both calls are suppressed (So calls captured by the L2 resilience are suppressed 
      by the system)

  2. Failure End condition:
    • Assumptions: We assume the solution will not produce a failure event because based on the logic. However possible errors due to enhanced exceptions in code which will be picked up during QA. 
Frequency 

Dependent on customer request

Priority MUST have 
Technical SpecificationCall Suppression - tech spec#techspec-L2resilienceandsuppression


ASSUMPTIONS

  • We have assumed that Non-functional requirements will be the same as the Call Suppression feature.   


Add label