Patent Grant
7155528
The present invention relates in general to network-based voice communications, and more particularly to a method of supporting functionally based supplementary services implemented using H.323 protocol.
H.323 is a well known standard for multi-media communication. This standard governs communications between terminals and other entities over a packet switched network. A person of ordinary skill in the art and who is familiar with the H.323 standard will understand the elements of establishing third party call control via a Gatekeeper. Briefly, upon powering up, a H.323 endpoint (desktop) implements a discovery process for determining which Gatekeeper to register with. This can be effected in a number of ways, such as by multicasting a message which identifies the endpoint (i.e. the GRQ message) to a predetermined multicast address. The assigned Gatekeeper then responds (i.e. the GCF/GRJ message) with its RAS channel address (i.e. IP address). Before attempting to place a call, the endpoint must register with the Gatekeeper (i.e. the RRQ message) by advising it of its transport address and any aliases (discussed below). Registration is then confirmed by the Gatekeeper (i.e. via the RCF/RRJ message). Actual call signaling takes place over an established channel between two H.323 endpoints using Q.931 messages. For third party (i.e. Gatekeeper) call control, the originating endpoint sends a H.225 Admission Request (ARQ) to the Gatekeeper over the previously established RAS channel. The Gatekeeper responds with an ACF message which specifies the call signaling transport address to use for the call setup. The originating endpoint then transmits a Setup message to the Gatekeeper which, in turn, sends a Setup message to the destination endpoint. The destination endpoint then sends an admission request (ARQ) to the Gatekeeper and receives an acknowledgment (ACF) therefrom. Finally, a Connect message is sent from the destination endpoint to the Gatekeeper which contains the address of the originating endpoint for H.425 control messages to the originating endpoint.
The inventor has recognized the desirability of adapting the H.323 standard to voice communications such as traditionally implemented via a PBX. However, the H.323 umbrella protocol standard only provides a limited set of recommendations in terms of supporting functionally based supplementary services between a Gatekeeper (GK) and an Endpoint (EP), due to the relative newness of the standard. Thus, H.323 suffers from limitations in providing a full range of PBX like functionally based supplementary services. The use of a functionally based supplementary service protocol requires a substantial amount of intelligence and knowledge of state within the Endpoint, which tends to make an Endpoint code heavy.
The H.323 recommendation refers to the H.450 recommendation as the primary method for functionally based supplementary service signaling in the H.323 domain. The H.450 recommendation is new, with support for only eight supplementary services (as of Oct. 99), and expanding at a current rate of only three supplementary services per year. Furthermore, the H.450 protocol is a cumbersome protocol since it is ASN.1 based.
Another available method of supplementary services signaling is through the use of “DTMF signaling”. This is similar to the use of feature access code signaling methods seen in traditional telephony. However, DTMF signaling is also not an ideal method for providing supplementary services since it usually requires a user to remember a complicated set of access codes and is therefore error prone.
According to the present invention, a simple supplementary service protocol (SSSP) is provided for implementing functionally based supplementary services using the H.323 standard. According to the preferred embodiment, a generic and expandable protocol is provided for passing supplementary services information between H.323 entities for the provision of over twenty classes of functionally based supplementary services. The protocol of the present invention is relatively lightweight (i.e. not code intensive) compared to H.450 since it does not rely on ASN.1 encoding. In addition, the mixture of functional and stimulus protocol concepts in the design of the inventive protocol results in robust functional characteristics and implementation capability using only lightweight Endpoints.
According to another aspect of the invention, a user interface is provided at an Endpoint for the purpose of displaying call and feature information relating to a SSSP enabled device, without the requirement of an elaborate state machine.
An embodiment of the invention is described below with reference to the accompanying drawings, in which:
A generalized method of Alpha Numeric String Encoding and Dual Tone Multiple Frequency (DTMF) String Encoding for a SSSP Protocol Data Unit (PDU) is provided, as set forth below. Alpha Numeric is the preferred method of encoding when used in H.323 systems. The DTMF String Encoding method is restricted to the traditional DTMF character set. As such, it allows SSSP to be ported to non-H.323 communication systems with ease.
General Encoding Terminology
AlphaNumericType ::= sequence of characters of set (A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
DirectoryNumberType ::= sequence of characters of set {0,1,2,3,4,5,6,7,8,9,#,*,!},
NumberType ::= sequence of characters of set {0,1,2,3,4,5,6,7,8,9}
MacAddressType ::= MacParm ‘*’ MacParam ‘*’ MacParam ‘*’ MacParam ‘*’ MacParam ‘*’ MacParam
In the foregoing encoding method, the following restrictions apply:
Thus, for example, a call forward busy indication containing the forwarded destination directory number is formatted as follows:
In the foregoing encoding method, the following restrictions apply:
According to the preferred embodiment at the time of this specification, five PDUTypes have been established including Indication, Command, Request, Response, and Error. The definitions are as follows:
Indication: a message that contains information but does not require action or response.
Command: a message that requires action but no explicit response.
Request: a message that results in action by the remote device and requires an immediate response from it.
Response: a message that is the response to a request.
Error: a message indicating exception information.
The following portions of this disclosure illustrate the use of SSSP for providing Gatekeeper implemented supplementary services. Table 1 provides a summary of example SSSP command and indication primitives. Table 2 provides a summary of example SSSP requests and responses. Table 3 lists requests for code enumeration, while Table 4 lists response code enumeration. Table 5 lists SSSP primitive descriptions. Table 6 lists error codes.
Rules for Expandability
There are two groups of rules for expanding the SSSP protocol, one for AlphaNumeric String Encoding and the other for DTMF String Encoding.
When adding new PDUs, the new PDU is defined based on the definition of PrimitiveName as set forth above. For extending existing PDU's, parameter expansion follows the rule of simply adding additional ParameterExtenstions to the end of the PDU.
Previously defined parameters are not removed from an existing PDU when new versions of a PDU are implemented, for backward compatibility. Endpoints supporting older versions of SSSP ignore parameters outside the scope of their known PDU templates.
Alphanumeric String Encoding Expansion Rules
The following is an example of expanding an existing PDU:
Pre-Conditions:
1. The Consultation Call Command PDU is to be expanded to support an Alias Field.
Additional Encoding:
Parameter Extensions Required:
The following is a example of expanding an existing PDU:
Pre-Conditions:
Being an application layer protocol, SSSP can be carried within any non-standard data field of a H.225 or H.245 message. For the preferred embodiment set forth herein, SSSP messages are carried within the RAS Location Request (LRQ) and Location Confirmation (LCF) messages in the following examples.
Using LRQ/LCF for SSSP Transport
SSSP messages are carried within the nonStandardData field of the LRQ and LCF message. For simplicity, the LRQ and LCF are not be used for address translation functionality and the sending and receiving entity regards the LRQ and LCF as a transport mechanism for SSSP only. An independent location request/response exchange is initiated for address translation services.
LRQ/LCF Attribute Encoding
Message Sequence Charts
The following sub-sections contain message sequence charts (MSCs) to provide guidance for the developer to implement SSSP in Endpoints and Gatekeepers. The format of the MSC is as follows:
H.225 and H.245 parameters that are mandatory within the H.225 and H.245 message are not presented within the message diagrams of
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
The message sequence is as follows:
To Login:
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
The message sequence is as follows:
The message sequence is as follows:
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
In
The message sequence is as follows:
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
In the scenario of
The message sequence is as follows:
A complicated state machine is traditionally required to keep user interfaces (UIs) in the correct context for displaying information related to a functionally based supplementary services protocol. The following portion of this disclosure provides a simplified implementation for providing a UI at an Endpoint for the purpose of display normal call and feature information related to a SSSP enabled device.
The state handling required for UI display is simplified in the present invention by dividing the display into two views: a feature display, which handles all feature related displays needed during SSSP interaction, and a default display, which handles all non-SSSP related display information. By flipping between feature and default displays according to a small finite set of rules, an Endpoint can provide an effective UI without a need for a completed state machine, as set forth below.
The term Default Display represents the normal status display view that a H.323 Terminal supports (if the Terminal has a display capability). For optimal support of SSSP feature indications, according to the present invention the H.323 Terminal supports an additional view (referred to herein as the Feature Display) for display of feature information. The Feature Display is driven by SSSP indications and has the same visual dimensions as the Default Display. According to the invention, the H.323 terminal runs both views (Default and Feature) at any given time. Both displays are updated in real time. However, only one display is placed in the foreground (displayed) to the user at any given time. Based on set rules, the Feature Display and Default Display toggle back and forth from foreground to background.
The contents of the display shown in Table 11 is for example purposes only. The display text may be customized to the capability of the end device. In addition, the terms “line1:” and “line2:” represent the line location to display the text on the Terminal.
When the Terminal receives a message from Table 11, it cancels any existing operation that has been started. Then the Terminal displays the correct Feature or Default display in the foreground.
For example:
The discussion above illustrates how SSSP indications that manipulate the Feature Display so as to toggle the Feature Display from background to foreground. The rest of the SSSP indications change internal parameter/state values, particularly if a value is set or not.
As shown in Table 12, the indications sent to the Endpoint cause the endpoint to update its current parameter/state value for a particular feature. This includes whether to turn on an icon or off an icon, showing if a feature is enabled or disabled in a feature list, or updating it's current calling line identifier display. On reception of a message listed in Table 12, the Endpoint follows the procedures listed in
Alternatives and variations of the invention are possible. For example, although H.2323 protocol is set forth as the existing protocol within which SSSP is transported, the principles of SSSP may be applied to ISDN, T1 or any other user-to-user communication protocol (i.e. any protocol which supports transparent tunneling of information. Also, although the specific implementation examples are directed to exchanges between the Gatekeeper and Endpoints, it will be understood by a person of skill in the art that SSSP may also be extended to communications between Endpoints. All such alternative embodiments and variations are believed to be within the sphere and scope of the claims appended hereto.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0001035.5 | Jan 2000 | GB | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 6118763 | Trumbull | Sep 2000 | A |
| 6430176 | Christie, IV | Aug 2002 | B1 |
| 6614784 | Glitho et al. | Sep 2003 | B1 |
| 6621814 | Korpi et al. | Sep 2003 | B1 |
| 6636508 | Li et al. | Oct 2003 | B1 |
| 6693874 | Shaffer et al. | Feb 2004 | B1 |
| 6738343 | Shaffer et al. | May 2004 | B1 |
| Number | Date | Country |
|---|---|---|
| 2343584 | May 2000 | GB |
| 9410813 | May 1994 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20010056496 A1 | Dec 2001 | US |
