Patent Application
20060004924
This invention relates generally to wireless communications systems and methods and, more specifically, relates to wireless terminals and wireless network nodes that use a Session Initiation Protocol (SIP).
The infrastructure of the Session Initiation Protocol (SIP) is defined in IETF RFC 3261 (Rosenberg et al., June 2002). In general, the SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. The sessions can include Internet telephone calls, multimedia distribution and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.
In “SIP-Specific Event Notification”, A. Roach, RFC 3265, July 2002 (referred to hereafter simply as RFC 3265), there is described a SIP event framework to enable event-based information provisioning to any node in the Internet. This procedure is expected to become a key element within the SIP infrastructure. Examples of this kind of information are presence, location information, content/service availability, or access-controlled SIP events.
As is discussed in RFC 3265, the general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network, and those entities (or entities acting on their behalf) can send notifications when those states change. A typical flow of messages would be:
Subscriptions are expired and must be refreshed by subsequent SUBSCRIBE messages.
Several useful definitions include the following:
AOR: Address of Record
Event Package: An event package is an additional specification which defines a set of state information to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by RFC 3265 that are required to convey such state information.
Notification: Notification is the act of a notifier sending a NOTIFY message to a subscriber to inform the subscriber of the state of a resource.
Notifier: A notifier is a user agent which generates NOTIFY requests for the purpose of notifying subscribers of the state of a resource. Notifiers typically also accept
SUBSCRIBE requests to create subscriptions.
Subscriber: A subscriber is a user agent which receives NOTIFY requests from notifiers; these NOTIFY requests contain information about the state of a resource in which the subscriber is interested. Subscribers typically also generate SUBSCRIBE requests and send them to notifiers to create subscriptions.
Subscription: A subscription is a set of application state associated with a dialog. This application state includes a pointer to the associated dialog, the event package name, and possibly an identification token. Event packages will define additional subscription state information. By definition, subscriptions exist in both a subscriber and a notifier.
As was noted above, the SIP event framework defined in RFC 3265 is intended to enable event-based information provisioning to any node in the Internet. SIP events are used to provide a notification scheme that allows for conveying state changes of a particular resource, or changes of aggregated states relating to a pool of resources, to subscribers for the state information. Examples for this kind of information are presence (see J. Rosenberg, “A Presence Event Package for the Session Initiation Protocol (SIP)”, Internet Draft, Internet Engineering Task Force, (work in progress), January 2003), location information or content/service availability (see, for example, US 2004/0003058 A1, D. Trossen, “Integration of Service Registration and Discovery in Networks”, Ser. No. 10/179,244, filed Jun. 26, 2002). In these cases the resource is the presentity, the location information or the content/service information, and changes to these resources are conveyed to subscribers as event notifications.
An element of the SIP interactivity discussed briefly above is service discovery in SIP event environments. Discovery requests and service availability subscriptions are initiated for services within certain categories or locations. Newly available service agents are supported via registration subscriptions.
The approaches disclosed by the inventor in “Integration of Service Registration and Discovery in Networks”, Ser. No. 10/179,244, filed Jun. 26, 2002, and in “Content and Service Registration, Query, and Notification using SIP Event Packages”, Ser. No. 10/330,146, filed Dec. 30, 2002 are techniques to achieve service discovery and availability in SIP environments. In general, these techniques assume that the SIP event server is a dedicated discovery agent in the discovery environment. The system described by K. Arabshian, H. Schulzrinne, “GloServ: Global Service Discovery Architecture”, paper submission, Columbia University presents an approach for category-based and location-based service discovery in which services are grouped by category (such as “restaurant”) or civic location (such as “New York”), and allow for hierarchical searches by introducing appropriate Domain Name Service (DNS) naming schemes for the environment. This proposed system architecture requires the presence of a dedicated discovery agent.
The availability of SIP technology in many future devices makes it desirable to provide some type of service announcement scheme for services provided by these devices. Further, ordering services according to categories or location is desirable in many scenarios, such as in home environments (devices in certain location, such as living room). However, at least some of the systems mentioned above, as well as the one proposed by E. Guttman et al., “Service Location Protocol Version 2”, Internet Engineering Task Force, RFC 2165, June 1999, assume that a dedicated directory agent exists in the environment. However, the presence of such an agent introduces an additional component into the system that must be implemented and maintained, thereby increasing cost and complexity.
As for a SIP-based solution, it would be desirable to have such category-based/location-based discovery scheme with the same advantages as obtained by using the prior discovery techniques, including integration in SIP environments as well as support for availability notifications, in addition to the plain discovery, without requiring the introduction of a discovery agent as a dedicated element in the environment.
In general, the prior approaches typically rely on central discovery agents to exist in the discovery system, i.e., there is a dedicated element in the network, hosting the service information. This information is queried by user agents, and the results are retrieved. In the inventor's previous U.S. patent applications Ser. Nos. 10/179,244 and 10/330,146 a subscription model is offered that additionally allows for availability information of later published services.
In addition to the foregoing, schemes such as the one described by Yaron Y., Cai, Ting, Leach, Paul, Gu, Ye, and Albright, Shivaun, “Simple Service Discovery Protocol”, Work In Progress, IETF Draft, Oct. 28 1999, do not rely on a dedicated central entity, i.e., the discovery agent. However, they rely instead on the usage of multicast for relaying the discovery messages to every service agent. Since there usually do not exist different multicast groups for particular categories or locations, the discovery request is received by every service agent in the environment. As can be appreciated, this approach can place a heavy burden on the system, in particular with respect to scalability. Hence, this type of system is more optimally targeted at smaller environments, such as home environments, in which such scalability issues do not arise.
A need thus exists, but was not adequately fulfilled prior to this invention, to provide the application of SIP events for discovery/availability functionality, as well as for the support of newly available (newly registered) service agents. The more preferred solution would apply to the forking of subscriptions as defined in RFC 3265, where AORs may be grouped by service categories or locations, without requiring the introduction of a dedicated service discovery agent.
The foregoing and other problems are overcome, and other advantages are realized, in accordance with the presently preferred embodiments of these teachings.
This invention solves the foregoing and other problems by providing in one aspect thereof a method to operate an event notification system that includes at least one event server, at least one device and a subscriber unit. The method includes registering an Address of Record (AOR) of the device with a system registrar for each service category in which the device offers a service, the AOR being based on a service category naming convention; sending a Subscribe message from the subscriber unit to the device for registering to receive an availability notification for a desired service, the Subscribe message comprising a Uniform Resource Identifier (URI) based on the AOR service category naming convention and, in response to a receipt of the Subscribe message, sending an initial Notify message from the device to the subscriber unit, the initial Notify message containing an indication of whether the desired service is currently supported by the device. Registering can further register a further AOR of the device with the system registrar for a location of the device, the further AOR being based on a location naming convention.
In a further aspect this invention provides a device having an interface to a SIP proxy. The device has a controller operable for registering an AOR of the device with the SIP proxy for each service category in which the device offers a service, the AOR being based on a service category naming convention and uses a device Uniform Resource Identifier (URI) as a contact URI. The controller is responsive to a receipt of a Subscribe message originated from a subscriber for subscribing to an “Availability” event package for returning an initial Notify message containing an indication of whether a service is currently available at the device, where the service is specified in the Subscribe message, and if the Subscribe message indicates a non-zero lifetime, for returning a subsequent Notify message in the event that there is a change in the availability of the desired service at the device. The controller may also register a further AOR of the device for indicating a location of the device, the further AOR being based on a location naming convention. In this case the controller can return the initial Notify message to contain an indication of the location of the device, where the location is specified in the Subscribe message.
In a still further aspect this invention provides a domain registrar associated with a SIP proxy for managing registration of at least an AOR of devices associated with a domain, where each AOR includes at least one of an indication of a service provided by the device or a location of the device, in accordance with at least one of an AOR service and location naming protocol. The domain registrar is responsive to a receipt of a Subscribe message from a subscriber for subscribing to the registration state of at least one of the registered AORs, for returning an initial Notify message to the subscriber for indicating a current registration state of the at least one of the AORs, and for returning a subsequent Notify message to the subscriber in response to a change in state of the at least one of the AORs.
In a still further aspect this invention provides a subscriber unit operable in an event notification system, and containing logic to originate a Subscribe message to subscribe to a service “Availability” event package. The logic is responsive to a receipt of an initial Notify message to determine whether a desired service is currently available at a device or devices, where the desired service is specified in the Subscribe message, and if the Subscribe message is originated with a non-zero lifetime indication, to receive a subsequent Notify message in the event that there is a change in the availability of the desired service at the device or devices.
In a yet still further aspect this invention provides a subscriber unit operable in an event notification system, and containing logic to originate a Subscribe message to a SIP proxy that manages registration of at least an AOR of devices associated with a domain. Each AOR includes at least one of an indication of a service provided by the device or a location of the device, in accordance with at least one of an AOR service and location naming protocol. The Subscribe message is for subscribing to a registration state of at least one of the registered AORs. The subscriber unit is responsive to a receipt of an initial Notify message to determine a current registration state of the at least one of the AORs, and to a receipt of a subsequent Notify message to determine a change in state of the at least one of the AORs.
The foregoing and other aspects of these teachings are made more evident in the following Detailed Description of the Preferred Embodiments, when read in conjunction with the attached Drawing Figures, wherein:
The presently preferred embodiment of this invention describes the system and method in the overall context of the SIP event framework, as defined by RFC 3265. Hence, the operation of the event server and subscriber unit described below with respect to
Referring to
In the presently preferred, but non-limiting embodiment of this invention the subscriber 12 is associated with a mobile wireless communications device, such as a cellular telephone, or a personal communicator, or a mobile user or agent such as a computer that is coupled to the network 18 via a wireless link. The network 18 can comprise the Internet.
The subscriber 12 includes logic 12A and is assumed to desire to discover the availability of services or content, as described in further detail below.
The SIP proxies 14 and 16 typically exist for the subscriber 12 as well as for the devices 20, 22, and are responsible for the handling of SIP messages and appropriately forwarding the SIP messages to the specified entity. Note that the SIP proxies 14 and 16 represent a non-limiting embodiment of an entity that provides forwarding of registration, subscription, and notifications, as provided by the SIP event framework specified by RFC 3265. However, other mechanisms could be used as well in other embodiments of this invention. Thus, while the SIP proxies 14, 16 are a presently preferred embodiment, their use should not be construed as a limitation upon the implementation and practice of this invention.
The various logic units, functions and modules that comprise the subscriber 12 and devices 20, 22 can be constructed using hardware, software or a combination of hardware and software. In some cases the logic units, functions and modules can be implemented in whole or in part with computer program code that is locally stored and executed by data processors that comprise the subscriber unit 12 and the devices 20, 22, as well as the SIP proxies 14, 16.
By way of introduction, the invention has three major components or functions, namely registration, subscription, and reaction to changes.
The registration function assumes the presence of a user naming scheme that defines a hierarchy of service categories and locations. The above mentioned K. Arabshian, H. Schulzrinne, “GloServ: Global Service Discovery Architecture”, paper submission, Columbia University, provides an example of such naming scheme. Hence, a hierarchy of categories and locations is assumed, such as “service.CE.cablebox” or “location.us.NY.new_york”. This user naming scheme is combined with the domain information as the service agent's AOR to be used in its registration with the SIP system 10. Hence, a cable box (e.g., Device_A 20 in
Note that the actual naming scheme may be subject to standardization in appropriate standardization bodies. For example, the Universal Plug and Play (UPnP™) forum is one possible candidate for such name standardization within a home environment.
The subscription is based on a SIP event package, named “availability”, according to RFC3265. The request Uniform Resource Identifier (URI) for each subscription, sent by a particular user agent, is one of the AORs based on the naming scheme explained above. For instance, a user agent may subscribe to an event at request URI “sip:location.livingroom@domain”. According to RFC3265 the event package specifically supports forking of subscriptions. Due to the multiple AOR registrations of all devices 20, 22 in the living room, and the forking capabilities of the event package, the subscription is forked to all registered devices in the living room, constituting therefore a location-based discovery (the same occurs for discovery within categories, such as within “cable box”). The particular registered device 20, 22 receives the subscription as a SIP event server, delivering the matching service parameters back to the subscriber 12.
It is noted that after local matching services become available, the device 20, 22 will notify the subscriber 12 appropriately, according to RFC3265, thereby providing a service availability notification.
A user can react to changes in the environment by subscribing to a registration state for a particular AOR according to, for example, J. Rosenberg, “Registration State Event Package”, Work In Progress, IETF Draft, 2003. A notification for such a state constitutes a change in environment, such as the removal or addition of a device 20, 22 in a particular location or category. The subscriber 12 may react to this change with a subscription to the particular location or category. In the case of an existing subscription, the subscription is renewed, automatically forking the subscription to the newly added device 20, 22. In the case of a removal, a current subscriber to the removed device can initiate appropriate actions, such as choosing an appropriate replacement for the removed device.
In accordance with an aspect of this invention, an inter-domain discovery process is supported by subscribing to the particular AOR in the particular domain, e.g., a user in enterprise A can subscribe to “sip:service.projectors@enterpriseB.com” to determine information concerning the projector equipment in enterprise B. Access authorization policy approaches, such as XCAP (an Extended Mark-up Language (XML)-based Configuration Access Protocol) can be used to restrict access for visitors in order to the preserve privacy of the service data (e.g., the user in enterprise A may only discover the projector equipment in Enterprise B if duly authorized to do so).
In the system 10 of
The SIP proxies 14, 16 exist for the subscriber 12 and the Device_A 20 and Device_B 22 (possibly different for each) and are responsible for the handling of SIP messages, such as by appropriately forwarding them to the specified entity. Note that in the exemplary home environment scenario, the SIP proxy for the subscriber 12 and for Device_A 20 and Device_B 22 would typically be the same (i.e., the subscriber 12 and the Device_A 20 and Device_B 22 would all be connected to the same SIP proxy).
An aspect of this invention is the definition of an event package (compliant to RFC3265) that is referred to for convenience, and not by way of limitation, as “Availability”. The characteristic (or description) of the service is included in the body of the subscription or notification. RDF and XML are both suitable candidates for use in describing the service.
According to RFC3265 the event package explicitly supports forking of subscriptions with the request URI being the destination of the event subscription, i.e., the AOR of the SIP event server.
In accordance with a further aspect of this invention there is a naming scheme for the device 20, 22 AORs that is based preferably on a category and location hierarchy. K. Arabshian, H. Schulzrinne, “GloServ: Global Service Discovery Architecture”, paper submission, Columbia University, gives an example for such hierarchy. For example, AORs can be constructed such as:
“sip:location.livingroom@myhome.com” can be used for location-based registration; or “sip:service.cablebox@myhome.com” can be used for category-based registration. Hierarchies as outlined by K. Arabshian et al. can be constructed as well, thereby implying recursive application of this invention, e.g., registration and subscription to upper and lower hierarchy AORs, respectively. However, for the sake of simplicity, the ensuing description assumes the use of a flat hierarchy, as such a flat hierarchy is very likely to be present in small, contained environments such as home environments.
Each device 20, 22 in a particular SIP environment needs to register to the SIP environment, according to J. Rosenberg et al, “SIP: Session Initiation Protocol”, RFC 3261, July 2002. In order to be discovered as a service agent in the SIP environment, the device 20, 22 additionally registers, according to RFC3261, within each service category in which it offers services. Further, it is possible to register based on its location, if such information is available. While the category (e.g., projector, or cable box) is usually known to the device 20, 22, the location may be entered during the initial configuration of the device, using a user interface (e.g., location=Conference Room A, or Living Room). It is also possible to use automatic means of determining the location, such as indoor location beacons or RFID tags, and thus the devices 20, 22 may each include some type of location determination (LD) device or function 20B, 22B.
During the registration of the device 20, 22 as a service agent, the different AORs (for each supported service category and the location) are registered with the local SIP proxy (e.g., 16 in the case of
For example, a cable box in the living room with URI “sip:pc27@myhome.com” would register two AORs, namely:
“sip:location.livingroom@myhome.com” for location-based registration, and “sip:service.cablebox@myhome.com” for category-based registration, with “sip:pc27@myhome.com” as the contact URI, according to RFC3265.
Note that, in order to be reachable, the device 20, 22 would also register its own AOR with the SIP system. However, this registration is not germane to an understanding of this invention.
A description is now made of the discovery request and availability subscription aspects of this invention.
The subscriber 12 sends a SUBSCRIBE (message 1 in
It is assumed that Device_A 20 and Device_B 22 in
Since both devices, Device_A 20 and Device_B 22, registered the chosen request URI as their AOR, the subscription requests are forked, according to RFC3261 and RFC3265, and sent to both devices 20 and 22 (shown as messages 3 and 4 in
According to RFC3265, the Device_A 20 and Device_B 22, acting as SIP event servers 20A, 22A, respond with an Acknowledgment as to whether the subscription is granted. Such a decision may be based on the support of the event, or the access rights of the subscriber 12. With the latter, the privacy of the service data is preserved, in particular for scenarios in which visitors have access to the service data, either locally (visitor scenarios in local environments) or remotely (potential visitor in domain A desires to find services in domain B). For such access rights support, existing access authorization policies may be used.
Device_A 20 and Device_B 22 both respond according to RFC3261 and RFC3265 with a reason code (‘200OK’ if accepted), shown as message 5 and message 8 in
Note that due to the concurrent character of the message delivery in the Internet 18, the message sequence in
If the subscription has been a “one-shot” subscription according to RFC3265, i.e., its lifetime has been defined as zero in the subscription request, the steps described above can be seen to constitute a simple discovery request. Hence, there is no subscription established at the SIP event servers 20A, 22A of Device_A 20 and Device_B 22, respectively.
However, in the case where the lifetime of the subscription request is defined as non-zero, a proper subscription is set-up at the SIP event servers 20A, 22A, according to RFC3265. With this subscription, if the service availability at any of the subscribed devices 20, 22 changes in the future, the SIP event server 20A, 22A of the affected device 20, 22 matches the newly available service with the existing subscriptions. If a match is found to exist, an appropriate notification is sent to the subscriber 12. This is shown in
With these steps, the subscriber 12 obtains knowledge of available services in a particular category or location, expressed through the particularly selected AOR.
It is often the case that environments that include service-providing devices, such as the devices 20 and 22 in
The preferred embodiment of this invention accommodates such changes in the manner described below.
The devices 20, 22 in the SIP environment register with the local SIP proxy 16 when powered on (and time out when they are powered off). Further, as explained above, the registered AOR constitutes the service category and location of the device.
Hence, a subscriber (which is not necessarily the same subscriber that subscribes to the services as in
The subscriber 12 sends a SUBSCRIBE to the registration state (message 1 in
After accepting the subscription (otherwise, an error code is returned according to RFC3265), the registrar 16A of the SIP proxy 16 responds with a ‘2000K’ back to the subscriber 12 (message 3 in
According to RFC3265, the registrar 16A of the SIP proxy 16 sends an initial NOTIFY to the subscriber 12 (message 5 in
If Device_A 20 is subsequently powered on at some point in time, it performs the registration steps explained above, shown as message 7 and message 8 in
Note that also powering off a device may beneficially trigger a notification if a subscriber had subscribed to the state of the device. This notification would indicate the removal of the device. In this manner the preferred embodiments of this invention are enabled to cope with changes in the SIP environment.
Based on the foregoing description it should be apparent that an advantage of the use of the preferred embodiments of this invention is the removal of a dedicated discovery agent from the system 10, without also requiring the introduction of a multicast-based system. This is preferably achieved by using the service category and location AORs in a defined naming scheme, with the support of the forking of SIP event subscriptions. The system in accordance with the invention readily integrates into the existing SIP framework, i.e., no changes are required apart from standardizing the naming scheme and the event package according to the preferred embodiments of this invention.
Another advantage is that the preferred embodiments of this invention easily enable remote service discovery by simply subscribing to AORs in foreign domains. Existing access authorization policies can be used to securely reveal service data in such cases.
The preferred naming scheme defines the granularity of service categories and therefore defines a design parameter for the scalability of the approach, together with the general local character of the invention (since the registrations happens at the local SIP proxies, this allows for spreading the load among different SIP proxies).
For a case where category-based discovery may lead to requests sent to devices that do not necessarily provide matching services, finer-grained naming hierarchies can be employed, possibly in conjunction with recursive application of the invention.
In accordance with exemplary embodiments of this invention the problems present in the prior art are solved by applying category and location-derived AOR registration of devices, and the forking of discovery subscriptions to the contact addresses for a particular AOR (for a particular category or location). The exemplary embodiments of this invention additionally provide a system and method that notify interested parties of newly available service agents in particular categories or location, and accommodate variability in the SIP environment.
Furthermore, the combination of the exemplary embodiments of this invention with a naming scheme similar to the one described in K. Arabshian et al. would permit for hierarchical discovery to occur.
The exemplary embodiments of this invention enable location-based discovery through simple static configuration of service agents, and also allow for automatic determination of location information.
Further, the exemplary embodiments of this invention readily allow for foreign domain service discovery, assuming an adoption (e.g., through standardization) of the naming scheme for the service categories and locations, by simply subscribing to foreign domain AORs. Existing access authorization policy approaches (such as XCAP) can be used to control access to these services from foreign domains.
The foregoing description has provided by way of exemplary and non-limiting examples a full and informative description of the best method and apparatus presently contemplated by the inventor for carrying out the invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. As but some examples, the use of other similar or equivalent message type and formats, resources and network architectures, may be attempted by those skilled in the art. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention.
Furthermore, some of the features of the exemplary embodiments of this invention could be used to advantage without the corresponding use of other features. As such, the foregoing description should be considered as merely illustrative of the principles of the present invention, and not in limitation thereof.
This patent application is related to the following commonly assigned U.S. patent applications: D. Trossen, “Integration of Service Registration and Discovery in Networks”, Ser. No. 10/179,244, filed Jun. 26, 2002; D. Trossen, “Content and Service Registration, Query, and Notification using SIP Event Packages”, Ser. No. 10/330,146, filed Dec. 30, 2002; D. Trossen, K. Mehta, “Access Control Alert Method using SIP Event Package”, Ser. No. 10/353,014, filed Jan. 29, 2003; D. Trossen, “Querying for SIP Event Packages by Using SIP OPTIONS Method or by Using Service Discovery”, Ser. No. 10/418,313, filed Apr. 18, 2003; D. Trossen, D. Pavel, “Application Semantic Binding through SIP Event Package Template”, Ser. No. 10/465,455, filed Jun. 19, 2003; to U.S. patent application Ser. No. 10/______ filed ______, “Method, System and Computer Program to Enable Querying of Resources in a Certain Context by Definition of SIP Event Package”, by Dirk Trossen and Dana Pavel; and to U.S. patent application Ser. No. 10/______, filed ______, “Method, System and Computer Program to Enable Semantic Mediation for Sip Events Through Support of Dynamically Binding to and Changing of Application Semantics of Sip Events”, by Dirk Trossen and Dana Pavel, the disclosures of which are incorporated by reference in their entireties.
