Networking — Something Good to Know

January 8, 2014

webRTC for online store application

Filed under: Uncategorized — conningtech @ 9:00 pm

webRTC for online store applications

DPI Based Intelligent network traffic routing

Filed under: Uncategorized — conningtech @ 8:59 pm

DPI based intelligent network traffic routing

Enhanced Voice Mail Services

Filed under: Uncategorized — conningtech @ 8:52 pm

1.      Existing voice mail services overview

  • PSTN/wireless/VoIP/etc. users who subscribed “voicemail” service can direct incoming calls to voicemail system based on preference (e.g. on busy line etc.)
  • Calls directed to voicemail system are recorded and saved in voice system, and voicemail waiting indicator is delivered to the user’s device or email account via SMDI/Skinny Call Control Protocol, SMS, email etc.
  • Users can access their voicemail accounts via phone, email, web and so on to listen, manage and delete stored voicemails.

2.      Enhanced voice mail services/capabilities

  • Introduced voicemail class/category/priority/treatment indications: voicemail sender is allowed and prompted to specify the class/category/priority/treatment indications of the voicemail to be recorded, and these indications are used to instruct the voicemail treatment and voicemail waiting indicator delivery. These indications are saved together with the corresponding voicemails in the voicemail system database.
  • Introduced voicemail system/application server initiated call to deliver the voicemail(s): if a voicemail treatment indication specifies that to make a call and deliver the voicemail to the recipient via call, the voicemail system or appropriate application server initiates a call to the recipient when the called device is free and deliver the voicemail via call. Here are two example cases:

i.     Voicemail system initiates the call. When a new voice mail is received and If the voicemail system is capable of initiating calls, it checks the recipient’s status (e.g. via presence server) and initiates a call to the recipient’s’ device when found free. When the call is answered, the recorded voicemail is delivered/played through the call. All voicemail handling features of the current existing voicemail listening (via phone) can be applied.

ii.     Application server initiates the call. If the voicemail system is not capable of making calls, an application server can be placed in between the voicemail system and user device. On receiving a new voicemail, the voicemail system delivers a voicemail waiting indicator through the application server to the user using existing method. On receiving such an indicator, the application server then checks the recipient’s status (e.g. via presence server) and initiates respectively a call to the recipient’s’ device and a call to the voicemail system when the recipient’s device is found free. When the call is answered, the two calls are bridged and the recorded voicemail is delivered/played through the call to the recipient. All voicemail handling features of the current existing voicemail listening (via phone) can be applied.

Optionally, an IVR/announcement server can be connected to the voicemail recipient before the call is connected to the voicemail system to prompt and allow the recipient to control this voicemail system/application server initiated call on how to handle the call and the corresponding voicemail. Also optionally, the voicemail system/application server can provide user preference configuration capability on how to initial the voicemail system/application server initiated call and the corresponding voicemail.

  • Introduced voicemail-caller-callee conferencing capability: when a voicemail is listened by the recipient via any type of calls described in above texts or traditional dial-in method, the voicemail system (if capable) or application server can initiate a conference call to the original voicemail sender to let the three party discuss the voicemail context lively.
  • Introduced voicemail aggregation/association: when a recipient listened a voicemail and calls back to the voicemail sender and is directed to the sender’s voicemail system, the replying voicemail and the original voicemail can be tagged and associated/aggregated via these tags. When playing back the voicemail by either party, the associated voicemail records can also be accessed for reference if needed.

3. Architectural diagram of the enhanced voicemail system/services

enhanced vms

“Select-to-visit” – a telephone IVR system base web page delivery and presentation capability

Filed under: Uncategorized — conningtech @ 8:45 pm

 

1.      Background information

“click-to-call” is a web capability that allows the web page viewer to make a real-time call to the targeted recipient while surfing the web page. The calling device can be a software phone client on the same computer or it can be any common independent phone devices (e.g. telephone, cellphone etc.) with its telephone number associated with the “click-to-call” configuration. When the “click-to-call” link/button in the web page is clicked by the viewer, a call is made between the viewer’s designated phone device to the targeted recipient and then the two parties can proceed with real-time call session when call is established. This is a great feature that integrates the information-rich web pages with the real-time on-demand capability of phone services, and is very useful in customer service type of applications.

 

