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

User Story

Customer is an Internet provider and CDMA operator in Iraq using Porta Switch (PS provider). To increase the subscriber base of the phone service, they started with a project where they allowed any user with a smartphone to become their VoIP customer. User installs an app, automatically gets Iraqi DID number from customer's CDMA range, can call and receive calls using the app. Now they need to deliver incoming SMS to their users of the app via SIP messages. As a result, our customer will sell SMS termination services to big carriers like TATA.

The PS provider's DIDs, that are assigned to end-users and are used in his mobile apps, can be combined with users' own mobile numbers. For example, the user has his phone with a sim of mobile operator A. He then decides to additionally start using services provided by the PS provider, so he downloads the PS provider's app and gets the DID number. In this case the user will have his own mobile number assigned to the sim and a different DID assigned to the PS provider's app.

SMS will be delivered from PS provider to end users for free. The delivery of SMS from external Vendor to PS provider's network is not charged per message, but the total monthly fees may apply depending on total volume of messages passed.

Use case #1: Delivering of DIDs' SMS to mobile applications 

Roles: Admin, End-user, Carriers who want to send SMS to our customer's network

Preconditions: There are Carrier1, Carrier2, Carrier3 in the system, who send SMS messages to the system via SMPP protocol.

The system is set up to receive messages from Carriers in SMPP and convert them to SIP before delivering to accounts.

Scenario #1.1: Receiving SMS campaigns from a mobile operator in the mobile app

  • A new customer John Doe want to use services via a service provider's application. Admin creates a new customer in the system, assigns 111222333 DID to a new user, assigns a product 'Call & Chat'.

  • Admin provides John with DID number he'll have and a password. John downloads a mobile app, registers his account.

  • Asia Cell mobile operator starts sms campaign informing users about their new promotional actions. SMS are sent to the service provider's DID numbers as well.

  • A message comes from Carrier1 to 111222333 DID.
  • The system understands that 111222333 is a local DID, registered via the app, so it sends the message to the app via SIP.

  • John sees in his mobile app a new message from Asia Cell.


Scenario #1.2: Receiving verification SMS in the mobile app

  • Continued after Scenario #1.1.

  • John decides to download Viber app to his phone.
  • John specifies his phone number as 111222333 DID in Viber to perform his SMS verification.
  • Verification SMS is sent to 111222333 number containing a verification code, that should be entered in Viber to verify that the user owns 111222333 number.
  • John opens his mobile app, and sees a new message from Viber service center with a verification code.
  • John copies the verification code, pastes it in Viber .
  • 111222333 gets verified / bound to the user in Viber.

Use case #2: Inter-env messages delivery

Roles: Admin, End-user, Carriers who want to send SMS to our customer's network, System

Preconditions:

Account 1111 is registered in env1 via Zoiper App (UDP/TCP/TLS transport can be used). Account 2222 is registered in env4 via CloudSoftPhone App (UDP/TCP/TLS transport can be used).

Scenario #2.1: Routing of the messages between envs

  • Admin creates 1111 in env1 and assigns a product with messaging configured ( 'Call & Chat').

  • Admin creates 2222 in env4 and assigns a product with messaging configured ( 'Call & Chat 2').
  • Admin creates connection  "Messages to vendor via SMPP" in env1 and assigns IP of env4 SIP cluster.
  • Admin creates Service Policy with '222%' Recipient domain pattern' and SMPP transport in env1.

  • Admin creates configuration in env4 for receiving incoming SMS. 

  • Account 1111 send message to 2222 via SIP.

  • The system (env1) converts SIP message to SMS and routes it to env4 via the connection.
  • The system (env4) gets the SMS, converts it to SIP message and delivers it to 2222.

  • User of 2222 account sees in his mobile app a new message from 1111 account user.

 

Use case #3: The only entry point for incoming SMSs from Carrier

Roles: System, End-user (mobile App.), Carrier who want to terminate SMS messages on Customer's network

Preconditions: There is "TATA" carrier who sends SMS messages to accounts located in all envs via SMPP protocol. Our customer provides TATA with IP from Env1, so that messages from TATA are received in ENV=1.

environment #1 is set up to receive SMSs from the carrier TATA and send to other envs based on the e.164 numbers by certain pattern (e.g. 222%).

environment #2 is set up to receive SMSs from env1  (e.g. connection with VIP IP of env1).

Account 1111 is registered in env1 via Zoiper App. Account 2222 is registered in env2 via CloudSoftPhone App. The accounts have got Messaging service configured.

The same entry IP is not possible to assign for different envs.

Scenario #3.1: Delivering SMS from Carrier to an account registered via the same entry point (env1)

  • Carrier sends SMS to 1111 account via SIP cluster IP in env1;

  • System processes the SMS within env1 and finds the account created in env1;
  • System delivers the SMS to Mobile App with 1111 account registered like it is expected in 1.1, 1.2 scenarios;

Scenario #3.1: Delivering SMS from Carrier to account registered in a different env (env2)

  • Carrier sends SMS to 2222 account via SIP cluster IP in env1;

  • System processes the SMS within env1 and does not find the account created in env1;
  • System decides to route the SMS via existing external Vendors;
  • System matches connection by '222%' pattern and routes the SMS to env2 via the connection;
  • System gets the SMS within env2 and delivers it to 2222 account in similar way described in 3.1 scenario. 

Use case #4: Billing processing for the involved entities

Roles: System, End-user (mobile App.), Carrier who want to terminate SMS messages on Customer's network, Admin

Preconditions: There is "TATA" Customer who sends SMS messages to accounts via env1;

Admin configured tariff for TATA. Tariff is based on e.164 format, specifies price per SMS.

environment #1 is set up to receive SMSs from the TATA and forward them to another envs if necessary.

Accounts 1111, 2222, 3333, ... are registered in different envs . The accounts have got Messaging service configured.

Incoming SMSs are free of charge for the App users.

"TATA" pays for the SMS delivered to customer's network.

Scenario #4.1: SMS authorization and settlement with Carrier

  • Carrier sends SMSs to during certain period (e.g. during the month);

  • System counts records for SMSs received from the Carrier;
  • Admin counts 1000 SMSs passed from TATA for the specified period;
  • TATA has to pay 10$ for the delivered messages.

1 Comment

  1. Vaclav Balcar

    So far it looks, like the billing arrangement doesn't require from vendor connection in this specific use case where account charged=carrier. 

    However we will need some technical definition of the incoming point. It looks like we need to extend the Authz_Rules for MSG service type defining who to identify in system. Already discussed with @psv some time ago. Note we already have Authz_Rules.i_service_policy for keeping IM parameters.

    From there it will be then provisioned to Imgate. So in the first implementation they can be set manually by the SMPP plugin parameters. When/if we add MSG from Vendor connection the Authz_Rules would be autopopulated, like we do for voice.