Browse Prior Art Database

Visual Presentation of Call Information to Subscriber

IP.com Disclosure Number: IPCOM000103538D
Original Publication Date: 2005-Apr-16
Included in the Prior Art Database: 2005-Apr-16
Document File: 2 page(s) / 100K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

Useful call informations should be presented to the subscriber of a telecommunication network instantly, constantly and in a good looking and flexible way. Such informations can be that the subscriber has moved or that he is not accepting any calls. In addition, it should be inexpensive for the operator. The suggested solutions work in the following way: The signaling of the transaction currently passes to the subscriber exchange, the cause values of the call. E.g. call is barred to a destination, the destination is unreachable, and user is busy and so on. Now, there are two alternative solutions from this point on: 1) At the subscriber exchange a server will map the cause values to an appropriate mask (e.g. HTML-page (Hypertext Markup Language)) that will be forwarded to the subscriber's device and hence the actual reason for an unsuccessful call will be displayed on his apparatus screen (e.g. videophone screen). 2) After the message is received by the user terminal, the response code that is contained will be mapped to the proper stored HTML-page and that HTML-page will be displayed at the screen of the videophone by the HTML-browser of the terminal.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 2

S

Visual Presentation of Call Information to Subscriber

Idea: Michael Kenameas, GR-Athens

Useful call informations should be presented to the subscriber of a telecommunication network instantly, constantly and in a good looking and flexible way. Such informations can be that the subscriber has moved or that he is not accepting any calls. In addition, it should be inexpensive for the operator.

The suggested solutions work in the following way:

The signaling of the transaction currently passes to the subscriber exchange, the cause values of the call. E.g. call is barred to a destination, the destination is unreachable, and user is busy and so on.

Now, there are two alternative solutions from this point on:

1) At the subscriber exchange a server will map the cause values to an appropriate mask (e.g. HTML- page (Hypertext Markup Language)) that will be forwarded to the subscriber's device and hence the actual reason for an unsuccessful call will be displayed on his apparatus screen (e.g. videophone screen).

2) After the message is received by the user terminal, the response code that is contained will be mapped to the proper stored HTML-page and that HTML-page will be displayed at the screen of the videophone by the HTML-browser of the terminal.

The advantages of these solutions are considerable. The user has a nice and convenient visual output. He understands instantly and exactly what the situation is. There is no waiting to hear the announcement and no misunderstandings. He can save the output and prove it in some kind of situation. The output can contain many useful information, e.g. time, call-type, a-number, b-number, event, instructions, interfaces that can allow additional action from the subscriber, e.g. post-processing of the received data for various reasons.

The operator can reduce or eliminate the announcement part that needs so much resources and implementation (hardware parts, connections etc.). The user will have instead some servers at the subscriber-side that will do the mapping to predefined masks (HTML-pages) and then, these masks will be forwarded to the subscriber's videophone device. By using this technique the bandwidth that is needed will remain extremely low, since the error code will pass to the subscriber side over the signaling and at the subscriber exchange it will be mapped to HTML-page and it will be send over to the apparatus afterwards. Additionally, there will be no delay to release the call and to connect the announcement and to play the announcement. Instead of that the error code will be forwarded immediately to the subscriber and it will be mapped to HTML-page and then it will be displayed to the videophone screen.

This solution can help also people that have problems with their hearing (e.g. elderly people etc.).

Examples of the described idea:

1) Terminal solution

A SIP (Session Initiation Protocol) subscriber A is calling a subscriber B. The call is progressing but the terminating exchange fin...