1 / 18

nem.con Grandeur Pvt Ltd.

Communication solution – CASE STUDY 1. nem.con Grandeur Pvt Ltd. INDEX. CASE STUDY 1. Existing Communication Architecture . Office by Office Description . Challenges in Existing Architecture. NEW Architecture. New Call Flow and Features – Internal communication.

brent
Download Presentation

nem.con Grandeur Pvt Ltd.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. EXISTING COMMUNICATION ARCHITECTURE CASE STUDY 1 NEVADA – LARGEST WAREHOUSE 1 PRI LINE MICROSOFT COMMUNICATION SERVER VoIP DID IBW • 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. EXISTING COMMUNICATION ARCHITECTURE CASE STUDY 1 IBW • Client had an EPABX here • All calling through PRI • Intra office calling using PRI • Inbound traffic through DID serving as helpline for Sales / CS CALIFORNIA - HEADQUARTERS EPABX 1 PRI LINE DID

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

  7. EXISTING COMMUNICATION ARCHITECTURE CASE STUDY 1 IBW • 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 NEW YORK – WAREHOUSE EPABX 1 PRI LINE DID

  8. EXISTING COMMUNICATION ARCHITECTURE CASE STUDY 1 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 IBW

  9. CHALLENGES IN EXISTING ARCHITECTURE CASE STUDY 1 USER FRIENDLINESS COST • Inter office communication happened through PRI or VoIP and hence was chargeable. • Microsoft Communication Server – expensive technology. • Didn’t want any spends on hardware • Communication platforms used were not prioritised in terms of cost. • No Live monitoring across offices. • No recording of conversations. • IT admin has no collated view of the entire telecom spends. • No single client for voice / chat / video except for the Nevada Office. • Inbound caller had to rely on the operator for reaching the correct extension. TECHNICAL ARCHITECTURE • Integration of Microsoft communication server with Asterisk server and SIP client without an API and yet within legal purview. • IT admin will set all rules dynamically in Microsoft communication server but should be applicable to the asterisk server as well. • Different communication hardware in each of the offices making it difficult to unify them. • No organized call flow despite inbound calls for various departments.

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

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

  12. INTERNAL CALLING DESCRIPTION CASE STUDY 1 • 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 NEVADA • 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 ATLANTA • 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 OTHER OFFICES

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

  14. OUTBOUND DESCRIPTION CASE STUDY 1 • 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 CALL FLOW FEATURES • 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. NEW CALL FLOW – INBOUND - NON OFFICE CASE STUDY 1 NEVADA LYNC CLIENT MS COMM. SERVER DID IBW HUB ASTERISK SERVER CALIFORNIA ATLANTA PRI SIP CLIENT – I BEAM LOCAL ASTERISK SERVER SIP CLIENT – I BEAM SIP CLIENT – I BEAM SIP CLIENT – I BEAM

  16. INBOUND DESCRIPTION CASE STUDY 1 • 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 CALL FLOW FEATURES • 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. KEY HIGHLIGHTS CASE STUDY 1 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

More Related