1. nem.con Grandeur Pvt Ltd. Communication solution – CASE STUDY 1

2. INDEX  Existing Communication Architecture  Challenges in Existing Architecture  NEW Architecture  New Call Flow and Features – Internal communication  Key Highlights CASE STUDY 1  Office by Office Description  New Call Flow and Features – Inbound – External Communication  New Call Flow and Features – Outbound – External Communication

3. CASE STUDY 1 EXISTING COMMUNICATION ARCHITECTURE NEVADA – LARGEST WAREHOUSE 1 PRI LINE MICROSOFT COMMUNICATION SERVER VoIP DID CALIFORNIA - HEADQUARTERS EPABX 1 PRI LINE DID ATLANTA – WAREHOUSE EPABX 1 PRI LINE DID NEW YORK – WAREHOUSE EPABX 1 PRI LINE DID CHICAGO –WAREHOUSE 1 PRI LINE MICROSOFT COMMUNICATION SERVER DID

4. CASE STUDY 1 EXISTING COMMUNICATION ARCHITECTURE NEVADA – LARGEST WAREHOUSE 1 PRI LINE MICROSOFT COMMUNICATION SERVER VoIP DID Client had installed Microsoft communication exchange server. local calling was done through pri line while calling outside of the state was done through VoIP Intra office calling using VoIP. Inbound traffic through DID which served as helpline for sales / CS

5. CASE STUDY 1 EXISTING COMMUNICATION ARCHITECTURE CALIFORNIA - HEADQUARTERS EPABX 1 PRI LINE DID Client had an EPABX here All calling through PRI Intra office calling using PRI Inbound traffic through DID serving as helpline for Sales / CS

6. CASE STUDY 1 EXISTING COMMUNICATION ARCHITECTURE ATLANTA – WAREHOUSE EPABX 1 PRI LINE DID Client had an EPABX here All calling through PRI Intra office calling using PRI Inbound traffic through DID serving as helpline for Sales / CS

7. CASE STUDY 1 EXISTING COMMUNICATION ARCHITECTURE NEW YORK – WAREHOUSE EPABX 1 PRI LINE DID Client had an EPABX here All calling through PRI Intra office calling using PRI Inbound traffic through DID which served as helpline for sales / CS

8. CASE STUDY 1 EXISTING COMMUNICATION ARCHITECTURE CHICAGO –WAREHOUSE EPABX 1 PRI LINE DID Client had an EPABX here All calling through PRI Intra office calling using PRI Inbound traffic through DID serving as helpline for sales / CS

9. CASE STUDY 1 CHALLENGES IN EXISTING ARCHITECTURE COST USER FRIENDLINESS TECHNICALARCHITECTURE

10. CASE STUDY 1 NEW ARCHITECTURE NEVADA – LARGEST WAREHOUSE 1 PRI LINE MICROSOFT COMMUNICATION SERVER ASTERISK SERVER ON VMWARE VoIP DID – all Geographies CALIFORNIA - HEADQUARTERS REMOTE CONNECTIVITY TO ASTERISK SERVER VoIP ATLANTA – WAREHOUSE REMOTE CONNECTIVITY TO ASTERISK SERVER LOCAL ASTERISK SERVER on PC PRI NEW YORK – WAREHOUSE REMOTE CONNECTIVITY TO ASTERISK SERVER VoIP CHICAGO –WAREHOUSE REMOTE CONNECTIVITY TO ASTERISK SERVER VoIP

11. CASE STUDY 1 NEW CALL FLOW - INTERNAL HUB ASTERISK SERVER MS COMM. SERVER LYNC CLIENT SIP CLIENT – I BEAM SIP CLIENT – I BEAM LOCAL ASTERISK SERVER SIP CLIENT – I BEAM SIP CLIENT – I BEAM SIP CLIENT – I BEAM SIP CLIENT – I BEAM SIP CLIENT – I BEAM SIP CLIENT – I BEAM VoIP PRI VoIP PRI NEVADA CALIFORNIA CHICAGO ATLANTA NEW YORK