In the traditional telephone based customer service (e.g. call center) use cases, the typical scenario is like:

  1. Customer calls the customer service number (e.g. a 1-800 number)
  2. The call is initially answered by the interactive voice response (IVR) system and the calling customer is prompted to follow and menu and response with appropriate selection so that the system can direct the call to appropriate agent and/or automatic handling logic.
  3. When the customer service call is initially established, a lot of customer service IVR introductive announcement has statement like “Welcome to xxx customer service, you can also visit our web page at www.xxx.com. For sales, please press or say ‘one’, for order status, please press or say ‘two’,……”
  4. In response to this “welcome” menu, if a customer want to visit the company’s web site, he/she needs to open the web browser and type in the company’s web link as announced and then start visit the web page. 

2.      Description of “Select-to-visit”

The “Select-to-visit” capability described here is to introduce the following capabilities into the telephone IVR system based applications that allows the web page be automatically opened in the customer’s designated device (e.g. computer, smartphone etc.) when the customer select the “visit company web” option in the IVR menu during the customer service call session.

  1. Customer calls the customer service number (e.g. a 1-800 number)
  2. The call is initially answered by the interactive voice response (IVR) system and the calling customer is announced the “welcome” menu like “Welcome to xxx customer service, to visit our web page at www.xxx.com, please press or say ‘nine’, for sales, please press or say ‘one’, for order status, please press or say ‘two’,……”
  3. If the customer press or say “nine”, the IVR system then trigger a web proxy server to issue a web request to acquire the company’s web page and redirect the corresponding reply to the designated calling customer web capable device (such as computer or smartphone that makes the customer service call).
  4. On receiving such web page reply, the client/agent in the customer device opens the customer preferred web browser automatically and displays the received page contents.
  5. The customer designated web page receiving device can be determined by either configuration in the customer’s account or customer device capability detection mechanism provided by the network.

Customer service/call center application is only one typical usage example of this “select-to-visit” capability. This capability can definitely be used in any other telephone IVR and web integration applications.

 

Wireless Signal Level Based Intelligent Mobile Device Capability/Function Control

Filed under: Uncategorized — conningtech @ 8:40 pm

With the integration of more and more capabilities (such as static or video camera functions, recording functions and so on) into mobile devices, and with more and more varieties of services (voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) provided to the mobile devices, it is more and more convenient and flexible for a user to do activities of his/her interest at anytime and anywhere by a lot of means using his/her mobile devices.  A lot of these communication activities, however, will rely on certain wireless signal strength and traffic channel quality of service (QoS) levels, such as available average and top/bottom speed, retransmission rate, error rate and so on.

 

The wireless signal level based mobile device capability control provides a method that allows to control the communication capabilities of a mobile device based on the real-time wireless signal strength and traffic channel QoS  measurements and the user’s preference configuration. In brief, a functional module resides in the mobile device keeps monitoring the real-time wireless signal strength and the traffic channel QoS levels, and check them against the owner’s preference configurations and controls (e.g. enable, disable and any other possible forms of control) the use of the mobile communication capabilities (such as voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) so that a specific communication capability (e.g. video calls) can only be placed when a certain wireless signal strength and certain QoS levels can be achieved at the use time. Such controls can be turned on or off by owners on their wills.

 

In addition to the real-time QoS measurement by the mobile device itself, QoS measurement can also be done by any existing or new network elements, and in this case, network measured QoS values can be delivered to the mobile device to help with the communication capability control decision making.

 

When user launches a function/capability/application that will need certain wireless signal strength and/or traffic channel QoS guarantees, a prompt can be raised to alter user for allow/disallow the function/capability/application.

 

Battery Level Based Intelligent Mobile Device Capability/Function Control

Filed under: Uncategorized — conningtech @ 8:37 pm

