• Type your task here, using "@" to assign to a user and "//" to select a due date

User Story

In India, law agencies should have a secure remote access to enable and disable LI on any account at their will and on a real-time basis. Service providers should not even be aware if the LI is enabled for any of their subscribers at all.

Big operators already implemented LI on their end and allow smaller service providers to send calls to their network where these calls may be intercepted by law enforcement agencies so that smaller service providers do not even have to store LI recordings on their hardware.

Ultimately, the LI requirement is applicable to all calls - both on-net and off-net. Therefore, the customer needs a possibility to route on-net calls to a certain vendor ('trusted third party') who will return calls to the customer's network if a destination matches one of the customer's accounts/numbers. Such on-net calls must have an identifier that would be used by a vendor to return these calls back to the service provider.

Use Cases

Use case #1: Enabling routing for on-net calls

Roles: Administrator

Preconditions: There is Vendor MTNL that has two connections:

'To Vendor via SIP' - 98.77.66.80

'From Vendor via SIP' - 98.77.66.80

MTNL equipment is able to accept the SIP header and route calls with this header accordingly

Use scenario #1.1: Allow routing for on-net calls

  • Admin enables the system to route on-net calls to remote vendors

  • Admin enables the SIP header to be generated for on-net calls

Use case #2: Handling on-net calls

Roles: Users, System, Vendor

Preconditions: There is a routing plan which sets static routing for all outbound calls to a single vendor connection

Vendor equipment is able to accept the SIP header and route calls with this header

There are customers in the system:

'John Doe' with accounts 91222333444 (ext 100), 91222333555 (ext 200)

'Alpha Bank' with account 91222000666 which operates an auto-attendant

'Alice Smith' (under Reseller ABC) with account 91999777000

'Smart Insurance' with account 201.10.15.27

There is 'Internal Conference' IVR with access number *900

Use scenario #2.1: Calls within same IP Centrex environment

  • Continued after #1

  • Mike (91222333444 = ext 100) calls his colleague's extension 200

  • The system resolves 200 to local account 91222333555 under 'John Doe'

  • The system builds a routing list according to the routing plan: 98.77.66.80

  • Since this call must be identified as on-net, the system generates the corresponding SIP header

  • The call from ext 100 (91222333444) to ext 200 (91222333555) is routed to 98.77.66.80

  • Vendor accepts the call from ext 100 (CLI = 91222333444) to ext 200 (91222333555)
  • Vendor identifies that this call must be routed back to the service provider by the SIP header
  • The system accepts the call coming from 98.77.66.80
  • Mike's colleague (ext 200) sees the incoming call from ext 100

Use scenario #2.2a: Calls between customers' accounts (AA)

  • Continued after #1

  • Mike (91222333444) dials his bank number 91222000666

  • The system builds a routing list according to the routing plan: 98.77.66.80

  • Since this call must be identified as on-net, the system generates the corresponding SIP header
  • The call from 91222333444 to 91222000666 is routed to 98.77.66.80
  • Vendor accepts the call from 91222333444 to 91222000666
  • Vendor identifies that this call must be routed back to the service provider by the SIP header
  • The system accepts the call coming from 98.77.66.80
  • Mike gets connected to 'Alpha Bank' auto-attendant (91222000666)

Use scenario #2.2b: Calls between customers' accounts

  • Continued after #1

  • Mike (91222333444) dials his friend Alice's number 91999777000

  • The system builds a routing list according to the routing plan: 98.77.66.80

  • Since this call must be identified as on-net, the system generates the corresponding SIP header
  • The call from 91222333444 to 91999777000 is routed to 98.77.66.80
  • Vendor accepts the call from 91222333444 to 91999777000
  • Vendor identifies that this call must be routed back to the service provider by the SIP header
  • The system accepts the call coming from 98.77.66.80
  • Alice (91999777000) sees the incoming call from 91222333444

Use scenario #2.2c: Calls between customers' accounts (from IP PBX)

  • Continued after #1

  • 'Smart Insurance' employee, Craig (91222555888), dials Mike's number 91222333444

  • The system authorizes the call from 'Smart Insurance' IP PBX (201.10.15.27) to 91222333444

  • The system builds a routing list according to the routing plan: 98.77.66.80

  • Since this call must be identified as on-net, the system generates the corresponding SIP header
  • The call from 91222555888 to 91222333444 is routed to 98.77.66.80
  • Vendor accepts the call from 91222555888 to 91222333444
  • Vendor identifies that this call must be routed back to the service provider by the SIP header
  • The system accepts the call coming from 98.77.66.80
  • Mike (91222333444) sees the incoming call from 91222555888

Use scenario #2.3: Internal conference calls

  • Continued after #1

  • Mike (91222333444) dials *900

  • The system finds that *900 is the conference access number

  • The system builds a routing list according to the routing plan: 98.77.66.80

  • Since this call must be identified as on-net, the system generates the corresponding SIP header

  • The call from 91222333444 to the conference number *900 is routed to 98.77.66.80

  • Vendor accepts the call from 91222333444 to *900
  • Vendor identifies that this call must be routed back to the service provider by the SIP header
  • The system accepts the call coming from 98.77.66.80
  • Mike hears the IVR prompt, enters his pin and joins the conference

Use case #3: Handling off-net calls

Roles: Users, System, Vendor

Preconditions: There is a routing plan which sets static routing for all outbound calls to a single vendor connection

There is customer 'John Doe' with account 91222333444  in the system

  • Continued after #1

  • Mike (91222333444) calls his friend (PSTN 91888444987)

  • The system builds a routing list according to the routing plan: 98.77.66.80

  • The call from 91222333444 to 91888444987 is routed to 98.77.66.80

  • Vendor accepts the call from 91222333444 to 91888444987
  • Vendor sends the call from 91222333444 to 91888444987 for termination to PSTN
  • Mike's friend (91888444987) answers the incoming call from Mike (91222333444)

Other requirements / constraints

How about more complex scenarios with on-net calls involving multiple local accounts, huntgroups, forwards, transfers?