12. CASE STUDY 1 INTERNAL CALLING DESCRIPTION Within Nevada office, employees can chat, video call, call each other through LYNC client on dialling desired extension. CALL FLOW: LYNC – MS Comm Server – HUB Asterisk Server – MS COMM Server - LYNC Within the organization out side of Nevada office employees can call other employees on desired extensions. CALL FLOW: LYNC – MS Comm Server – HUB Asterisk Server – SIP CLIENT In the Atlanta office, there was a connectivity issue with bandwidth at times, hence a local Asterisk Server was installed there. Internal calling of employees within office happened on dialling desired extension numer. CALL FLOW: SIP CLIENT – LOCAL Asterisk Server – SIP CLIENT Internal calling to Nevada office employees on dialling desired extension CALL FLOW: SIP CLIENT – LOCAL Asterisk server – HUB Asterisk Server – MS Comm. Server – LYNC. In case the bandwidth is down then dial the desired number through VoIP. CALL FLOW: SIP CLIENT – LOCAL Asterisk Server – PRI – END USER Internal calling within same location or other locations except Nevada office. CALL FLOW: SIP CLIENT – HUB Asterisk server – SIP CLIENT Internal Calling to Nevada office. CALL FLOW: SIP CLIENT – HUB Asterisk server – MS Comm. Server - LYNC

13. CASE STUDY 1 NEW CALL FLOW – OUTBOUND – NON OFFICE HUB ASTERISK SERVER MS COMM. SERVER LYNC CLIENT SIP CLIENT – I BEAM SIP CLIENT – I BEAM LOCAL ASTERISK SERVER SIP CLIENT – I BEAM SIP CLIENT – I BEAM VoIP PRI VoIP PRI NEVADA CALIFORNIA ATLANTA

14. CASE STUDY 1 OUTBOUND DESCRIPTION Nevada office employees can out call any number. CALL FLOW: LYNC – MS Comm Server – HUB Asterisk Server – VoIP/PRI – DESTINATION Other than Atlanta / Nevada office calling outside of office network happens as under CALL FLOW: LYNC – SIP CLIENT – HUB Asterisk Server – VoIP/PRI – DESTINATION Atlanta office calling outside of the organization network CALL FLOW: SIP CLIENT – LOCAL Asterisk Server – HUB Asterisk Server – VoIP/PRI – DESTINATION Atlanta office calling outside of organization when connectivity is down CALL FLOW: SIP CLIENT – LOCAL Asterisk Server – PRI - DESTINATION Outcalling will happen as per the dynamic low cost routing logic set by the admin in Microsoft Comm. Server – Asterisk server will understand the rules set in MS Comm. Server and set the routing accordingly. Call recording – chronicling with proper nomenclature from the recording library. Call Retrieval – Through an advanced search box Automatic switchover from VoIP to PRI in case VPN over IBW is down.

15. CASE STUDY 1 NEW CALL FLOW – INBOUND - NON OFFICE HUB ASTERISK SERVER MS COMM. SERVER LYNC CLIENT SIP CLIENT – I BEAM SIP CLIENT – I BEAM LOCAL ASTERISK SERVER SIP CLIENT – I BEAM SIP CLIENT – I BEAM DID PRI NEVADA CALIFORNIA ATLANTA

16. CASE STUDY 1 INBOUND DESCRIPTION All incoming calls land on DIDs that the organization had taken, which were different for different regions. For nevada office, inbound calls landed as per this logic CALL FLOW: ORIGIN – HUB Asterisk Server – MS Comm. Server - LYNC For Atlanta Office the incoming calls were routed as under: CALL FLOW: ORIGIN – HUB Asterisk Server – LOCAL Asterisk Server – SIP CLIENT For other offices the incoming calls were routed as under: CALL FLOW: ORIGIN – HUB Asterisk Server – SIP CLIENT Inbound calls from various destinations would land up on the HUB Asterisk server where an IVR Was configured giving 3 options to the callers: If for Sales press 1 and the call would land up at sales workstations of the respective offices. If for service press 2 and the call would land up at service work stations of the respective offices. If they knew the desired extension number, they can straightaway dial that too. In case the call doesn’t get picked up then it gets routed to a mobile number which was manned 24/7. In case the mobile number is busy then the caller leaves a voice mail which gets emailed to the extension number the caller was trying to reach. In case of a caller calling to Sales or service set up, and not able to get through, voice mail was emailed to the supervisor who can further take care of it. Call recording and chronicling them.

17. CASE STUDY 1 KEY HIGHLIGHTS Negotiation with the MC Comm Server Protocol without an API and without any illegal access of the DB. Setting up a multi office communication architecture with minimal expense. Creating a low cost routing logic for outbound calls, basis the cheapest VoIP rates for the destination location – which was dynamic and can be altered by the Admin. Ensuring that inbound calls get routed to the sales / service of the respective office basis the location of the originator

18. CASE STUDY 1