Patent Application
20050289222
The present invention relates generally to the Session Initiation Protocol (SIP). More particularly, the present invention relates to a method, apparatus, and computer program for assigning a plurality of SIP Endpoints to any part of a communication resource that participates in SIP based sessions.
The Session Initiation Protocol (SIP) is an application-layer control protocol for creating, modifying, and terminating sessions between communication resources. The SIP protocol specification is defined in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 3261, dated June 2002; the disclosure of which is incorporated herein by reference in its entirety. Accordingly, it is known in the art that SIP may be used by a SIP Enabled Application, which is executing on a SIP Enabled Device, to manage Internet telephony and distributed multimedia conferencing sessions.
The SIP protocol specification defines several types of communication resources that are involved in establishing and maintaining SIP based sessions, which can include user agents, registrars, redirect servers, and proxies. These SIP communication resources are responsible for sending, receiving, routing, and relaying SIP messages among various user agents that participate in SIP based sessions.
A SIP Endpoint is a logical construct in a communication resource that participates in a SIP based session. A SIP Endpoint is assigned a SIP Universal Resource Identifier (URI) to enable communications with other SIP communication resources. The SIP URI identifies a sender and a receiver of a SIP message in the header fields of SIP protocol data units.
According to the SIP specification, RFC 3261, the general format of a SIP URI is: “sip:user@host.” There also several optional fields of a SIP URI. A SIP URI is similar to the popular mailto URL that defines an email address. The SIP specification also defines a SIPS URI, which indicates that a communication resource is to be contacted securely. The SIPS URI has the same general format as the SIP URI format shown above, except the term “sip” is replaced with “sips”. The term “SIP address” will be used throughout this specification to refer in general to either a SIP URI or a SIPS URI, as will be understood.
A physical endpoint in a SIP network is a SIP Enabled Device or object. Examples of SIP Enabled Devices include, but are not limited to, a telephone, a personal computer, a personal digital assistant, and a multimedia teleconferencing device. These SIP Enabled Devices employ SIP Enabled Applications to establish and maintain sessions that are required by the SIP Enabled Applications.
Prior art SIP Enabled Applications associate a single SIP Endpoint with a single SIP Enabled Device. As a result, current SIP Enabled Applications only have the capability to provide limited control of subscriber devices, which limits the features and services that may be provided by these applications. For example, current SIP Enabled Applications that support Internet telephony are unable to offer many of the advanced features that are currently available to users of non-SIP enabled devices, who connect to the Public Switched Telephone Network (“PSTN”) through a Private Branch Exchange (PBX). These advanced features include, but are not limited to, three-way calling and advanced display control.
Prior art SIP enabled Internet telephony systems have attempted to overcome the above-mentioned limitations of SIP by implementing additional protocols in conjunction with SIP. These protocols have provided a subset of the features currently available to modern PBX users, such as the capability to signal a new incoming call on a SIP Enabled Device that is already part of a SIP communication session, for example. However, these protocols are not flexible and are limited in scope and applicability. Moreover, these protocols do not provide an optimized SIP call flow. Applications developed in conjunction with these protocols do not provide the flexibility of associating multiple SIP Endpoints with a single SIP Enabled Device.
The foregoing and other problems and deficiencies in the prior art are overcome by the present invention that provides a method, apparatus, and computer program for flexibly assigning multiple SIP Endpoints to a single subscriber SIP Enabled Device.
An object of the present invention is to remove device location and behavior requirements from a SIP Enabled Application, thus providing a generic interface for developing robust SIP Enabled Applications.
A further object of the present invention is to provide SIP Enabled Applications with an ability to associate and coordinate activities that are occurring on a plurality of SIP Endpoints, which endpoints may correspond to any part of a SIP Enabled Device.
Yet another object of the present invention is to enable the development of advanced features in SIP Enabled Applications.
Still another object of the present invention is to provide the ability to develop powerful SIP call control applications.
A further object of the present invention is to expose all User Interface Points of a communication resource to SIP Enabled Applications.
An additional object of the present invention is to provide administrators of SIP Enabled Applications with the flexibility to define where and how SIP calls are handled.
Yet another object of the present invention is that it allows every SIP subscriber to receive notification of calls on multiple SIP Endpoints.
Still additional object of the present invention is to allow SIP Endpoints to have implicit associations with subscribers.
An additional object of the present invention is to allow subscribers to define the behavior of SIP Endpoints based on call situations.
The foregoing objects are achieved and other features and advantages of the present invention will become more apparent in light of the following detailed description of exemplary embodiments thereof, as illustrated in the accompanying drawings, where:
Generally, under the present invention, users or subscribers of SIP Enabled Applications are able to enjoy advanced features not available in the prior art. A user of a SIP Enabled Device of the present invention enjoys advanced features currently available to users of modern non-SIP based PBX systems. A SIP Enhanced Device of the present invention employs a plurality of SIP Endpoints, thus providing SIP Enabled Applications with the flexibility to coordinate and control multiple aspects of communication resources. Examples of SIP Enabled Devices include telephones, personal computers, and multimedia conferencing systems.
The present invention will now be described in detail with reference to the accompanying drawings. Referring to
The convention used throughout this specification is that a SIP message is shown as a solid line with a single arrow, which indicates the direction of message transmission. The type of SIP message is indicated on the line along with a number in parentheses, which indicates the relative ordering of messages. For example, the line containing “INVITE (1)” is a solid line, so it is a SIP message. Furthermore, it is a SIP Invite message and it is the first message that is sent in the exchange of messages depicted. This SIP message is sent from the SIP Endpoint in subscriber A's SIP Enabled Device to subscriber A's SIP Proxy. Non-SIP messages are shown as a dashed line. For example, the dashed line with “VOICE SESSION (13)” indicates that non-SIP messages are part of the voice session between the SIP Enabled Applications that are executing on the SIP Enabled Devices. The relative ordering of these messages is such that the “VOICE SESSION (13)” messages are sent between the “OK (11)” SIP message and the “BYE (14)” SIP message.
The SIP Enabled Application 504 also interfaces with Network Communications Logic 506 to send and receive non-SIP messages (not shown). Network Communications Logic 506 implements communications protocols that are required to communicate with other network resources. The Network Communications Logic 506 interfaces with Network Interface 507, which is used to physically interface to a network that provides connectivity with other SIP Enabled Devices (not shown).
The following example is provided to illustrate the operation of the exemplary SIP Enabled Device of the present invention that is depicted in
As shown in
In this example, a SIP “Invite” message, which corresponds to message 901, is received by the Voice SIP Endpoint 5051. As a result, message 902 is sent to the SEG 503 indicating the arrival of the SIP “Invite” message. Next, the SEG 503 is programmed to determine if the device is currently in use. Message 903 is sent to the handset switch UIP 5022, which sends message 904 to the SEG 503 indicating that the handset is on the switch. The SEG 503 then sends message 905 to the Voice SIP Endpoint 5051, which causes a SIP “Ringing” message 906 to be sent to the sender of the SIP “Invite” message 901. The SEG 503 also responds by sending message 907 to the ringer UIP 5028, which causes the ringer to ring. The SEG 503 also sets a logical timer (not shown). If the logical timer expires before a user picks up the handset, the SEG 503 will send another message to the ringer UIP 5028 instructing the ringer to stop ringing.
In this example, the user answers the call by picking up the handset before the timer expires. The handset switch UIP 5022 sends message 908 to the SEG 503, which indicates that the handset has been picked up and that the call has been answered. The SEG 503 responds by sending message 909 to the ringer UIP 5028 instructing the ringer to stop ringing. The SEG 503 also responds by sending message 910 to the Voice SIP Endpoint 5051, which causes the SIP “Ok” message 911 to be send from the Voice SIP Endpoint 5051 to the sender of the SIP “Invite” message 901. The SEG 503 also sets a logical timer (not shown) so that an error message can be displayed if no SIP “Ack” message is received when the timer expires.
In this example, a SIP “Ack” message 912 is received on the Voice SIP Endpoint 5051 before the logical timer expires, which sends message 913 to the SEG 503. When SEG 503 detects this event, it sends message 914 to the SIP Enabled Application 504, with information about the voice call session that has just been established.
In this example, Device 1 and Device 2 are identically configured, except the SIP addresses assigned to the SIP Endpoints. The Voice SIP Endpoint and Callback SIP Endpoint on Device 1 are assigned the values “sip:subscriber-A.device-1@siemens.com” and “sip:callback.device-1@siemens.com” respectively. Similarly, the SIP Endpoints in Device 2 are assigned the values of “sip:subscriber-B.device-2@siemens.com” and “sip:callback.device-2@siemens.com.”
Initially, subscriber A picks up the handset on Device 1 and uses the keypad to enter the address for subscriber B. The SEG 503 and the SIP Enabled Application 504 executing on Device 1 have been programmed with the necessary events associated with the handset switch and keypad so that it can be detected when the user has picked up the handset and finished entering the destination address. In response to detecting the completion of these events, the “INVITE (1)” SIP message is sent from the Voice SIP Endpoint of Device 1.
New events are also defined for the Voice SIP Endpoint on Device 1, when the “INVITE (1)” SIP message is sent. One such event is to set a logical timer that is associated with the “INVITE (1)” SIP message. Another event that is defined is the receipt of a SIP “Ringing” message. Another event that is defined is the receipt of a SIP “Ok” message. If the timer expires before a SIP “Ringing” message is received, an error message is displayed on the text display or played in the handset earpiece. If a SIP “Ringing” message is received but not followed by a SIP “Ok” message from the destination of the “INVITE (1)” SIP message, the user is prompted to invoke the callback feature.
Since the “RINGING (8)” SIP message is received by Device 1, but no corresponding SIP “Ok” message is received when the logical timer expires, subscriber A is prompted to determine if she desires to use the callback function. For example, the SEG 503 sends a message to the handset earpiece UIP 5024, which instructs the earpiece of the handset to play a pre-recorded message asking the user of the device to press the callback button if she would like to use the callback feature.
After subscriber A indicates that she desires to use the callback feature by pressing the callback button, she uses her keypad to compose a text message and then presses the callback button again to initiate the callback request. The SEG 503 monitors the keypad UIP 5021 and the callback button UIP 5026 to gather the text entered and to detect when the callback button is pressed again, which indicates that subscriber A has finished entering her text message and return address to use for the callback. When this event is detected by SEG 503, the “INVITE (9)” SIP message is sent from the Callback SIP Endpoint 5052 in Device 1 to the Callback SIP Endpoint 5052 in Device 2.
An event has been defined on Device 2 that corresponds to a successful transfer of Callback Data. When the “BYE (19)” SIP message is received by the Callback SIP Endpoint 5052 on Device 2, this event is detected. A response is performed which sends a message to the callback LED button UIP 5025 instructing the callback LED to illuminate, which indicates to a user of Device 2 that a callback request has been received. Another response is to define an event for the callback button UIP 5026, which corresponds to the depression of the callback button while the LED of the callback button is in an illuminated state.
When subscriber B sees the illuminated LED and presses the callback button on Device 2, these events are detected and in response the callback return address and text message are sent to the text display UIP 5027. This causes the return address and text message to be displayed on the text display of the user interface of Device 2 for a specified period of time. When the user presses that callback button again, which indicates that the user would like to initiate a voice call to the callback address, this event is detected. In response, the “INVITE (21)” SIP message is sent from the Voice SIP Endpoint 5051 on Device 2, which initiates a voice call session with subscriber A at Device 1. The appropriate detections, responses, and new events are defined so that “VOICE CALL SESSION (33)” is completed.
In this example, a one-way voice broadcast feature has been implemented in the SIP Enabled Device 500 that is depicted in
Initially, the Broadcast SIP Endpoint 5052 on Device 1 sends the “INVITE (1)” SIP message to the Broadcast SIP Endpoint 5052 on Device 2. When the SEG 503 on Devices 2 detects the event of receiving the “INVITE(4)” SIP message, it responds by sending the “RINGING (6)” SIP message to the Broadcast SIP Endpoint 5052 on Device 1, which indicates that Device 2 may be willing to participate in the one-way broadcast session. The SEG 503 on Device 2 instructs the Broadcast SIP Endpoint 5052 to send the “OK (9)” SIP message, which indicates that Device 2 will participate in the one-way broadcast.
The SEG 503 on Device 1 detects the “OK (11)” SIP message. In response, the SEG 503 on Device 1 causes the “INVITE (12)” SIP message to be sent, with auto answer enabled, to the Mute SIP Endpoint 5053 on Device 2. The SEG 503 on Device 2 responds by sending a message to the mute button UIP 5026, which prevents the microphone from functioning. The SEG 503 on Device 2 also responds by sending the “OK (17)” SIP message.
Similarly, the SEG 503 on Device 1 causes the “INVITE (21)” SIP message to be sent, with auto answer enabled, to the Speaker SIP Endpoint 5054 on Device 2. The SEG 503 on Device 2 responds by sending a message to the speaker button UIP 5025, which activates the speaker. The SEG 503 on Device 2 also responds by sending the “OK (26)” SIP message.
When the SEG 503 on Device 1 detects the “Ok” SIP messages from the Speaker and Mute SIP Endpoints on Device 1, it responds by sending the “ACK (20)” SIP message, the “ACK (29)” SIP message, and the “ACK (30)” SIP message to Device 2. The SEG 503 on Device 1 also responds by setting up a voice call, by sending the “INVITE (31)” SIP message from the Voice SIP Endpoint 5051 on Device 1 to the Voice SIP Endpoint 5051 on Device 2.
Once the voice session is set up, “BROADCAST SESSION (40)” data is sent from the SIP Enabled Application 504 on Device 1 to the SIP Enabled Application 504 on Device 2. When the user of Device 1 instructs Device 1 to end the one-way broadcast, Device 1 sends a series of SIP “Bye” messages to Device 2. These messages correspond to the “BYE (41)” SIP message, the “BYE (43)” SIP message, the “BYE (45)” SIP message, and the “BYE (47)” SIP message. When the SEG 503 on Device 2 detects these SIP “Bye” messages, it returns Device 2 to its original state; the speaker is deactivated and the mute is disabled.
One skilled in the art will appreciate that many changes can be made to the exemplary embodiments disclosed without departing from the spirit of the present invention.