With the integration of more and more capabilities (such as static or video camera functions, recording functions and so on) into mobile devices, and with more and more varieties of services (voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) provided to the mobile devices, it is more and more convenient and flexible for a user to do activities of his/her interest at anytime and anywhere by a lot of means using his/her mobile devices.  A lot of these activities, however, will require intensive usage of battery power. With the main purpose being for communications, especially for emergency voice calls for example, the mobile device is often the essential tool for a user to keep the basic and critical contact with others and therefore a user will most likely want or prefer to maintain some minimum battery power level to sustain this basic and critical need.

 

The battery level based intelligent mobile device capability control provides a method that allows to control the functional and communication capabilities of a mobile device based on the real-time battery level measurement and the user’s preference configuration. In brief, a functional module resides in the mobile device keeps monitoring the real-time battery level and check it against with the owner’s preference configurations and controls (e.g. enable, disable and any other possible forms of control) the use of the functional capabilities of the mobile device (such as static or video camera functions, recording functions, OTT Applications and so on) and the mobile communication capabilities (such as voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) so that a given remaining batter power level can be reserved and limited only to the allowed functions/capabilities/applications corresponding to the battery level specified in the owner’s preference configurations. Such controls can be turned on or off by owners on their wills.

 

In addition to the real-time battery power level monitoring, estimated power consumption of a certain application (e.g. a video call etc.) can be calculated based on the wireless signal strength, screen brightness, network quality of service (speed, error/retransmission rates etc.) and so on. Control decision can then be made more intelligently by combining the remaining battery power level and estimated power requirement etc.

 

When user launches a function/capability/application that will need significant battery power, a prompt can be raised to alter user for allow/disallow the function/capability/application.

 

Location Based Intelligent Mobile Device Capability/Function Control

Filed under: Uncategorized — conningtech @ 8:32 pm

With the integration of more and more capabilities (such as static or video camera functions, recording functions and so on) into mobile devices, and with more and more varieties of services (voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) provided to the mobile devices, it is more convenient and flexible for a user to do activities of his/her interest at anytime and anywhere. This at the meantime imposes significant challenges to both the user him/her-self and the location owners when any of those activities are restricted by any means such as privacy, confidentiality, or any other forms of governmental or private restrictions at a specific location. To a user, he/she may involuntarily violate the laws or rules while doing disallowed activities in a specific location. To the location owners, such as government facilities with high confidentiality rulings, privacy and confidentiality protection becomes more and more vulnerable.

 

The location based mobile device capability control is a method that allows to control the functional and communication capabilities of a mobile device based on location. In brief, when a mobile device is entering a location (positioned by any types of Cellular positioning technologies, and/or GPS etc.), the functional capabilities of the mobile device (such as static or video camera functions, recording functions, OTT Applications and so on) and the mobile communication capabilities (such as voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) will be controlled (e.g. disabled or enabled or any other forms of controls) by an appropriate functional module resides in the mobile device either automatically or manually based on 1) user’s preference configuration and/or 2) suggestive or mandatory lawful/policy requirements of a specific location. When control decision is made based on user’s preference, all controlling calculations and logics are done in the mobile device. When control decision is made based on the lawful/policy requirements of a specific location or based on this information in conjunction with user’s preference, the location based lawful/policy requirements will be delivered to the mobile device from a server when the mobile device is entering a specific location to help making the control decision. The holding place of the relevant lawful/policy requirements can be a location owner owned server that is connected to the network and accessible by the mobile device and/or the network, or it can be a specific network server element that provide the location based lawful/policy requirements hosting services.

 

When a control decision is made and applied, the functional and communication capabilities of a mobile device will be limited or restricted according to user’s preference or location owner’s lawful/policy requirements.

A notes on HSS schema

Filed under: Uncategorized — conningtech @ 7:47 pm

HSS Schema Notes….

SIM, USIM, CSIM and ISIM Overview

Filed under: Uncategorized — conningtech @ 7:30 pm

An overview on wireless SIM, USIM, CSIM and ISIM……

Create a free website or blog at WordPress.com.