WO2006029645A1 - A method and system of interaction between entities on a communication network - Google Patents

A method and system of interaction between entities on a communication network Download PDF

Info

Publication number
WO2006029645A1
WO2006029645A1 PCT/EP2004/010419 EP2004010419W WO2006029645A1 WO 2006029645 A1 WO2006029645 A1 WO 2006029645A1 EP 2004010419 W EP2004010419 W EP 2004010419W WO 2006029645 A1 WO2006029645 A1 WO 2006029645A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
sip
machine
readable
description
Prior art date
Application number
PCT/EP2004/010419
Other languages
French (fr)
Inventor
Laurent Walter Goix
Hélène RADIGOIS
Original Assignee
Telecom Italia S.P.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telecom Italia S.P.A. filed Critical Telecom Italia S.P.A.
Priority to EP04765317A priority Critical patent/EP1790143A1/en
Priority to PCT/EP2004/010419 priority patent/WO2006029645A1/en
Priority to US11/663,060 priority patent/US8775640B2/en
Publication of WO2006029645A1 publication Critical patent/WO2006029645A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • the present invention relates to the access from users to services or resources over the Internet, and particularly to the interaction between entities on a communication network through SIP (Session Initiation Protocol) .
  • This invention relates in particular to the access to ses ⁇ sion- and subscription-based services through SIP (Session Initiation Protocol) .
  • transaction-based services e.g. e-commerce
  • information services e.g. web browsing
  • session-based services e.g. video streaming, inter-personal multimedia communication
  • subscription-based services e.g. get updated about presence information
  • messaging-based services e.g. instant messag ⁇ ing
  • Session Initiation Protocol (as avail ⁇ able in the Request for Comments collection, RFC3261, by J. Rosenberg et al . , on June 10, 2004 at the complete URL http://www.ietf.org/rfc/rfc3261.txt) that provides a way to establish and control multimedia sessions over IP, as well as a framework for event notification and subscription manage ⁇ ment (SIP event framework) called Session Initiation Protocol (SIP) -Specific Event Notification (as available in the Re ⁇ quest for Comments collection, RFC3265, by A. B. Roach, on June 10, 2004 at the complete URL http://www. ietf.org/rfc/rfc3265.txt) .
  • SIP Session Initiation Protocol
  • SIP-enabled multimedia communications include, but are not limited to, , audio/video, data, messaging and event notifica ⁇ tion (such as presence) communications between two or more entities.
  • SIP protocol defines several types of methods (SIP methods) and related text-based messages' (hereinafter SIP messages) between two entities, typically a client application and a server.
  • Each type of SIP method defines a different service model .
  • SIP has, amongst others, service model types of: - session (using the INVITE SIP method) ;
  • SIP protocol defines some ba ⁇ sic message interactions between clients and servers, includ ⁇ ing message type and format.
  • a SIP message includes some re ⁇ quired information (for example some SIP headers) and can be extended with optional information depending on the SIP method and the service to invoke.
  • a user wishing to view a movie trailer would typically require its client application to use an INVITE method and to send an INVITE message to start a video session with a movie server.
  • a user willing to be updated with information e.g. about local weather, will use a SUBSCRIBE method by triggering a SUBSCRIBE message from its client application to a server, e.g. a weather forecast server.
  • SIP URI SIP Uniform Resource Identifier
  • sip:weatherOmycompany.com and specifies that the SIP "SUB ⁇ SCRIBE” method has to be used and that an "Event” header with value "weather” and a “P-City” header with value "turin” have to be inserted in the SIP SUBSCRIBE message.
  • the client application associated with SIP hyperlinks of the type SIP-URIs constructs the SIP message with all these parameters, confident that it is exactly the format expected by the service.
  • the input SIP message can be sent to the ser ⁇ vice and be processed at the server location in the right way.
  • the client application does not know the exact seman ⁇ tics of the answer from the service a priori without invoking the service and actually receiving the answer.
  • the client application will see what the re ⁇ sponse format is only when it receives a response from the service it has invoked. Moreover, the comprehension of output data and parameters sent by the server to the client application may not be trivial, since some information can be included in headers or body of the SIP message and unknown to the user.
  • a SIP client application may not handle and process answers coming from a server automatically and/or correctly. This means that a SIP client application needs to conform to the answer it is going to receive.
  • the above mechanism does not allow defining op ⁇ tional information that may or may not be sent by the client application when invoking the service.
  • the above mechanism explicitly applies for a single service provider entity (responding at the specified SIP URI) and not to a plurality of provider entities or services.
  • CPL Call Processing Lan ⁇ guage
  • the SIP Servlet is a Java-based service logic executing on a SIP server that can listen to SIP messages coming from cli- ents .
  • the SIP servlet specification defines deployment de ⁇ scriptors for SIP servlets: these descriptors are XML-based files stored locally on a server that map an input filter based on a SIP message with a predefined SIP servlet.
  • a SIP servlet container checks whether the message matches a filter defined in a descriptor. If so, the servlet container automatically triggers the service logic that cor ⁇ responds to the matching filter in the descriptor.
  • SIP event framework defines service model of asynchronous notification in subscription-based services, i.e. it allows a client application to subscribe to event oc ⁇ currences during a certain period of time and to be dynami ⁇ cally notified by a server of each event occurrence during the period.
  • the notification is sent by the server at times decided by the server.
  • SIP event framework suggests that the notification comprises data formatted according to a so called "SIP event package" .
  • SIP event framework suggests the same approach for sub ⁇ scription to event occurrences.
  • SIP event framework is explicitly independent from the actual service data that is requested by the client, so that these mechanisms are open to apply to notification of any kind of event and related service data, for example online discov ⁇ ery/retrieving of specifications and/or availability informa ⁇ tion regarding the services currently provided by a server.
  • the above method explicitly refers only to event packages de ⁇ scription provisioning from a server to a client.
  • the WO 2004/059502 Al and US 2004/0153547 fail to teach how a client application will receive answers by a server when in ⁇ voking a service, it neither teaches how answered informa ⁇ tion is organized.
  • a user wishing to be updated with information about local weather, and subscribing at a server to. a weather forecast service will neither know how notification will oc ⁇ cur, i.e. it will not be informed about the type, format, output parameters and transport protocol of the answer he should receive, before the notification itself, nor when up ⁇ dating information will be sent by the server.
  • Applicant believes that the closest prior art related to SIP session- and subscription-based services fails to make available standard ways of describing how to invoke a SIP service, receive and understand the response.
  • Current so- lutions to describe the operation or the invocation of such a service only cover a single aspect of this interaction, i.e. the input interaction between a client application and a server, but fail to teach how the server is going to act in response.
  • the aim of the present invention is therefore to provide a method and a system of interaction between entities through the SIP protocol to ease invocation of a service.
  • the invention seeks to provide a solution to cor ⁇ rectly invoke and understand session- or subscription-based services on SIP protocol .
  • a further object of the invention is also to provide a solu ⁇ tion for retrieving information at the client ' s side regard ⁇ ing the services currently provided by one or more servers, and being updated in real-time of any changes in service specifications and/or availability.
  • the invention provides a service invocation mechanism to formally describe at least session- and subscription-based SIP services, including the provision of a service descrip- tion or formalism intended to describe input and output mes ⁇ sage formats for invoking a SIP service and understanding its response on the side of the client application.
  • the service description includes the format specification of input and output messages as a set of abstract rules defin ⁇ ing the message structure (in terms of attributes and pa ⁇ rameters) for said service, and the implementation of those rules (binding) on the SIP protocol, for example indicating a list of entities, which provide this service.
  • the service description provided according to the invention in ⁇ cludes some semantic information about the service, as for example information helping to identify the type of service requested (e.g. weather-related service) as well as the mean ⁇ ing of the parameters associated with the service.
  • the invention envisions the use of extensions of Web Service Description Language (WSDL) to add support to session and subscription mechanisms and support binding for the SIP protocol and format.
  • WSDL Web Service Description Language
  • the first version of WSDL has been defined by The World Wide Web Consortium in March 2001, and periodic updates have been made until the last version, WSDL 2.0, in November 2003 (pub- lished at the complete URL http://www.w3.org/2002/ws/desc/, as retrieved on June 10, 2004) .
  • the method and system according to the invention make use of the service description for a client application both to in- voke a service to the relevant SIP Uniform Resource Identi ⁇ bomb and to know a priori the expected answer, i.e. know where and how the parameters of invocation and response would or could be transmitted in the SIP request line, header or body of the exchanged SIP messages.
  • the availability of a common formalism to de ⁇ scribe every aspect of a SIP service allows a client application to correctly interact with a service provider or another client application and be updated in case of dynamic creation and provision of ser ⁇ vices so as in case of modification of service parameters.
  • the invention proposes also a new mechanism for real-time no ⁇ tification of service availability, interaction rules and providers.
  • the architecture of this mechanism envisions a client appli ⁇ cation that is interested in getting updated about service description and availability. Updates are provided by a reg ⁇ istry, which stores service-related information and maintains a state for each client application. Service description and availability is published by the service provider using a publication interface on the registry, or by a further entity on behalf of the service provider. Each time a change occurs in the registry that may be triggered by a new publication from a service provider, the registry will notify the inter- ested client applications if the change matches their sub ⁇ scription filter, if any.
  • subscriptions will provide informa ⁇ tion on new, changed or deleted entities within a registry as they occur during the whole subscription duration.
  • the invention can be used to deliver updates to client appli ⁇ cations (including but not limited to end-user applications) either pushing or allowing them to download updated machine- readable descriptions of available services without requiring any intervention from the user itself. It is to note that the information provided in notifications is related to service interaction description and is independent from the service data that may be retrieved when invoking the described ser ⁇ vice.
  • a client entity (a user or network application or resource, commonly and herein ⁇ after referred to as “client (subscriber) application”) is allowed to subscribe to a notification service providing a single service description and be dynamically notified about it, for example on how and where to invoke the service and how to interpret the expected answer, if any.
  • client (subscriber) application a user or network application or resource, commonly and herein ⁇ after referred to as “client (subscriber) application
  • client (subscriber) application is allowed to subscribe to a notification service providing a single service description and be dynamically notified about it, for example on how and where to invoke the service and how to interpret the expected answer, if any.
  • client (subscriber) application is allowed to subscribe to a notification service providing a single service description and be dynamically notified about it, for example on how and where to invoke the service and how to interpret the expected answer, if any.
  • This includes as well a mechanism to query and fetch a single service de ⁇ scription, and allows the client application to be
  • the actual service de ⁇ scription may be sent inline or indirectly and referenced us ⁇ ing some pointer to a network-based server which hosts the service description, for example through a URI.
  • Subscriptions or queries may include filters to refine the service descrip ⁇ tion notified to the subscriber application.
  • the subscriber application is allowed to subscribe to a list of service de- scriptions, explicitly (by requesting a known list of ser ⁇ vices) or implicitly (by requesting an unknown list of ser ⁇ vices) , and being dynamically notified about every single service description.
  • Subscriptions or queries may include filters to refine the service description notified to the subscriber application.
  • the invention also defines a way for a service provider server, or a resource on behalf of it (hereinafter referred to as "publisher"), to publish the description of one or more services to at least one other entity (network-based re ⁇ source) .
  • publisher a service provider server, or a resource on behalf of it
  • a system to aggregate service descriptions from more network-based resources to optionally obtain a list of re ⁇ sources that provide a similar service, and to compose a new description of the service.
  • Figure 1 is a block diagram of a functional architecture for session- and subscription-based SIP service ' s invocation by a client, according to the invention
  • Figure 2 is a block diagram of a functional architecture for service description notification to a client
  • Figure 3 is a flow chart of the notification mechanism of a single service description according to the invention.
  • Figure 4 is a flow chart of the notification mechanism of a list of service descriptions according to the invention.
  • Figure 5 is a message sequence chart of a service de ⁇ scription publication and notification mechanism.
  • the functional architecture related to a typical access sce- nario to a session- or subscription-based SIP service is shown in figure 1.
  • a client entity C such as a client application, wishing to invoke a session or subscription SIP service S is connected to a service provider or server SP over a direct network- based communication link Li nvoke -
  • a service description pro ⁇ vider DP which provides a service description D for service S, is arranged to be coupled to, for instance, a web server WS over a direct network-based communication link L pu bii S h/ the web server WS being intended to publish a SIP service de ⁇ scription D supplied by service description provider DP.
  • the client application C is arranged to be connected to web server WS to retrieve published service description D over a direct network-based communication link L retr i e ve-
  • the service description provider DP may be coupled to the service pro ⁇ vider SP.
  • the service provider SP is asso ⁇ ciated to a SIP server, but, according to further embodiments of present invention, the service provider SP may also be an ⁇ other client application.
  • a typical client application includes a set of computer pro ⁇ gram modules for performing network operations such as access to remote resources or services.
  • SIP-based services can be invoked sending a SIP message from client application C to the service provider SP or to another client application.
  • SIP protocol defines several types of message between a cli ⁇ ent application C and a server SP, and each type of message defines a different service model.
  • SIP has, amongst others, concepts of session (instantiated by the INVITE method) , of subscription (SUBSCRIBE method) , and of asynchronous notifi ⁇ cation (NOTIFY method) .
  • INVITE method instantiated by the INVITE method
  • SUBSCRIBE method subscription
  • NOTIFY method asynchronous notifi ⁇ cation
  • SIP envisions two types of messages: requests and responses.
  • SIP requests can be initiated both by client ap ⁇ plications and servers.
  • SIP responses are triggered by SIP requests and can also be sent both by client applications and servers.
  • client ap ⁇ plication as the entity sending a request
  • server or service provider as the entity receiving the request and sending a response
  • a SIP message is composed of 3 sections: - a SIP Request-Line, which contains the SIP method (e.g. INVITE) and the SIP Request-URI, which is used for SIP message routing between the client application C and its fi ⁇ nal destination (e.g. the server SP) ;
  • SIP method e.g. INVITE
  • SIP Request-URI SIP Request-URI
  • a SIP message can include a message body; when present, the body corresponds to a specific MIME con- tent, whose type is described in the SIP "Content-Type:" header.
  • service description pro ⁇ vider DP publishes a service description D of the SIP service S provided by service provider SP, e.g. by making it avail ⁇ able at web server WS through link L pub ii S h.
  • client application C Prior to actually invoking the service S at service provider SP, client application C first retrieves service description D, e.g. from server WS through link L retr i eve/ according to a mechanism independent from the service (e.g. through HTTP re ⁇ quest to web server WS) .
  • service description D e.g. from server WS through link L retr i eve/ according to a mechanism independent from the service (e.g. through HTTP re ⁇ quest to web server WS) .
  • the service description D give ' s information to the client ap- plication about where and how to invoke the service, and also about how the service will answer remotely to the applica ⁇ tion. It includes, but is not limited to, a machine-readable description including specifications of interaction between a requesting entity and a responding entity, said specifica- tions comprising at least a set of rules describing required and/or optional input and output message formats and their actual implementation over (binding with) SIP protocol for accessing a service S supplied by provider SP.
  • the service S can be a session-based or sub- scription-based service, i.e. a service, which needs an ex ⁇ plicit request/invocation by the client, which related ser ⁇ vice data is supplied over a protracted time and which is concluded by an explicit termination.
  • service supplied over a protracted time is intended as a service where at least one of the actions of sending and receiving service data between entities involved in the service is protracted over time: - either continuously (as in a session-based service, where the action of sending and/or receiving service data is con ⁇ tinuous in time) , or intermittently (as in a subscription-based service, where the action of sending and/or receiving service data is plural and executed at different points of time, e.g. on a periodic basis) .
  • a service supplied over a protracted time is intended as op ⁇ posed to a service of the type "request-response", where a single instant request is answered with a single instant re- sponse and the action of sending and/or receiving service data is executed only once at a specific point of time.
  • the generic type of service e.g. a subscription, a session, etc.
  • the model of service i.e. the interaction(s) between the requesting entity and the responding entity (e.g. "in- multi-out") ;
  • Session-based services have specific concepts addressed, such as :
  • the session description in terms of media (e.g. au ⁇ dio, video, application or data) , protocols, codecs, etc.;
  • Subscription-based services also have specific concepts ad ⁇ dressed, such as:
  • the service description may include human-readable description and/or se ⁇ mantic information related to the service, for example de ⁇ scribed in OWL (Ontology Web Language) .
  • OWL Ontology Web Language
  • the service description formalism disclosed in the following description for session- and subscription-based services making use of SIP as a trans ⁇ port protocol is defined extending WSDL syntax to add support for such services through a SIP binding that answers to ser ⁇ vice description requirements listed in the previous section.
  • syntaxes completely different from that of WSDL may be generated without affecting the inventive principles of the present invention.
  • WSDL which is a language well known to a man skilled in the art and therefore need not to be discussed in detail in the present application
  • the verb attribute defined in the HTTP binding of the WSDL specification is reused to specify the type of SIP- message to be used in the service interaction.
  • this attribute is used only at binding level in WSDL specifi ⁇ cation, the present invention defines it also at message level .
  • service-related parameters can be speci ⁇ fied in the SIP Request-URI, in a header or in the body of the message.
  • the way in which the input (from client of server) and output (from server to client) parameters are exchanged between the SIP client application and the SIP server must be defined clearly, so that the client applica ⁇ tion knows where to find the information included in the SIP messages, and how to interpret it correctly.
  • a message element is defined to select a message format (SUB- SCRIBE, NOTIFY, INVITE, ...) and the way the input and output parameters are going to be transmitted. This element is placed inside the input and output elements of the binding's operation.
  • the verb attribute is used to specify the message format . This attribute would assume any value, so that the output message could be transported either by a SIP request or by a
  • SIP response In case of a SIP request, the value corresponds to the SIP method to be used (e.g. "INVITE", "SUBSCRIBE") . In case of a SIP response, the value "response" is used.
  • This attribute is not required in the message element if a default attribute ⁇ verbDefault) is defined in the operation and binding elements. However, each message must have a verb or verbDefault attribute defined. If a verbDefault attribute is defined and the message element includes a verb attribute, then only the latter value has to be considered.
  • the uristyle attribute is used whenever there is the need to send service-related parameters (parts) within the SIP Re ⁇ quest-URI. This attribute should not be present if all parts are to be sent within the SIP message body or a SIP header.
  • parts can be replicated both in the SIP Request-URI and in a SIP header or the SIP message body if necessary.
  • the location attribute defines a pattern of parts to use to extend the SIP Request-URI. No meaning is currently associ ⁇ ated to this attribute when used with "urlEncoded" value of uristyle attribute.
  • message parts can be sent either in the SIP message body or in a SIP header. Since message body format and header names are exten ⁇ sible, specific elements are defined to clearly describe how each part of the message will be transmitted.
  • SIP message body when present, must pertain at a MIME type.
  • parts inserted into the SIP message body can be de ⁇ fined following the MIME binding for WSDL or through another mechanism.
  • XML-based content can be inserted as:
  • the contentXml element defines how to insert an XML-based part into the SIP message body.
  • the part attribute references the name of the part in the message to be sent, which type may refer to an external XML type in an external XML namespace.
  • the type attribute defines the MIME type of the XML content.
  • the header element defines how to insert a message part into a SIP header, and its structure is:
  • the part attribute references the name of the part in the message to be sent.
  • the name attribute defines the name of the SIP header that will contain the value of the part.
  • the required attribute specifies whether this header is re ⁇ quired for the correct processing of the message.
  • the binding element defines the mapping of a service model on a specific transport protocol that will be used to transport the input and output messages, if any.
  • the flexibility of the solution is guaranteed by the fact that the output can be none, one or multiple and that it can be transported by both a SIP request and a SIP response.
  • a verbDefault attribute is added to provide a default format for a specific operation or binding, in order not to have to specify it in all messages.
  • style and styleDefault attribute are added to specify a standard SIP behavior, such as "session”, "sub ⁇ scription” or “rpc” (Remote Procedure Call) .
  • These defini ⁇ tions implicitly define message verbs, message exchange and simplify the definition of a service.
  • the "sub ⁇ scription” style would implicitly correspond to an exchange of "SUBSCRIBE” messages in input and ⁇ multiple "NOTIFY" mes ⁇ sages in output in an asynchronous way for a SIP-based sub ⁇ scription service.
  • styleDefault attribute with binding owner applies when no style attribute with operation owner applies.
  • the transport attribute with binding owner aims to know which protocol will be used to access the service. It references a URI that points to the document that describes the transport protocol to use.
  • the location attribute with operation owner defines the de ⁇ fault SIP URI parameter pattern to apply by default to all request messages exchanged within this operation.
  • the operation owner are defined two extra attributes spe ⁇ cifically related to subscription-based services: minDura- tion and event.
  • the event attribute specifies to which event the subscription is related.
  • the minDuration defines the minimum subscription duration (e.g. in seconds) accepted by the service.
  • a section is provided in a WSDL document, which defines in particular the URI where the service has to be invoked.
  • WSDL standard accepts any kind of URI format as contact point. However, an extension is described here to support definition of patterns of SIP URIs.
  • an address element is added to the syntax for SIP-based services to identify the SIP resource where the service is located.
  • the value of the location attribute can represent a single SIP URI or a pattern that can define a number of SIP URIs at which the described service can be invoked by the client ap ⁇ plication.
  • location value of "sip: 0039 [0-9] *@mycompany.com” specifies that the service is supported by any SIP resource, whose SIP URI starts with “0039” and belongs to the "mycom- pany.com” domain, while other SIP URIs may not support the service.
  • a subscription-based service is de ⁇ scribed.
  • the exemplary description defines a meteorology service that can notify a client about weather forecast updates for a specific city.
  • the service defines a single operation (named sub- scribeWeatherForecast) , which requires, as input message, the name of a city (named request) and returns the weather fore ⁇ cast for the given city as output (named response) , as a forecast string associated with an icon.
  • WSDL syntax preferably taken as a model for the SIP service description, first of all, an abstract por ⁇ tion of the description is given, where message names and their parts are defined in a conceptual way, then, in the binding section, a material way is described to invoke the service using SIP as transport protocol.
  • SUBSCRIBE sip:weather@mycompany . com; city turin SIP/2.0 the SIP "SUBSCRIBE” message needs to include a SIP "Event:” header with value "weather” (the type of event) , and a SIP “Expires : " header with value equal or greater than "3600” (the subscription minimum duration in seconds) , i.e.
  • a streaming (session-based) service is described.
  • the exemplary description defines a service providing a way to call a movie server and watch a movie trailer on demand.
  • the service defines a single operation (named stream- MovieTrailer) , which requires, as input message (named re- quest) , the name of the desired movie ("movie” part) and the description of user-side media capabilities ("offer” part) and returns (named response) a description of service-side media capabilities ("answer” part) , then starting the stream ⁇ ing of the movie.
  • WSDL syntax preferably taken as a model for the SIP service description, first of all, an abstract por ⁇ tion of the description is given, where message names and their parts are defined in a conceptual way, then, in the binding section, a material way is described to invoke the service using SIP as transport protocol.
  • binding styleDefault "session” />
  • INVITE sip streaming@mycompany.com SIP/2.0
  • P -Movie The Matrix the service will then answer with a SIP response ("re ⁇ sponse" verb) containing the description of its media capa- bilities in SDP in the SIP message body.
  • a service description is transferred to the client applica ⁇ tion by mean of a network-based communication.
  • This communi ⁇ cation can be a direct communication between the client ap- plication C and the service description provider DP or, ac ⁇ cording to figure 1, an indirect communication between the client application C and the service description provider DP through a server WS .
  • the communication between the client application C and the service description provider DP is indirect when the service description provider DP transfers the service de ⁇ scription D on a web server WS through a network-based commu ⁇ nication in a first step, and the client application C re ⁇ trieves the service description D from the web server WS in a second step through another network-based communication.
  • Figure 2 shows the functional architecture related to a typi ⁇ cal usage scenario of the service description notification method according to the invention.
  • a client entity (hereinafter “subscriber application”) is in- dicated C and a SIP service provider is indicated SP, as in figure 1.
  • Service provider SP offers a SIP service S de ⁇ scribed by an associated service description D provided by service description provider DP, and the subscriber applica- tion may invoke said service S on a direct communication link
  • Subscriber application C is arranged to be coupled to a reg- istry R in uplink for requesting data about current service information through a subscription interface SUBS__I.
  • Registry R is coupled to a service database DB serv storing service in ⁇ formation such as availability and service description D of service S, and a subscription database DB SU bs storing sub- scriptions of subscriber application C.
  • the registry may be a UDDI (Universal Description, Discovery and Integration) registry or a SIP Event Server or any kind of component or group of components that provides at least a publication interface and an inquiry interface and/or sub ⁇ scription and notification interface.
  • UDDI Universal Description, Discovery and Integration
  • SIP Event Server any kind of component or group of components that provides at least a publication interface and an inquiry interface and/or sub ⁇ scription and notification interface.
  • figure 2 shows a single client ap ⁇ plication C and a service provider SP and a related service S, but the following disclosure applies to a general archi ⁇ tecture comprising a plurality of subscriber applications and service providers, each offering one or more services.
  • Registry R is arranged to be downlink coupled to subscriber application C for informing about current service information through a notification interface NOT_I, associated with sub ⁇ scription database DB subs .
  • Service provider SP may be coupled with service description provider DP for providing service description D.
  • the service description provider DP may be part of the service provider SP or, according to further embodiments, standalone.
  • Service description provider DP is arranged to be coupled to a publisher entity PUB.
  • service description pro ⁇ vider DP may also be coupled to a publication server PS for storing service description D.
  • the publica ⁇ tion server PS may receive service description D from the publisher entity PUB itself or from registry R, as shown in broken lines. Registry R is also connectable to publisher en ⁇ tity PUB by means of a publication interface PUB_I .
  • the pub ⁇ lisher entity PUB may be part of the service description pro ⁇ vider DP or standalone.
  • the publication server PS (e.g. a web server) may be part of the publisher entity PUB, the service description provider DP or the registry R, or it may be a standalone entity.
  • Service information can be related to the availability of a service, service-specific information or to a service description D of remote interaction mecha- nisms that can be used by subscriber applications, for exam ⁇ ple for GUI automatic generation or some automated action.
  • Notifications as defined in the invention may contain the re ⁇ lated information inline or may contain a pointer to a re- source providing the information, or may not carry any re ⁇ lated information other than the event occurrence itself.
  • the subscriber application C requests the registry R to be notified about information related to the service S through the subscription interface SUBS_I, optionally including fil ⁇ tering parameters about notification conditions or informa ⁇ tion filtering (e.g. the application is interested in all no ⁇ tifications but only in part of the information) .
  • the registry R stores the subscription into subscription da ⁇ tabase DB subs , and may check immediately about current infor ⁇ mation related to the requested service in service database DBs erv If some information is found in the service database and if the service information matches optional rules and filters provided by the subscriber application C or applied by the registry R, the registry R sends a notification to the subscriber application C through the notification interface N0T_I, informing the subscriber application C about the cur ⁇ rent service information.
  • This notification may include the actual service information or a pointer to it, and in par ⁇ ticular it may include service description D or a pointer to it on publication server PS (e.g. a HTTP URL) .
  • the subscriber appli ⁇ cation C may automatically download the service information and/or service description D from publication server PS and process it, for example to generate a GUI to display to the user.
  • the subscriber application may further invoke the service S based on such description information, using the SIP SERVICE message, HTTP, SOAP or any other SIP or other network-based communication protocol message.
  • the service provider SP that provides service S, or an external entity on behalf of it may publish over a network some information about the service S, for example when the service becomes available, whether its description has been updated, or based on external conditions.
  • the service description provider DP asks pub ⁇ lisher entity PUB to publish the service description D by either sending the actual service description D, which is defined according to the invention, to the publisher entity PUB, or by sending a pointer to the service description D which can be retrieved from the publication server PS. Either way, the publisher PUB can further store the service descrip ⁇ tion D on publication server PS.
  • the publisher entity PUB sends the service information (con ⁇ taining the service description D or a pointer to it) to the registry R through publication interface PUB_I, asking the registry R to store this service information into the service database DB serv
  • Service information- publication can be done using SIP PUBLISH message, HTTP, SOAP or any other SIP or other protocol message.
  • Service description D can be embedded into the SIP PUBLISH message (e.g. as MIME "applica- tion/wsdl+xml" content type) or indirected via a pointer to a remote resource (e.g. through a HTTP URL pointing to publica- tion server PS) .
  • the registry R stores the service information in service da ⁇ tabase DB S erv and checks into subscription database DB SUbS whether any subscriber application C has subscribed for in- formation related to this service S, or to a list of services that includes service S. For any reference to a subscriber application C found in the subscription database DB SU b S / and if the published service information matches optional rules and filters provided by the subscriber application C or ap- plied by the registry R, the registry R sends a notification to the subscriber application C through the notification in ⁇ terface NOT_I, informing about some change in the service in ⁇ formation stored in the registry, if any.
  • This notification includes service information or a pointer to it, and may in ⁇ clude service description D or a pointer to it on publica ⁇ tion server PS (e.g. a HTTP URL) . Notifications may be re ⁇ lated to changes in service availability, service description D or other service-related information.
  • PS publica ⁇ tion server
  • Notification processing at subscriber application C may fol ⁇ low the same behaviour as during the first notification.
  • a client application C can also access directly to publication server PS and retrieve service description D, without being notified by registry R offering a subscription service on service description updates.
  • notification may be triggered by any of the changes related to a single service, and also by changes related to the addition or removal of services that match subscription criteria.
  • Figure 3 shows a flow chart of the notification mechanism of a single service description.
  • publisher PUB publishes a service description D into the registry R (step 100) .
  • the registry R stores the service description D on service database DB serv (step 110) .
  • a client application C makes a request, e.g. a subscrip ⁇ tion, for the service description D of a specific service S to registry R (step 120) .
  • the registry R checks whether this request is a subscription or a single query.
  • the registry R If the request from the client application C to the registry R is a subscription (A-part of the flow chart) , the registry R first stores the subscription into its subscription data ⁇ base DB 3UbS at step 140, then it searches a service descrip ⁇ tion D corresponding to the requested service S in the ser- vice database DB serv (step 150) and checks whether the service description is available (step 160) . If so, it sends the ser ⁇ vice description D to the client application C at step 170, then waits for an update of service description D at step 180 checking for it (step 185) . If the service description is not found, the registry R informs the client application C that no service description is currently available at step 175, then waits for an update of service description D at step 180 checking for it (step 185) .
  • the registry R in ⁇ forms the client application C and sends service-related in ⁇ formation (availability and/or service description D) at step 190.
  • the registry R searches into its service database DB serv the service description D associated with the service S requested by the client application C at step 200.
  • the registry R checks its service database DB ser v at step 210. If the service S is found, then the registry R sends the service description D to the client application C at step 220, otherwise it in ⁇ forms the client application C that no service description was found for this service S at step 230.
  • Figure 4 shows a flow chart of the notification mechanism of a list of service descriptions.
  • publisher PUB publishes a service description D into the registry R (step 300) .
  • the registry stores the service description D on service database DB ser v (step 310) .
  • a client application C makes a request, e.g. a subscrip ⁇ tion, for the service descriptions of a list of services to registry R (step 320) .
  • the list may comprise a static or dynamic number of services, known or unknown to the client application.
  • the registry R checks whether this request is a subscription or a single query.
  • the registry R If the request from the client application C to the registry R is a subscription (A-part of the flow chart) , the registry R first stores the subscription into its subscription data ⁇ base DB 3UbS at step 340, then it searches for service descrip ⁇ tions corresponding to the requested list of services in the service database DB serv (step 350) and checks whether at least one service description D is available (step 360) . If so, it sends the list of available service descriptions to the cli ⁇ ent application C at step 370, then waits for an update of any service description within the list of services, or for an update of the list itself (added/removed service) at step 380 checking for it (step 385) .
  • the registry R informs the client application C that no service description is currently available at step 375, then waits for an update of any ser ⁇ vice description within the list of services, or for an up- date of the list itself (added/removed service) at step 380 checking for it (step 385) .
  • the registry R informs the client application C and sends service-related information (availability, list and/or service description) at step 390.
  • the registry R searches into its service database DB ser v for service descriptions corresponding to the requested list of services requested by the client application C at step 400.
  • the registry R checks its service database DB serv at step 410. If at least one service is found, then the registry R send the list of available service descriptions to the client ap ⁇ plication C at step 420, otherwise it informs the client ap- plication C that no service description was found for any service of the list at step 430.
  • the actual content of the published information may be filtered or modified in any way by one or more enti ⁇ ties interposed between the publisher entity PUB and the re ⁇ DCver of the service information, namely the registry R or the client application C.
  • SIP is used as a transport protocol for ser ⁇ vice description publication, discovery and dynamic notifi ⁇ cation.
  • a new SIP Event Package is defined, hereafter called service, which enables the exchange of service de ⁇ scriptions over a SIP-based network.
  • Figure 5 shows a message sequence chart of publication and notification mechanism according to the invention, illustrat- ing the message flows between the publisher entity PUB, the registry R and the client application C using SIP protocol .
  • the client application C subscribes first to the registry R for service description notifications (message 500) , it gets acknowledgement by the registry R through a SIP response mes ⁇ sage 200 OK of known type to a man skilled in the art, then it gets immediately notified (message 510) about current ser ⁇ vice description D, if available, and sends in turn its ac ⁇ knowledgement SIP message 200 OK.
  • publisher entity PUB publishes a new service descrip ⁇ tion D to the registry R (message 520) , which immediately, in an asynchronous way, notifies all client applications sub ⁇ scribed to this information with the newly updated informa- tion (message 530) .
  • the registry R immediately notifies, in an asynchronous way, the client applications again (message 550) .
  • the service description D may be published by the service provider SP itself or by another entity on behalf of it. Ad ⁇ vantageously, it may include some extra meta-information such as the category to which the described service belongs to, semantic information, business-related information, etc., de ⁇ rived from UDDI, OWL, OWL-S or other model or language.
  • the service description itself is preferably described as a WSDL content using MIME type "application/wsdl+xml", but it may also be described by other means.
  • Content-Type application/wsdl+xml Content -Length: ...
  • a network element receiving this information may- publish it again using different mechanisms (e.g. HTTP), or store or save them to persistent or volatile component (file, database, etc.) . It may also add or remove some information retrieved remotely or locally by these means or by another means, such as presence and availability information. It may also compose this information to aggregate similar service descriptions into a single one, for example for a single ser ⁇ vice accessible through different SIP URIs.
  • the discovery process as a whole regards both instant fetch of data and asynchronous notification. It may be performed by different techniques and protocols and may include some data
  • the discovery process is based on a sub- scription triggered by a SIP SUBSCRIBE message that enables asynchronous notif ication of information during the subscrip ⁇ tion duration.
  • the discovery process may be performed for a single service or for a list of services , whether is the services contained in the list are known a priori or not .
  • This message corresponds to message 500 of Figure 5 .
  • the single service description or list of service descrip ⁇ tions returned may be of any type of content and is format ⁇ ted, for example , according to the formalism of the inven ⁇ tion . It is returned either inline or in an indirected way (for example using an HTTP URL) .
  • This message corresponds ei ⁇ ther to messages 510 , 530 or 550 of Figure 5 .
  • Content-Transfer-Encoding binary Content-ID: ⁇ mrEakg@mycompany.com > Content-Type: application/wsdl+xml; [WSDL document (i.e. the published document defined above)] --TfZxoxgAvLqgj4wRWPDL--
  • the client application C reads the service descrip ⁇ tion D and, according to the formalism and the description of the service, builds the message to be sent to the server SP that corresponds to the specific service to invoke.
  • the message is then sent on the link Li nvO k e from the client application C to the server SP, which process it and recog ⁇ nizes that this message corresponds to a specific service S since its content is conform to the service description D.
  • the server SP executes the service S according to its inter ⁇ nal service logic and the information contained in the mes ⁇ sage sent by the client application C.
  • the server SP produces an output message formatted according the formalism and the description of the service S, which corresponds to the result of the service logic execution, and sends it to the client application C.
  • the client application C receives the output message from the server SP that corresponds to the result of the service logic execution. Using the service description D it already has lo ⁇ cally, the client application C reads the content of the out- put message and interprets it in a proper way according to the formalism defined in this invention.
  • an inter-personal communication service S such as a multimedia session-based service between two client ap ⁇ plications C in a communication network
  • a service description D which is provided by a standalone service description provider DP, such a provider knowing a priori remote interaction mechanisms supported by client applications in the communication network.
  • client applications C retrieves service description D from service description provider DP, and invoke multimedia session-based service S to the other client application C ac ⁇ cording to remote interaction mechanisms already described in service description D.
  • the method is expected to answer the dynamic creation and provision of services when the number of ser ⁇ vices available to users will change very fast, to allow cli ⁇ ent applications to be permanently updated about available services and how to interact with them a priori.
  • this invention applies to any kind of service that interacts with SIP messages, including but not limited to session-, subscription-based services, information ser ⁇ vices, messaging services, presence-based services, and any other kind of service supplied, for example, over a pro ⁇ tracted time.
  • This invention does not limit itself to SIP-based services as such, but also applies to SIP-based resources, such as end- user application (i.e. user agent) , proxy, application server, multipoint conference unit, media gateway, media server, applications on top of application servers, network and home appliances, etc.
  • end- user application i.e. user agent
  • this invention also covers the description of ser ⁇ vices that use SIP messages to interact with non-SIP services or resources, i.e. services or resources that do not imple ⁇ ment the full SIP protocol and which primary function is not SIP-related but that do send and/or receive SIP-based mes- sages.
  • non-SIP services or resources i.e. services or resources that do not imple ⁇ ment the full SIP protocol and which primary function is not SIP-related but that do send and/or receive SIP-based mes- sages.
  • resources are network appliances that send a SIP message to publish some information or receive some command or query through a SIP message.
  • the information covered by this invention relates at least to remote service interaction and semantic description (intended as human- and machine-readable definition) .
  • This description may be defined using WSDL description language or other lan ⁇ guages.
  • the method and system of the present invention can be further extended to allow client applications to sub ⁇ scribe to information about users subscribed to service de ⁇ scription information according to the present invention.
  • the client applications may be updated, for example, about which service descriptions one or more spe ⁇ cific users are subscribed to, or which users are subscribed to one or more service descriptions .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)

Abstract

The invention relates to a method and system of interaction between a requesting entity (C) and a responding entity (SP) on a communication network based on the Session Initiation Protocol (SIP). The invention provides a machine-readable service description (D) including specifications of interac­tion between the requesting entity (C) invoking a service (S) at the responding entity (SP), and the responding entity (SP) offering the service (S). The specifications comprise at least a set of rules including abstract input/output message formats and SIP protocol binding rules so that the requesting entity (C) may invoke the service (S) to a SIP uniform re­source identifier by means of a SIP invocation message pat­terned according to the service description (D) and it may interpret the response provided by the responding entity (SP) according to the service description (D).

Description

A method and system of interaction between entities on a com¬ munication network
FIELD OF THE INVENTION
The present invention relates to the access from users to services or resources over the Internet, and particularly to the interaction between entities on a communication network through SIP (Session Initiation Protocol) . This invention relates in particular to the access to ses¬ sion- and subscription-based services through SIP (Session Initiation Protocol) .
BACKGROUND OF THE INVENTION
Different types of Internet-based services exist, such as transaction-based services (e.g. e-commerce) , information services (e.g. web browsing), session-based services (e.g. video streaming, inter-personal multimedia communication) and subscription-based services (e.g. get updated about presence information) , messaging-based services (e.g. instant messag¬ ing) .
The Internet Engineering Task Force (IETF) has standardized in June 2002 the Session Initiation Protocol (SIP) (as avail¬ able in the Request for Comments collection, RFC3261, by J. Rosenberg et al . , on June 10, 2004 at the complete URL http://www.ietf.org/rfc/rfc3261.txt) that provides a way to establish and control multimedia sessions over IP, as well as a framework for event notification and subscription manage¬ ment (SIP event framework) called Session Initiation Protocol (SIP) -Specific Event Notification (as available in the Re¬ quest for Comments collection, RFC3265, by A. B. Roach, on June 10, 2004 at the complete URL http://www. ietf.org/rfc/rfc3265.txt) .
SIP-enabled multimedia communications include, but are not limited to,, audio/video, data, messaging and event notifica¬ tion (such as presence) communications between two or more entities.
SIP protocol defines several types of methods (SIP methods) and related text-based messages' (hereinafter SIP messages) between two entities, typically a client application and a server.
Each type of SIP method defines a different service model .
SIP has, amongst others, service model types of: - session (using the INVITE SIP method) ;
- subscription (using the SUBSCRIBE SIP method) ;
- asynchronous notification (using the NOTIFY SIP method) ; and
- messaging (using the MESSAGE SIP method) .
For each type of service model, SIP protocol defines some ba¬ sic message interactions between clients and servers, includ¬ ing message type and format. A SIP message includes some re¬ quired information (for example some SIP headers) and can be extended with optional information depending on the SIP method and the service to invoke.
As an example, a user wishing to view a movie trailer would typically require its client application to use an INVITE method and to send an INVITE message to start a video session with a movie server. In another context, a user willing to be updated with information, e.g. about local weather, will use a SUBSCRIBE method by triggering a SUBSCRIBE message from its client application to a server, e.g. a weather forecast server.
Currently, one standard way to describe a service invocation through the SIP protocol between a client application and a server is to define a SIP Uniform Resource Identifier (SIP URI) where to invoke the service, and optionally the SIP method and the required input parameters with their position in the SIP message (e.g. "sip:weatherOmycompany.com;method=SUSBCRIBE?event=weather&p- city=turin" defines a SIP URI, i.e. sip:weatherOmycompany.com, and specifies that the SIP "SUB¬ SCRIBE" method has to be used and that an "Event" header with value "weather" and a "P-City" header with value "turin" have to be inserted in the SIP SUBSCRIBE message.
By clicking on a hyperlink pointing to the SIP URI on a web page the client application associated with SIP hyperlinks of the type SIP-URIs constructs the SIP message with all these parameters, confident that it is exactly the format expected by the service. The input SIP message can be sent to the ser¬ vice and be processed at the server location in the right way.
However, using the above mechanism according to the SIP stan¬ dard, the client application does not know the exact seman¬ tics of the answer from the service a priori without invoking the service and actually receiving the answer.
In other words, the client application will see what the re¬ sponse format is only when it receives a response from the service it has invoked. Moreover, the comprehension of output data and parameters sent by the server to the client application may not be trivial, since some information can be included in headers or body of the SIP message and unknown to the user.
Due to these limitations, a SIP client application may not handle and process answers coming from a server automatically and/or correctly. This means that a SIP client application needs to conform to the answer it is going to receive.
Additionally, the above mechanism does not allow defining op¬ tional information that may or may not be sent by the client application when invoking the service.
Moreover, the above mechanism explicitly applies for a single service provider entity (responding at the specified SIP URI) and not to a plurality of provider entities or services.
In the context of session- and subscription-based services, formalisms are known to describe these services only for server's internal use.
Amongst them, scripting languages like Call Processing Lan¬ guage (CPL) (as retrieved on June 10, 2004 at the complete URL http://www. ietf.org/internet-drafts/draft-ietf-iptel-cpl- 09.txt) , whose last version has been defined in April 2004 by the IETF, defines rules for processing session-based services in XML (extensible Mark-up Language) .
This description, however, only defines the server's internal service logic and not the remote invocation mechanisms from the client application. In a similar way to CPL description, Sun Microsystems and Dy- namicsoft Inc. published in February 2003 the final release of SIP Servlet API v.1.0 Specification (available on June
10, 2004 at the complete URL http://jcp.org/aboutJava/communityprocess/final/jsrllδ/index. html) .
The SIP Servlet is a Java-based service logic executing on a SIP server that can listen to SIP messages coming from cli- ents . The SIP servlet specification defines deployment de¬ scriptors for SIP servlets: these descriptors are XML-based files stored locally on a server that map an input filter based on a SIP message with a predefined SIP servlet. When¬ ever a SIP message arrives from a client application to the server, a SIP servlet container checks whether the message matches a filter defined in a descriptor. If so, the servlet container automatically triggers the service logic that cor¬ responds to the matching filter in the descriptor.
This description is limited in the definition of input pa¬ rameters and does not include any information about the out¬ put of the service toward the client application.
In the above-mentioned two formalisms, if a client applica- tion sends a SIP message to a server, once more it will not know exactly what will be the output of the server, if any, and thus it cannot handle and process answers correctly.
Furthermore, SIP event framework defines service model of asynchronous notification in subscription-based services, i.e. it allows a client application to subscribe to event oc¬ currences during a certain period of time and to be dynami¬ cally notified by a server of each event occurrence during the period. The notification is sent by the server at times decided by the server.
SIP event framework suggests that the notification comprises data formatted according to a so called "SIP event package" . The SIP event framework suggests the same approach for sub¬ scription to event occurrences.
SIP event framework is explicitly independent from the actual service data that is requested by the client, so that these mechanisms are open to apply to notification of any kind of event and related service data, for example online discov¬ ery/retrieving of specifications and/or availability informa¬ tion regarding the services currently provided by a server.
International Publication WO 2004/059502 Al "Content and ser¬ vice registration, query and subscription, and notification in networks", published July 15th, 2004 describes a system and method using SIP protocol for discovery of availability and capability of services or content within a local network. This mechanism envision the client application to query ex¬ plicitly for a specific service, and get notified about its providers and their specific capability information (typi¬ cally SLP-based information in a local network) . The above known art does not apply to an unknown plurality of services, nor to telecommunication networks and services.
US Publication US 2004/0153547 "Service provisioning in a communication system", published August, 5tb 2004 describes a mechanism using SIP protocol for provisioning event package descriptions to be used for subscriptions to services.
The above method explicitly refers only to event packages de¬ scription provisioning from a server to a client. The WO 2004/059502 Al and US 2004/0153547 fail to teach how a client application will receive answers by a server when in¬ voking a service, it neither teaches how answered informa¬ tion is organized.
As an example, a user wishing to be updated with information about local weather, and subscribing at a server to. a weather forecast service, will neither know how notification will oc¬ cur, i.e. it will not be informed about the type, format, output parameters and transport protocol of the answer he should receive, before the notification itself, nor when up¬ dating information will be sent by the server.
Thus, on the basis of the known solutions in a SIP-based con- text, Applicant believes that formalisms defining session- and subscription-based services lack of a mechanism to de¬ scribe semantics of interactions both from client applica¬ tions to SIP resources offering these services and vice- versa.
To summarize, Applicant believes that the closest prior art related to SIP session- and subscription-based services fails to make available standard ways of describing how to invoke a SIP service, receive and understand the response. Current so- lutions to describe the operation or the invocation of such a service only cover a single aspect of this interaction, i.e. the input interaction between a client application and a server, but fail to teach how the server is going to act in response.
SUMMARY OF THE INVENTION
The aim of the present invention is therefore to provide a method and a system of interaction between entities through the SIP protocol to ease invocation of a service. Specifi¬ cally, the invention seeks to provide a solution to cor¬ rectly invoke and understand session- or subscription-based services on SIP protocol .
A further object of the invention is also to provide a solu¬ tion for retrieving information at the client ' s side regard¬ ing the services currently provided by one or more servers, and being updated in real-time of any changes in service specifications and/or availability.
According to the present invention, these objects are achieved by means of a method and system of interaction be- tween a first and second entity, having the characteristics referred to in the independent claims.
Further objects of the invention are a machine-readable ser¬ vice description, a communication network and a computer pro- gram product or computer program set of program products as claimed.
Moreover, methods for providing a session-based service and a subscription-based service in a SIP context are also claimed.
In summary, in order to overcome the drawbacks of the prior art, the invention provides a service invocation mechanism to formally describe at least session- and subscription-based SIP services, including the provision of a service descrip- tion or formalism intended to describe input and output mes¬ sage formats for invoking a SIP service and understanding its response on the side of the client application. The service description includes the format specification of input and output messages as a set of abstract rules defin¬ ing the message structure (in terms of attributes and pa¬ rameters) for said service, and the implementation of those rules (binding) on the SIP protocol, for example indicating a list of entities, which provide this service. Moreover, the service description provided according to the invention in¬ cludes some semantic information about the service, as for example information helping to identify the type of service requested (e.g. weather-related service) as well as the mean¬ ing of the parameters associated with the service.
Preferably, the invention envisions the use of extensions of Web Service Description Language (WSDL) to add support to session and subscription mechanisms and support binding for the SIP protocol and format.
The first version of WSDL has been defined by The World Wide Web Consortium in March 2001, and periodic updates have been made until the last version, WSDL 2.0, in November 2003 (pub- lished at the complete URL http://www.w3.org/2002/ws/desc/, as retrieved on June 10, 2004) .
The method and system according to the invention make use of the service description for a client application both to in- voke a service to the relevant SIP Uniform Resource Identi¬ fier and to know a priori the expected answer, i.e. know where and how the parameters of invocation and response would or could be transmitted in the SIP request line, header or body of the exchanged SIP messages.
Advantageously, the availability of a common formalism to de¬ scribe every aspect of a SIP service, including both input and output message formats in session- or subscription-based services, allows a client application to correctly interact with a service provider or another client application and be updated in case of dynamic creation and provision of ser¬ vices so as in case of modification of service parameters.
The invention proposes also a new mechanism for real-time no¬ tification of service availability, interaction rules and providers.
The architecture of this mechanism envisions a client appli¬ cation that is interested in getting updated about service description and availability. Updates are provided by a reg¬ istry, which stores service-related information and maintains a state for each client application. Service description and availability is published by the service provider using a publication interface on the registry, or by a further entity on behalf of the service provider. Each time a change occurs in the registry that may be triggered by a new publication from a service provider, the registry will notify the inter- ested client applications if the change matches their sub¬ scription filter, if any.
Using this architecture, subscriptions will provide informa¬ tion on new, changed or deleted entities within a registry as they occur during the whole subscription duration.
The invention can be used to deliver updates to client appli¬ cations (including but not limited to end-user applications) either pushing or allowing them to download updated machine- readable descriptions of available services without requiring any intervention from the user itself. It is to note that the information provided in notifications is related to service interaction description and is independent from the service data that may be retrieved when invoking the described ser¬ vice.
According to one aspect of the invention, a client entity (a user or network application or resource, commonly and herein¬ after referred to as "client (subscriber) application") is allowed to subscribe to a notification service providing a single service description and be dynamically notified about it, for example on how and where to invoke the service and how to interpret the expected answer, if any. This includes as well a mechanism to query and fetch a single service de¬ scription, and allows the client application to be notified automatically as soon as an updated description is available. As mentioned above, such changes can be for example related to interaction mechanisms, service availability or the number of service providers for this service. The actual service de¬ scription may be sent inline or indirectly and referenced us¬ ing some pointer to a network-based server which hosts the service description, for example through a URI. Subscriptions or queries may include filters to refine the service descrip¬ tion notified to the subscriber application.
According to another aspect of the invention, the subscriber application is allowed to subscribe to a list of service de- scriptions, explicitly (by requesting a known list of ser¬ vices) or implicitly (by requesting an unknown list of ser¬ vices) , and being dynamically notified about every single service description. This includes as well a mechanism to query and fetch a list of service descriptions, and allows the subscriber application to be notified automatically as soon as an updated description is available for a service, or whenever a change occurs in the service description list (ad¬ dition/removal of service descriptions) . Subscriptions or queries may include filters to refine the service description notified to the subscriber application.
The invention also defines a way for a service provider server, or a resource on behalf of it (hereinafter referred to as "publisher"), to publish the description of one or more services to at least one other entity (network-based re¬ source) .
According to an additional aspect of the invention, it is proposed a system to aggregate service descriptions from more network-based resources to optionally obtain a list of re¬ sources that provide a similar service, and to compose a new description of the service.
BRIEF DESCRIPTION OF THE DRAWINGS
Further characteristics and advantages of the invention will be explained in more detail in the following description, provided by way of non-limiting example with reference to the appended Figures, in which:
Figure 1 is a block diagram of a functional architecture for session- and subscription-based SIP service's invocation by a client, according to the invention; Figure 2 is a block diagram of a functional architecture for service description notification to a client;
Figure 3 is a flow chart of the notification mechanism of a single service description according to the invention;
Figure 4 is a flow chart of the notification mechanism of a list of service descriptions according to the invention; and
Figure 5 is a message sequence chart of a service de¬ scription publication and notification mechanism. DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
The functional architecture related to a typical access sce- nario to a session- or subscription-based SIP service is shown in figure 1.
A client entity C, such as a client application, wishing to invoke a session or subscription SIP service S is connected to a service provider or server SP over a direct network- based communication link Linvoke- A service description pro¬ vider DP, which provides a service description D for service S, is arranged to be coupled to, for instance, a web server WS over a direct network-based communication link LpubiiSh/ the web server WS being intended to publish a SIP service de¬ scription D supplied by service description provider DP. The client application C is arranged to be connected to web server WS to retrieve published service description D over a direct network-based communication link Lretrieve- The service description provider DP may be coupled to the service pro¬ vider SP.
In the preferred embodiment the service provider SP is asso¬ ciated to a SIP server, but, according to further embodiments of present invention, the service provider SP may also be an¬ other client application.
A typical client application includes a set of computer pro¬ gram modules for performing network operations such as access to remote resources or services.
SIP-based services can be invoked sending a SIP message from client application C to the service provider SP or to another client application.
SIP protocol defines several types of message between a cli¬ ent application C and a server SP, and each type of message defines a different service model. SIP has, amongst others, concepts of session (instantiated by the INVITE method) , of subscription (SUBSCRIBE method) , and of asynchronous notifi¬ cation (NOTIFY method) . Hence there is a need for the client application to know which type of SIP message is required by the service at each step of the invocation process.
Moreover, SIP envisions two types of messages: requests and responses. SIP requests can be initiated both by client ap¬ plications and servers. SIP responses are triggered by SIP requests and can also be sent both by client applications and servers. For convenience, in the following of the description and in the appended claims it is referred to the client ap¬ plication as the entity sending a request and the server or service provider as the entity receiving the request and sending a response, but it should be understood that the vice versa is possible, without departing from the scope of the invention.
The following is an example of a SIP INVITE request message.
INVITE sip:user@example.com SIP/2.0
[SIP Request-line]
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bKcaaaaaaaaa Content-Length: ...
Max-Forwards : 70
Content-Type: application/sdp
To: <sip:user@example.com>
From: "12345" <sip:12345@test.org>;tag=bθddb34d Call-ID: b0ddb34d@10.0.0.1
CSeq: 1413209355 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Contact: <sip:10.0.0.l:5060> [SIP headers] v=0 o=ntzum 734274293 734274293 IN IP4 10.0.0.1 S=-
C=IN IP4 10.0.0.1 t=0 0 m=audio 22000 RTP/AVP 4 a=rtpmap:4 G723/8000 m=video 22002 RTP/AVP 34 a=rtpmap:34 H263/90000
[SIP message body]
As shown, a SIP message is composed of 3 sections: - a SIP Request-Line, which contains the SIP method (e.g. INVITE) and the SIP Request-URI, which is used for SIP message routing between the client application C and its fi¬ nal destination (e.g. the server SP) ;
- a list of SIP headers; some of these headers are re- quired for SIP message processing within a SIP network (e.g.
"From:", "To:", etc.) , but some of them are optional (e.g. "Allow:") ;
- optionally, a SIP message can include a message body; when present, the body corresponds to a specific MIME con- tent, whose type is described in the SIP "Content-Type:" header.
According to a preferred embodiment of present invention, in order to ease invocation and interpretation of a SIP service S and of the related service data, service description pro¬ vider DP publishes a service description D of the SIP service S provided by service provider SP, e.g. by making it avail¬ able at web server WS through link LpubiiSh.
Prior to actually invoking the service S at service provider SP, client application C first retrieves service description D, e.g. from server WS through link Lretrieve/ according to a mechanism independent from the service (e.g. through HTTP re¬ quest to web server WS) .
The service description D give's information to the client ap- plication about where and how to invoke the service, and also about how the service will answer remotely to the applica¬ tion. It includes, but is not limited to, a machine-readable description including specifications of interaction between a requesting entity and a responding entity, said specifica- tions comprising at least a set of rules describing required and/or optional input and output message formats and their actual implementation over (binding with) SIP protocol for accessing a service S supplied by provider SP. For example, the service S can be a session-based or sub- scription-based service, i.e. a service, which needs an ex¬ plicit request/invocation by the client, which related ser¬ vice data is supplied over a protracted time and which is concluded by an explicit termination.
In the following, service supplied over a protracted time is intended as a service where at least one of the actions of sending and receiving service data between entities involved in the service is protracted over time: - either continuously (as in a session-based service, where the action of sending and/or receiving service data is con¬ tinuous in time) , or intermittently (as in a subscription-based service, where the action of sending and/or receiving service data is plural and executed at different points of time, e.g. on a periodic basis) .
A service supplied over a protracted time is intended as op¬ posed to a service of the type "request-response", where a single instant request is answered with a single instant re- sponse and the action of sending and/or receiving service data is executed only once at a specific point of time.
The requirements for the description of SIP-based services according to the invention are hereinafter described in more detail.
The service description formalism for SIP-based services sup¬ ports the syntactic definition of any type of SIP message, allowing the following flexibility:
- it specifies the SIP message type used by the service (SIP request or SIP response) ;
- when a SIP request, it specifies which method is to be used by the service, and what is the URI where the service can be accessed;
- it defines the headers that can be sent within the SIP message, both required and optional;
- it specifies if a message body is required in the SIP message and if so, it defines its content type, format and optionally value;
Additionally, the service description formalism supports the following concepts :
- the generic type of service, e.g. a subscription, a session, etc.;
- the model of service, i.e. the interaction(s) between the requesting entity and the responding entity (e.g. "in- multi-out") ;
- which message contains service-related data, if any (e.g. SIP request or SIP response) ;
- whether some specific extension is required.
Session-based services have specific concepts addressed, such as :
- the session description in terms of media (e.g. au¬ dio, video, application or data) , protocols, codecs, etc.;
- the session duration; - the session setup mechanism.
Subscription-based services also have specific concepts ad¬ dressed, such as:
- the subscription duration; - the notification mechanism (periodic/asynchronous, single/multiple) and, when periodic, the interval of notifi¬ cation;
- the type of event to be considered within the sub¬ scription duration.
Beside syntactic, machine-readable description, the service description may include human-readable description and/or se¬ mantic information related to the service, for example de¬ scribed in OWL (Ontology Web Language) .
According to a preferred embodiment, the service description formalism disclosed in the following description for session- and subscription-based services making use of SIP as a trans¬ port protocol is defined extending WSDL syntax to add support for such services through a SIP binding that answers to ser¬ vice description requirements listed in the previous section. However, syntaxes completely different from that of WSDL may be generated without affecting the inventive principles of the present invention.
With reference to WSDL, which is a language well known to a man skilled in the art and therefore need not to be discussed in detail in the present application, when describing a SIP message for the purposes of the invention, i.e. to define any type of service and to enable the extensibility of the in¬ vention, the verb attribute defined in the HTTP binding of the WSDL specification is reused to specify the type of SIP- message to be used in the service interaction. However, if this attribute is used only at binding level in WSDL specifi¬ cation, the present invention defines it also at message level .
Within SIP messages, service-related parameters can be speci¬ fied in the SIP Request-URI, in a header or in the body of the message. Hence, the way in which the input (from client of server) and output (from server to client) parameters are exchanged between the SIP client application and the SIP server must be defined clearly, so that the client applica¬ tion knows where to find the information included in the SIP messages, and how to interpret it correctly.
A message element is defined to select a message format (SUB- SCRIBE, NOTIFY, INVITE, ...) and the way the input and output parameters are going to be transmitted. This element is placed inside the input and output elements of the binding's operation.
An example of a message element is as follows:
<sip : mess age verb="xs : string"? uristyle="sip :UristyleChoice"? location=xs :uriReference"? /> <simpleType name="UristyleChoice"> <restriction base= " string" >
<enumeration value="urlEncoded"/> < enumeration value= "υxlReplacement " / > < enumeration value="userReplacement"/> </restriction>
</simpleType> The verb attribute is used to specify the message format . This attribute would assume any value, so that the output message could be transported either by a SIP request or by a
SIP response. In case of a SIP request, the value corresponds to the SIP method to be used (e.g. "INVITE", "SUBSCRIBE") . In case of a SIP response, the value "response" is used.
This attribute is not required in the message element if a default attribute {verbDefault) is defined in the operation and binding elements. However, each message must have a verb or verbDefault attribute defined. If a verbDefault attribute is defined and the message element includes a verb attribute, then only the latter value has to be considered.
The uristyle attribute is used whenever there is the need to send service-related parameters (parts) within the SIP Re¬ quest-URI. This attribute should not be present if all parts are to be sent within the SIP message body or a SIP header.
Within the SIP Request-URI, parameters can be transmitted:
- as uri-parameters, encoding automatically all parts that need to be sent and do not appear in the SIP message body or SIP header, using the "urlEncoded" value.
For example, assuming to send "paraml" and "param2" parame- ters, respectively with "valuel" and "value2", the "urlEn¬ coded" style will encode the parts into the SIP Request-URI as :
;paraml=valuel;param2=value2
- as other-parameters by replacing a relative URI pat- tern of parts (defined in the location attribute of the jnes- sage element, or the operation element) using the "urlRe- placement" value. In this case, parts can be replicated both in the SIP Request-URI and in a SIP header or the SIP message body if necessary.
Following the previous example, "urlReplacement" will trans¬ form the u;param=test;test={paraml} . {param2}" pattern into:
;param=test;test=valuel.value2 - as userinfo of the SIP Request-URI replacing the ex¬ isting one, if any, with a pattern of parts (defined in the location attribute of the message element, or the operation element) using the "userReplacement" value.
Following the previous example, "userReplacement" will trans- form the "service. {paraml} . {param2}" pattern as username into the SIP Request-URI as: service.valuel .value2
The location attribute defines a pattern of parts to use to extend the SIP Request-URI. No meaning is currently associ¬ ated to this attribute when used with "urlEncoded" value of uristyle attribute.
When not transmitted into the SIP Request-URI, message parts can be sent either in the SIP message body or in a SIP header. Since message body format and header names are exten¬ sible, specific elements are defined to clearly describe how each part of the message will be transmitted.
SIP message body, when present, must pertain at a MIME type. Hence, parts inserted into the SIP message body can be de¬ fined following the MIME binding for WSDL or through another mechanism. For example, XML-based content can be inserted as:
<sip:contentXml part="NMTOKEN" type="xs:string" />
The contentXml element defines how to insert an XML-based part into the SIP message body. The part attribute references the name of the part in the message to be sent, which type may refer to an external XML type in an external XML namespace.
The type attribute defines the MIME type of the XML content.
The header element defines how to insert a message part into a SIP header, and its structure is:
<sip:header name="xs:string" part="xs :NMT0KEN" required="xs:boolean"/>
The part attribute references the name of the part in the message to be sent.
The name attribute defines the name of the SIP header that will contain the value of the part.
The required attribute specifies whether this header is re¬ quired for the correct processing of the message.
The binding element defines the mapping of a service model on a specific transport protocol that will be used to transport the input and output messages, if any. The flexibility of the solution is guaranteed by the fact that the output can be none, one or multiple and that it can be transported by both a SIP request and a SIP response.
For the sake of conformity with the terminology used in HTTP and SOAP bindings defined in WSDL specification, binding and operation are defined, respectively identifying the transport protocol and the service location, as follows. <sip:binding transport="xs:anyURI" verbDefault="xs:string"? styleDefault="sip:styleChoice"?/>
<sip:operation location="xs:anyURI"? verbDefault="xs:string"? style="sip:styleChoice"? minDuration="xs:integer"? event="xs:string"? />?
<simpleType name="styleChoice1 "> <restriction base="string">
<enumeration value="session"/> <!-- INVITE method --> enumeration value="subscription"/> <!-- SUBSCRIBE method -->
<enumeration value="rpc"/> <!--• SERVICE method --> </restriction> </simpleType>
A verbDefault attribute is added to provide a default format for a specific operation or binding, in order not to have to specify it in all messages.
Additionally, a style and styleDefault attribute are added to specify a standard SIP behavior, such as "session", "sub¬ scription" or "rpc" (Remote Procedure Call) . These defini¬ tions implicitly define message verbs, message exchange and simplify the definition of a service. For example, the "sub¬ scription" style would implicitly correspond to an exchange of "SUBSCRIBE" messages in input and ■ multiple "NOTIFY" mes¬ sages in output in an asynchronous way for a SIP-based sub¬ scription service. styleDefault attribute with binding owner applies when no style attribute with operation owner applies.
The transport attribute with binding owner aims to know which protocol will be used to access the service. It references a URI that points to the document that describes the transport protocol to use.
The location attribute with operation owner defines the de¬ fault SIP URI parameter pattern to apply by default to all request messages exchanged within this operation. In the operation owner are defined two extra attributes spe¬ cifically related to subscription-based services: minDura- tion and event. The event attribute specifies to which event the subscription is related. The minDuration defines the minimum subscription duration (e.g. in seconds) accepted by the service.
In order to specify where to access the service, a section is provided in a WSDL document, which defines in particular the URI where the service has to be invoked.
WSDL standard accepts any kind of URI format as contact point. However, an extension is described here to support definition of patterns of SIP URIs.
To respect the terminology used in HTTP and SOAP bindings, an address element is added to the syntax for SIP-based services to identify the SIP resource where the service is located.
<sip:address location="xs :string"/>
The value of the location attribute can represent a single SIP URI or a pattern that can define a number of SIP URIs at which the described service can be invoked by the client ap¬ plication. For example, location value of "sip: 0039 [0-9] *@mycompany.com" specifies that the service is supported by any SIP resource, whose SIP URI starts with "0039" and belongs to the "mycom- pany.com" domain, while other SIP URIs may not support the service.
In the following, two examples of service description formal¬ ism according to the invention are presented, which describe a SIP subscription-based service and a SIP session-based ser- vice, respectively.
EXAMPLE 1
In the following example a subscription-based service is de¬ scribed. Specifically, the exemplary description defines a meteorology service that can notify a client about weather forecast updates for a specific city.
The service defines a single operation (named sub- scribeWeatherForecast) , which requires, as input message, the name of a city (named request) and returns the weather fore¬ cast for the given city as output (named response) , as a forecast string associated with an icon.
According to the WSDL syntax preferably taken as a model for the SIP service description, first of all, an abstract por¬ tion of the description is given, where message names and their parts are defined in a conceptual way, then, in the binding section, a material way is described to invoke the service using SIP as transport protocol.
Parts of the description which constitute the extended WSDL syntax according to the invention for describing a subscrip- tion-based service are indicated in bold.
<message name=" request ">
<part name="city" tγpe="xsd: string" /> </message>
<message name=" response ">
<part name=" forecast" type="xsd: string" /> <part name="icon" type="xsd:binary"/> </message> <portType name= "weather ">
<operation name= " subscribeWeatherForecast " > <input message="tns : request "/> <output message="tns :response"/> </operation> </portType> <binding name="sipWeather" type= "weather "> <sip:binding styleDefaulfc="subscription" />
<operation name= " subscribeWeatherForecast " > <sip: operation minDuration="3600" event="weather" /> < input > <sip:message verb=" SUBSCRIBE" uristyle="urlEncoded" />
</ input > <output>
<sip:message verb= "NOTIFY" /> <τnime :multipartRelated> <mime :part>
<mime : content part=" forecast" type="text/html"/> </mime :part> <mime :part>
<mime : content part="icon" type="image/gif "/> <mime : content part="icon" type="image/jpeg"/>
</mime :part>
</mime :tnultipartRelated> </ output > </operation> </binding>
<service name="weatherService">
<port name="subscriptionWeatherService" binding="tns : sipWeather">
<sip:address location="sip: weather@mycompany.com" /> </port>
</service>
The above description specifies that: to invoke the service, a "SUBSCRIBE" message has to be sent to "sip :weather@mγcoτnpany . com" (address) , with the name of the city encoded in the SIP Request-URI {urlEncoded) , i.e. :
SUBSCRIBE sip:weather@mycompany . com; city=turin SIP/2.0 the SIP "SUBSCRIBE" message needs to include a SIP "Event:" header with value "weather" (the type of event) , and a SIP "Expires : " header with value equal or greater than "3600" (the subscription minimum duration in seconds) , i.e.
Event : weather Expires: 10000 - a set of SIP "NOTIFY" messages are output from the ser- vice in an asynchronous way with the weather forecast infor¬ mation encoded in MIME format in the SIP message body, con¬ taining a textual information and a small icon illustrating the forecast .
EXAMPLE 2
In the following example a streaming (session-based) service is described. Specifically, the exemplary description defines a service providing a way to call a movie server and watch a movie trailer on demand.
The service defines a single operation (named stream- MovieTrailer) , which requires, as input message (named re- quest) , the name of the desired movie ("movie" part) and the description of user-side media capabilities ("offer" part) and returns (named response) a description of service-side media capabilities ("answer" part) , then starting the stream¬ ing of the movie.
According to the WSDL syntax preferably taken as a model for the SIP service description, first of all, an abstract por¬ tion of the description is given, where message names and their parts are defined in a conceptual way, then, in the binding section, a material way is described to invoke the service using SIP as transport protocol.
Parts of the description which constitute the extended WSDL syntax according to the invention for describing a session- based service are indicated in bold.
<tnessage name="request">
<part name="movie" type="xsd:string"/> <part name="offer" type="xsd:string"/> </message>
<message name="response">
<part name="answer" type="xsd:string"/> </message>
<portType name="movieStreaming">
<operation name="streamMovieTrailer">
<input message="tns:reguest"/> <output message="tns:response"/>
</operation> </portType>
<binding name="sipTrailer" type="streamMovieTrailer"> <sip:binding styleDefault="session" />
<operation name="streamMovieTrailer"> <input>
<sip:message verb="INVITE" />
<sip:header part="movie" name="P -Movie" required-:" true" /> <mime : content part="offer" type="application/sdp"/>
</ input > < output >
< sip :mes s age verb=" response" />
<mime : content part="answer" tγpe="application/sdp"/> </ output >
</operation> </binding>
< service name= " streamingService " > <port name="movieStreamingService" binding="tns :sipTrailer">
<sip: address locations "sip:streaming@inycompany . com" /> </port> </service>
The above description specifies that: to correctly invoke the service, an SIP "INVITE" message has to be sent to "sip : streaming@mycompany.com" with a spe¬ cific SIP header ("P-Movie:") containing the name of the movie and the description of the user-side media capabilities passed as SDP description in the SIP message body, i.e. :
INVITE sip: streaming@mycompany.com SIP/2.0 P -Movie: The Matrix the service will then answer with a SIP response ("re¬ sponse" verb) containing the description of its media capa- bilities in SDP in the SIP message body. Now, having described the formalism according to which a ses¬ sion- or subscription-based service description is provided by the service description provider DP, with reference to figures 2 to 5 a preferred service description transferring method, alternative to that of figure 1, is disclosed.
A service description is transferred to the client applica¬ tion by mean of a network-based communication. This communi¬ cation can be a direct communication between the client ap- plication C and the service description provider DP or, ac¬ cording to figure 1, an indirect communication between the client application C and the service description provider DP through a server WS . For example, the communication between the client application C and the service description provider DP is indirect when the service description provider DP transfers the service de¬ scription D on a web server WS through a network-based commu¬ nication in a first step, and the client application C re¬ trieves the service description D from the web server WS in a second step through another network-based communication.
A preferred mechanism for real-time notification of service descriptions using the SIP protocol is described hereinafter.
Figure 2 shows the functional architecture related to a typi¬ cal usage scenario of the service description notification method according to the invention.
A client entity (hereinafter "subscriber application") is in- dicated C and a SIP service provider is indicated SP, as in figure 1. Service provider SP offers a SIP service S de¬ scribed by an associated service description D provided by service description provider DP, and the subscriber applica- tion may invoke said service S on a direct communication link
IJinvoke •
Subscriber application C is arranged to be coupled to a reg- istry R in uplink for requesting data about current service information through a subscription interface SUBS__I. Registry R is coupled to a service database DBserv storing service in¬ formation such as availability and service description D of service S, and a subscription database DBSUbs storing sub- scriptions of subscriber application C.
The registry may be a UDDI (Universal Description, Discovery and Integration) registry or a SIP Event Server or any kind of component or group of components that provides at least a publication interface and an inquiry interface and/or sub¬ scription and notification interface.
For the sake of clarity, figure 2 shows a single client ap¬ plication C and a service provider SP and a related service S, but the following disclosure applies to a general archi¬ tecture comprising a plurality of subscriber applications and service providers, each offering one or more services.
Registry R is arranged to be downlink coupled to subscriber application C for informing about current service information through a notification interface NOT_I, associated with sub¬ scription database DBsubs.
Service provider SP may be coupled with service description provider DP for providing service description D. The service description provider DP may be part of the service provider SP or, according to further embodiments, standalone. Service description provider DP is arranged to be coupled to a publisher entity PUB. In addition, service description pro¬ vider DP may also be coupled to a publication server PS for storing service description D. Alternatively, the publica¬ tion server PS may receive service description D from the publisher entity PUB itself or from registry R, as shown in broken lines. Registry R is also connectable to publisher en¬ tity PUB by means of a publication interface PUB_I . The pub¬ lisher entity PUB may be part of the service description pro¬ vider DP or standalone. The publication server PS (e.g. a web server) may be part of the publisher entity PUB, the service description provider DP or the registry R, or it may be a standalone entity.
In the following, the case is presented where a subscriber application C wishes to subscribe to information about a ser¬ vice S and be notified as soon as information update is pub¬ lished for the service. Service information can be related to the availability of a service, service-specific information or to a service description D of remote interaction mecha- nisms that can be used by subscriber applications, for exam¬ ple for GUI automatic generation or some automated action.
Notifications as defined in the invention may contain the re¬ lated information inline or may contain a pointer to a re- source providing the information, or may not carry any re¬ lated information other than the event occurrence itself.
The subscriber application C requests the registry R to be notified about information related to the service S through the subscription interface SUBS_I, optionally including fil¬ tering parameters about notification conditions or informa¬ tion filtering (e.g. the application is interested in all no¬ tifications but only in part of the information) . The registry R stores the subscription into subscription da¬ tabase DBsubs, and may check immediately about current infor¬ mation related to the requested service in service database DBserv If some information is found in the service database and if the service information matches optional rules and filters provided by the subscriber application C or applied by the registry R, the registry R sends a notification to the subscriber application C through the notification interface N0T_I, informing the subscriber application C about the cur¬ rent service information. This notification may include the actual service information or a pointer to it, and in par¬ ticular it may include service description D or a pointer to it on publication server PS (e.g. a HTTP URL) .
Upon notification from the registry R, the subscriber appli¬ cation C may automatically download the service information and/or service description D from publication server PS and process it, for example to generate a GUI to display to the user.
The subscriber application may further invoke the service S based on such description information, using the SIP SERVICE message, HTTP, SOAP or any other SIP or other network-based communication protocol message.
At any point of time, the service provider SP that provides service S, or an external entity on behalf of it (namely ser¬ vice description provider DP) , may publish over a network some information about the service S, for example when the service becomes available, whether its description has been updated, or based on external conditions. To this aim, the service description provider DP asks pub¬ lisher entity PUB to publish the service description D by either sending the actual service description D, which is defined according to the invention, to the publisher entity PUB, or by sending a pointer to the service description D which can be retrieved from the publication server PS. Either way, the publisher PUB can further store the service descrip¬ tion D on publication server PS.
The publisher entity PUB sends the service information (con¬ taining the service description D or a pointer to it) to the registry R through publication interface PUB_I, asking the registry R to store this service information into the service database DBserv Service information- publication can be done using SIP PUBLISH message, HTTP, SOAP or any other SIP or other protocol message. Service description D can be embedded into the SIP PUBLISH message (e.g. as MIME "applica- tion/wsdl+xml" content type) or indirected via a pointer to a remote resource (e.g. through a HTTP URL pointing to publica- tion server PS) .
The registry R stores the service information in service da¬ tabase DBServ and checks into subscription database DBSUbS whether any subscriber application C has subscribed for in- formation related to this service S, or to a list of services that includes service S. For any reference to a subscriber application C found in the subscription database DBSUbS/ and if the published service information matches optional rules and filters provided by the subscriber application C or ap- plied by the registry R, the registry R sends a notification to the subscriber application C through the notification in¬ terface NOT_I, informing about some change in the service in¬ formation stored in the registry, if any. This notification includes service information or a pointer to it, and may in¬ clude service description D or a pointer to it on publica¬ tion server PS (e.g. a HTTP URL) . Notifications may be re¬ lated to changes in service availability, service description D or other service-related information.
Notification processing at subscriber application C may fol¬ low the same behaviour as during the first notification.
Naturally, a client application C can also access directly to publication server PS and retrieve service description D, without being notified by registry R offering a subscription service on service description updates.
The above-described method applies in the same way to list of services. In this case, notification may be triggered by any of the changes related to a single service, and also by changes related to the addition or removal of services that match subscription criteria.
Figure 3 shows a flow chart of the notification mechanism of a single service description.
First of all, publisher PUB publishes a service description D into the registry R (step 100) . The registry R stores the service description D on service database DBserv (step 110) .
Then a client application C makes a request, e.g. a subscrip¬ tion, for the service description D of a specific service S to registry R (step 120) . At step 130 the registry R checks whether this request is a subscription or a single query.
If the request from the client application C to the registry R is a subscription (A-part of the flow chart) , the registry R first stores the subscription into its subscription data¬ base DB3UbS at step 140, then it searches a service descrip¬ tion D corresponding to the requested service S in the ser- vice database DBserv (step 150) and checks whether the service description is available (step 160) . If so, it sends the ser¬ vice description D to the client application C at step 170, then waits for an update of service description D at step 180 checking for it (step 185) . If the service description is not found, the registry R informs the client application C that no service description is currently available at step 175, then waits for an update of service description D at step 180 checking for it (step 185) .
When the requested service S changes status and/or a new ser¬ vice description D is available for the service S (step 185) and/or a predetermined time is elapsed, the registry R in¬ forms the client application C and sends service-related in¬ formation (availability and/or service description D) at step 190.
If the request is a single query (B-part of the flow chart) , the registry R searches into its service database DBserv the service description D associated with the service S requested by the client application C at step 200. The registry R checks its service database DBserv at step 210. If the service S is found, then the registry R sends the service description D to the client application C at step 220, otherwise it in¬ forms the client application C that no service description was found for this service S at step 230.
Figure 4 shows a flow chart of the notification mechanism of a list of service descriptions. First of all, publisher PUB publishes a service description D into the registry R (step 300) . The registry stores the service description D on service database DBserv (step 310) .
Then a client application C makes a request, e.g. a subscrip¬ tion, for the service descriptions of a list of services to registry R (step 320) .
The list may comprise a static or dynamic number of services, known or unknown to the client application.
At step 330 the registry R checks whether this request is a subscription or a single query.
If the request from the client application C to the registry R is a subscription (A-part of the flow chart) , the registry R first stores the subscription into its subscription data¬ base DB3UbS at step 340, then it searches for service descrip¬ tions corresponding to the requested list of services in the service database DBserv (step 350) and checks whether at least one service description D is available (step 360) . If so, it sends the list of available service descriptions to the cli¬ ent application C at step 370, then waits for an update of any service description within the list of services, or for an update of the list itself (added/removed service) at step 380 checking for it (step 385) . If no service description is found for any service of the list, the registry R informs the client application C that no service description is currently available at step 375, then waits for an update of any ser¬ vice description within the list of services, or for an up- date of the list itself (added/removed service) at step 380 checking for it (step 385) .
When one of the service of the list (or the list itself) changes status and/or a new service description D is avail¬ able for a service (step 385) and/or a predetermined time is elapsed, the registry R informs the client application C and sends service-related information (availability, list and/or service description) at step 390.
If the request is a single query (B-part of the flow chart) , the registry R searches into its service database DBserv for service descriptions corresponding to the requested list of services requested by the client application C at step 400. The registry R checks its service database DBserv at step 410. If at least one service is found, then the registry R send the list of available service descriptions to the client ap¬ plication C at step 420, otherwise it informs the client ap- plication C that no service description was found for any service of the list at step 430.
An example of both a mechanism for service description spon¬ taneous publication/advertising by service description pro- vider DP and for subscription-based service description noti¬ fication by register R is given below.
For clarity purposes, in the following "advertising" refers to the concept of spontaneous advertising action, i.e. publi- cation by service description provider DP, while "discovery" refers to the concept of subscription-based action, i.e. no¬ tification to client application C.
Conveniently, the actual content of the published information may be filtered or modified in any way by one or more enti¬ ties interposed between the publisher entity PUB and the re¬ ceiver of the service information, namely the registry R or the client application C. In the example SIP is used as a transport protocol for ser¬ vice description publication, discovery and dynamic notifi¬ cation. Thus, a new SIP Event Package is defined, hereafter called service, which enables the exchange of service de¬ scriptions over a SIP-based network.
Figure 5 shows a message sequence chart of publication and notification mechanism according to the invention, illustrat- ing the message flows between the publisher entity PUB, the registry R and the client application C using SIP protocol .
The client application C subscribes first to the registry R for service description notifications (message 500) , it gets acknowledgement by the registry R through a SIP response mes¬ sage 200 OK of known type to a man skilled in the art, then it gets immediately notified (message 510) about current ser¬ vice description D, if available, and sends in turn its ac¬ knowledgement SIP message 200 OK.
Then, publisher entity PUB publishes a new service descrip¬ tion D to the registry R (message 520) , which immediately, in an asynchronous way, notifies all client applications sub¬ scribed to this information with the newly updated informa- tion (message 530) . When, again, a new publication occurs (message 540) , the registry R immediately notifies, in an asynchronous way, the client applications again (message 550) .
The service description D may be published by the service provider SP itself or by another entity on behalf of it. Ad¬ vantageously, it may include some extra meta-information such as the category to which the described service belongs to, semantic information, business-related information, etc., de¬ rived from UDDI, OWL, OWL-S or other model or language. The service description itself is preferably described as a WSDL content using MIME type "application/wsdl+xml", but it may also be described by other means.
A detailed example of publication using the SIP PUBLISH mes¬ sage of the service description of the streaming (session- based) service of example 2 above is shown below. This mes- sage corresponds to messages 520, 540 of Figure 5.
PUBLISH sip : streaming@mycompany.com SIP/2.0 From: sip : streamingOmycompany . com; tag=1234 To: sip: services@mycompany.com Event : service
Content-Type : application/wsdl+xml Content -Length: ...
<?xml version="l.0" encoding="utf-8"?> <definitions xmlns :xsd="http: //www.w3.org/200l/XMLSchema" xmlns :http="http://schemas .xmlsoap.org/wsdl/http/" xmlns :mime="http: //schemas .xmlsoap.org/wsdl/mime/" xmlns :soap="http : //schemas .xmlsoap.org/wsdl/soap/" xmlns : sip="http : //www.mycompany . com/wsdl/sip/ " xmlns : soapenc="http : //schemas .xmlsoap . org/ soap/encoding/ " targetNamespace= "http : / /www . mycompany . com/ " xmlns="http: //schemas .xmlsoap.org/wsdl/"> <message name=" request "> <part name= "movie" type="xsd: string" />
<part name="offer" type="xsd: string" /> </message>
<message name= " response "> <part name="answer" type="xsd: string" />
</message>
<portType name="movieStreaming">
<operation name= " streamMovieTrailer " > <input message="tns : request "/>
<output message="tns :response"/> </operation> </portType> <binding name="sipTrailer" type=" streamMovieTrailer "> <sip: binding styleDefault=" session" /> <operation name="streatnMovieTrailer"> < input > < sip: me s s age verb=" INVITE" />
<sip:lieader part="movie" name="P-Movie" required="true"/> <mime : content part="offer" type="application/sdp"/> </ input > < output >
< sip: me s s age verb=" response" />
<mime : content part="answer" type="application/sdp"/> </ output >
</operation> </binding>
<service name="streamingService"> <port name="movieStreamingService" binding="tns : sipTrailer">
<sip : address location="sip : streamingOmycompany . com"/> </port> </service> </def initions>
The actual behavior of the receiver of the published informa¬ tion is not defined in this invention. However, it is fore¬ seen that a network element receiving this information may- publish it again using different mechanisms (e.g. HTTP), or store or save them to persistent or volatile component (file, database, etc.) . It may also add or remove some information retrieved remotely or locally by these means or by another means, such as presence and availability information. It may also compose this information to aggregate similar service descriptions into a single one, for example for a single ser¬ vice accessible through different SIP URIs.
The discovery process as a whole regards both instant fetch of data and asynchronous notification. It may be performed by different techniques and protocols and may include some data
(e.g. defined in XML) to filter or condition the information to be received.
In the example below the discovery process is based on a sub- scription triggered by a SIP SUBSCRIBE message that enables asynchronous notif ication of information during the subscrip¬ tion duration. The discovery process may be performed for a single service or for a list of services , whether is the services contained in the list are known a priori or not . This message corresponds to message 500 of Figure 5 .
SUBSCRIBE sip : services@mycompany. com SIP/2 . 0 From: sip :user@mycompany . com; tag=1234 To : sip : services@mycompany. com Event : service
Require : eventlist
Expires : 3600
Contact : sip :tiser@host .mycompany . com
Content -Length: 0
The single service description or list of service descrip¬ tions returned may be of any type of content and is format¬ ted, for example , according to the formalism of the inven¬ tion . It is returned either inline or in an indirected way ( for example using an HTTP URL) . This message corresponds ei¬ ther to messages 510 , 530 or 550 of Figure 5 .
NOTIFY sip : user@host .mycompany. com SIP/2 . 0
To : sip : user@mycompany . com; tag=1234 From : sip : services@mycompany. com; tag=abcd
Event : service
Subscript ion- State : active ; expires=3600
Require : eventlist
Content-Type : multipart/related; type="application/rlmi+xml" ; start= " <2BEI83@mycompany . com> " ;boundary="TfZxoxgAvLqgj 4wRWPDL"
Content -Length: ...
--TfZxoxgAvLqgj4wRWPDL Content-Transfer-Encoding: binary Content-ID: <2BEI83©mycompany.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="l.0" encoding="UTF-8"?> <list xmlns="urn:ietf:params :xml:ns:rmli" uri="sip:servicesΘmycompany.com" version="2" name="Available services provided by mycompany" fullState="true"> <resource uri="sip:streaming@mycompany.com" name="Movie streaming">
<instance id="sdlkmeopdf" state="active" cid="mrEakg@mycompany.com"/> </resource> <resource uri="http://www.mycompany.com/webservices/trafficservice" name="Traffic Information"> <instance id="cmpqweitlp" state="pending"/> </resource> </list> --TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary Content-ID: < mrEakg@mycompany.com > Content-Type: application/wsdl+xml; [WSDL document (i.e. the published document defined above)] --TfZxoxgAvLqgj4wRWPDL--
Once the client application C has retrieved the service de- scription D, using for example the preferred method defined above, and the user wishes to invoke the corresponding ser¬ vice S, the client application C reads the service descrip¬ tion D and, according to the formalism and the description of the service, builds the message to be sent to the server SP that corresponds to the specific service to invoke.
The message is then sent on the link LinvOke from the client application C to the server SP, which process it and recog¬ nizes that this message corresponds to a specific service S since its content is conform to the service description D. The server SP executes the service S according to its inter¬ nal service logic and the information contained in the mes¬ sage sent by the client application C. The server SP produces an output message formatted according the formalism and the description of the service S, which corresponds to the result of the service logic execution, and sends it to the client application C.
The client application C receives the output message from the server SP that corresponds to the result of the service logic execution. Using the service description D it already has lo¬ cally, the client application C reads the content of the out- put message and interprets it in a proper way according to the formalism defined in this invention.
As mentioned in the foreground, the above-described mecha- nisms also apply when server SP corresponds to another client application.
For example, an inter-personal communication service S, such as a multimedia session-based service between two client ap¬ plications C in a communication network, can be described through a service description D, which is provided by a standalone service description provider DP, such a provider knowing a priori remote interaction mechanisms supported by client applications in the communication network. One of client applications C retrieves service description D from service description provider DP, and invoke multimedia session-based service S to the other client application C ac¬ cording to remote interaction mechanisms already described in service description D.
Advantageously, the method is expected to answer the dynamic creation and provision of services when the number of ser¬ vices available to users will change very fast, to allow cli¬ ent applications to be permanently updated about available services and how to interact with them a priori.
Advantageously, this invention applies to any kind of service that interacts with SIP messages, including but not limited to session-, subscription-based services, information ser¬ vices, messaging services, presence-based services, and any other kind of service supplied, for example, over a pro¬ tracted time. This invention does not limit itself to SIP-based services as such, but also applies to SIP-based resources, such as end- user application (i.e. user agent) , proxy, application server, multipoint conference unit, media gateway, media server, applications on top of application servers, network and home appliances, etc. Like services, resources can also describe their remote interaction mechanisms in the way de¬ fined in this invention.
As well, this invention also covers the description of ser¬ vices that use SIP messages to interact with non-SIP services or resources, i.e. services or resources that do not imple¬ ment the full SIP protocol and which primary function is not SIP-related but that do send and/or receive SIP-based mes- sages. Examples of such resources are network appliances that send a SIP message to publish some information or receive some command or query through a SIP message.
The information covered by this invention relates at least to remote service interaction and semantic description (intended as human- and machine-readable definition) . This description may be defined using WSDL description language or other lan¬ guages.
Additionally, the method and system of the present invention can be further extended to allow client applications to sub¬ scribe to information about users subscribed to service de¬ scription information according to the present invention. Advantageously, the client applications may be updated, for example, about which service descriptions one or more spe¬ cific users are subscribed to, or which users are subscribed to one or more service descriptions . Naturally, the principle of the invention remaining the same, the forms of embodiment may be varied widely with respect to those described and illustrated purely by way of non- limiting example, without thereby departing from the scope of protection of the present invention defined by the appended claims .

Claims

1. A method of interaction between a requesting entity (C) and a responding entity (SP) on a communication network based on the Session Initiation Protocol (SIP) , characterised in that it comprises the steps of: providing a machine-readable service description (D) in¬ cluding specifications of interaction between the requesting entity (C) invoking a service (S) and the responding entity (SP) offering the service (S) , said specifications comprising at least a set of rules including abstract input/output mes¬ sage formats and protocol binding rules; invoking the service (S) to a SIP uniform resource iden¬ tifier by means of a SIP invocation message patterned accord- ing to said machine-readable service description (D) ; and interpreting the response provided by the responding en¬ tity (SP) according to said machine-readable service descrip¬ tion (D) .
2. A method according to claim 1, comprising a step of
- providing said service (S) over a protracted time.
3. A method according to claim 2, wherein the service (S) is a session-based service, and said step of providing said service (S) over a protracted time comprises the step of
- sending and/or receiving service data related to the ser¬ vice (S) continuously in time.
4. A method according to claim 2, wherein the service (S) is a subscription-based service, and said step of providing said service (S) over a protracted time comprises the step of
- sending and/or receiving service data related to the ser¬ vice (S) intermittently at different points of time.
5. A method according to claim 3, wherein the machine- readable service description (D) includes a specification of a media employed in the session-based service.
6. A method according to claim 4, wherein the machine- readable service description (D) includes a specification of the duration of the subscription-based service.
7. A method according to claim 4, wherein the machine- readable service description (D) includes a specification of the notification mode of the subscription-based service.
8. A method according to claim 7, wherein the notification mode includes a specification of the interval of notification for a periodic notification.
9. A method according to claim 4, wherein the machine- readable service description (D) includes a specification of the type of event to be considered within the subscription- based service.
10. A method according to any of the preceding claims, wherein the machine-readable service description (D) is drafted according to Web Service Description type Language (WSDL) .
11. A method according to any of the preceding claims, wherein the step of providing said machine-readable service description (D) comprises the step of creating said machine-readable service description (D) , and
- making available said machine-readable service de- scription (D) to the requesting entity (C) .
12. A method according to claim 11, wherein the step of making available said machine-readable service description 5 (D) comprises the step of
- directly accessing said machine-readable service descrip¬ tion document (D) by the requesting entity (C) at the re¬ sponding entity (SP) offering the service (S) .
10 13. A method according to claim 11, wherein the step of mak¬ ing available said machine-readable service description (D) comprises the step of
- publishing said machine-readable service description (D) or a pointer thereto to a remote publication server (WS, PS) ,
15 and
- retrieving said service description document (D) directly at the remote publication server (WS, PS) .
14. A method according to claim 11, wherein the step of mak- 20 ing available said machine-readable service description (D) comprises the step of
- publishing said machine-readable service description (D) or a pointer thereto to a service information registry (R) ac¬ cessible by the requesting entity (C) .
25
15. A method according to claim 14, wherein the registry (R) is able to aggregate a single machine-readable service de¬ scription (D) from a plurality of published machine-readable service descriptions (D) .
30
16. A method according to claim 14, wherein the requesting entity (C) accesses said machine-readable service description (D) by - subscribing to a service information notification service provided by the registry (R) , service information including availability of at least one service (S) and at least one corresponding machine-readable service description (D) .
17. A method according to claim 16, wherein the step of sub¬ scribing to a service information notification service in¬ cludes the step of inserting filtering conditions.
18. A method according to claim 16, wherein the registry (R) is able to asynchronousIy notify the subscribed requesting entity (C) on changes in service information as published to the registry (R) .
19. A system of interaction between a requesting entity (C) and a responding entity (SP) on a communication network based on the Session Initiation Protocol (SIP) , wherein the requesting entity (C) comprises at least one re¬ questing application module arranged to invoke a service (S) at a responding entity (SP) , and the responding entity (SP) comprises at least one re¬ sponding application module arranged to provide the service (S) in response to the the service (S) invocation, characterised in that said requesting application module is arranged to invoke the service (S) to a SIP uniform re¬ source identifier by means of an invocation message patterned according to a predetermined machine-readable service de¬ scription (D) and to interpret the response provided by the responding module according to the machine-readable service description (D) , said machine-readable service description (D) including specifications of interaction between the requesting module and the responding module comprising at least a set of rules including abstract input/output message formats and protocol binding rules.
20. A system according to claim 19, wherein the machine- readable service description (D) includes at least one SIP invocation method and at least one or a pattern of SIP Uni¬ form Resource Identifiers where the service (S) can be ac¬ cessed.
21. A system according to claim 19, wherein the machine- readable service description (D) includes headers and infor¬ mation whether a message body is required and, in the af¬ firmative, the content and the format of the message body.
22. A system according to any of claims 19 to 21, character¬ ised in that
- the service (S) is a session-based service (S) , and
- the machine-readable service description (D) includes a specification of a media employed in the session-based ser- vice (S) .
23. A system according to any of claims 19 to 21, character¬ ised in that
- the service (S) is a subscription-based service (S) , and - the machine-readable service description (D) includes a specification of the type of event to be considered within the subscription-based service (S) .
24. A system according to claim 23, characterised in that the machine-readable service description (D) includes a specification of the notification mode of the subscription- based service (S) .
25. A system according to claim 24, characterised in that the notification mode includes a specification of the inter¬ val of notification for a periodic notification.
26. A system according to claim 23, characterised in that the machine-readable service description (D) includes a specification of the duration of the subscription-based ser¬ vice (S) .
27. A system according to any of claims 19 to 26, character¬ ised in that the machine-readable service description (D) is drafted according to Web Service Description type Language (WSDL) .
28. A system according to any of claims 19 to 27, character¬ ised in that it comprises a service description provider (DP) arranged to create said machine-readable service description (D) and to make available said machine-readable service de¬ scription (D) to the requesting entity (C) .
29. A system according to claim 28, characterised in that said service description provider (DP) is associated to said responding entity (SP) .
30. A system according to claim 28, wherein the requesting entity (C)- is arranged to access to said machine-readable service description (D) directly at the service description provider (DP) .
31. A system according to claim 28, comprising a service in¬ formation registry (R) including a service database (DBserv) arranged to store said machine-readable service description (D) or a pointer thereto supplied by the service description provider (DP) , the requesting entity (C) being arranged to access said service description document (D) through said registry (R) .
32. A system according to claim 31, wherein the registry (R) further comprises a subscription database (DBSUbΞ) arranged to store the subscription of a requesting entity (C) to a ser¬ vice information notification service provided by said regis¬ try (R) .
33. A system according to claim 32, wherein the registry (R) is arranged to asynchronousIy notify the requesting entity (C) on changes in service information stored in said service database (DBserv) •
34. A machine-readable service description (D) for describ¬ ing interaction between a requesting entity (C) invoking a service (S) on a communication network and a responding en¬ tity (SP) offering the service, characterised in that it in- eludes specifications of interaction between the requesting entity (C) and the responding entity (SP) through SIP trans¬ port protocol, said specifications comprising at least a set of rules including input and output abstract message formats and SIP protocol binding rules.
35. A machine-readable service description (D) according to claim 34, including at least one SIP invocation method and at least one or a pattern of SIP Uniform Resource Identifiers where the service (S) can be accessed.
36. A machine-readable service description (D) according to 34, including headers and information whether a message body is required and, in the affirmative, the content and the for- mat of the message body.
37. A machine-readable service description (D) according to any of claims 34 to 36, characterised in that the service is 5 a session-based service (S) , and in that it includes a speci¬ fication of a media employed in the session-based service (S) .
38. A machine-readable service description (D) according to 10 any of claims 34 to 36, characterised in that the service is a subscription-based service (S) , and in that it includes a specification of the type of event to be considered within the subscription-based service (S) .
15 39. A machine-readable service description (D) according to claim 38, characterised in that it includes a specification of the notification mode of the subscription-based service (S) .
20 40. A machine-readable service description (D) according to claim 39, characterised in that it includes a specification of the interval of notification for a periodic notification.
41. A machine-readable service description document accord- 25 ing to claim 38, characterised in that it includes a specifi¬ cation of the duration of the subscription-based service (S) .
42. A machine-readable service description (D) according to any of claims 34 to 41, characterised in that it is drafted
30 according to Web Service Description type Language (WSDL) .
43. A communication network including at least a requesting entity (C) and a responding entity (SP) , the requesting entity (C) comprising at least one re¬ questing application module arranged to invoke a service (S) at the responding entity (SP) , and the responding entity (SP) comprising at least one re- 5 sponding application module arranged to provide the service (S) in response to the invocation, the requesting entity (C) interacting with the respond¬ ing entity (SP) according to a method as defined in claims 1 to 18. 10
44. Computer program product or computer program product set loadable into the memory of at least one computer for carry¬ ing out a method as defined in claims 1 to 18.
15 45. A method for providing a session-based service in a SIP context, including a method of interaction between a request¬ ing entity (C) and a responding entity (SP) as defined in claims 1 to 18.
20 46. A method for providing a subscription-based service in a SIP context, including a method of interaction between a re¬ questing entity (C) and a responding entity (SP) as defined in claims 1 to 18.
25
PCT/EP2004/010419 2004-09-17 2004-09-17 A method and system of interaction between entities on a communication network WO2006029645A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP04765317A EP1790143A1 (en) 2004-09-17 2004-09-17 A method and system of interaction between entities on a communication network
PCT/EP2004/010419 WO2006029645A1 (en) 2004-09-17 2004-09-17 A method and system of interaction between entities on a communication network
US11/663,060 US8775640B2 (en) 2004-09-17 2004-09-17 Method and system of interaction between entities on a communication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2004/010419 WO2006029645A1 (en) 2004-09-17 2004-09-17 A method and system of interaction between entities on a communication network

Publications (1)

Publication Number Publication Date
WO2006029645A1 true WO2006029645A1 (en) 2006-03-23

Family

ID=34958672

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/010419 WO2006029645A1 (en) 2004-09-17 2004-09-17 A method and system of interaction between entities on a communication network

Country Status (3)

Country Link
US (1) US8775640B2 (en)
EP (1) EP1790143A1 (en)
WO (1) WO2006029645A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1993254A1 (en) * 2007-05-16 2008-11-19 Doga Armangil A method and a system for the composition of services
EP2058988A1 (en) * 2007-09-13 2009-05-13 Huawei Technologies Co., Ltd. A method and system for route selecting

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060242012A1 (en) * 2005-04-22 2006-10-26 Sumit Agarwal Determining or scoring properties to solicit to join ad network using advertiser or aggregated advertiser interest
US8401002B2 (en) 2005-06-22 2013-03-19 Research In Motion Limited Exchange and use of globally unique device identifiers for circuit-switched and packet switched integration
CN1794722B (en) * 2005-09-19 2010-05-05 华为技术有限公司 Method of transfering off-line message and instant message server
JP2009536497A (en) * 2006-05-05 2009-10-08 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Method and apparatus for virtual conferencing
WO2008110421A1 (en) * 2007-03-09 2008-09-18 International Business Machines Corporation A method, apparatus and computer program for capturing information on changes to a datastore
US20080301236A1 (en) * 2007-05-31 2008-12-04 Microsoft Corporation Contextual social language
KR100906109B1 (en) * 2007-06-20 2009-07-07 엔에이치엔(주) Ubiquitous Presence Method and System for Providing 3A Based Various Application Statuses
US20090019041A1 (en) * 2007-07-11 2009-01-15 Marc Colando Filename Parser and Identifier of Alternative Sources for File
US8478899B2 (en) * 2007-10-17 2013-07-02 Yahoo! Inc. Managing communications with global applications through message handlers
CA2703912C (en) * 2007-10-27 2016-09-27 Research In Motion Limited Content disposition system and method for processing message content in a distributed environment
KR101531166B1 (en) * 2007-11-27 2015-06-25 삼성전자주식회사 Method and apparatus for discovering IPTV service provider and IPTV service using SIP protocol
US8879545B2 (en) * 2007-12-31 2014-11-04 At&T Intelletual Property I, L.P. Methods and apparatus to route a communication session directly to a voicemail mailbox
MX2010008642A (en) * 2008-02-05 2010-12-14 Samsung Electronics Co Ltd A method and device for sending and receiving metadata for an application providing an iptv service.
EP2109285A1 (en) * 2008-04-11 2009-10-14 Hewlett-Packard Development Company, L.P. Conference system and method
US8301690B2 (en) * 2009-02-06 2012-10-30 International Business Machines Corporation Correlator system for web services
US10491966B2 (en) * 2011-08-04 2019-11-26 Saturn Licensing Llc Reception apparatus, method, computer program, and information providing apparatus for providing an alert service
EP2571223A1 (en) * 2011-09-14 2013-03-20 Telefonaktiebolaget LM Ericsson (publ) A gateway and a method therein for enabling sip communication over a non-standard sip transport protocol
US9769292B2 (en) * 2012-01-19 2017-09-19 Miosoft Corporation Concurrent process execution
US9788299B2 (en) * 2013-04-24 2017-10-10 Verizon Patent And Licensing Inc. Base station paging based on traffic content type
CN107209694B (en) 2014-12-24 2022-03-08 皇家Kpn公司 Method for controlling on-demand service provisioning
CN108701278B (en) * 2015-12-28 2023-01-10 皇家Kpn公司 Method for providing a service to a user equipment connected to a first operator network via a second operator network
US10757547B2 (en) * 2017-11-08 2020-08-25 Avaya Inc. Sequenced applications for controlling communication features
US11080114B2 (en) * 2019-11-26 2021-08-03 International Business Machines Corporation Controlling interaction with a scalable application
US11533345B2 (en) * 2020-03-27 2022-12-20 Samsung Electronics Co., Ltd. Method and apparatus for providing generic framework to manage custom subscription over sip

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004059502A1 (en) 2002-12-30 2004-07-15 Nokia Corporation Content and service registration, query and subscription, and notification in networks
US20040153547A1 (en) 2003-01-31 2004-08-05 Dirk Trossen Service provisioning in a communication system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2813471B1 (en) * 2000-08-31 2002-12-20 Schneider Automation COMMUNICATION SYSTEM FOR AUTOMATED EQUIPMENT BASED ON THE SOAP PROTOCOL
US7418485B2 (en) * 2003-04-24 2008-08-26 Nokia Corporation System and method for addressing networked terminals via pseudonym translation
US7213056B2 (en) * 2003-07-09 2007-05-01 Cisco Technology, Inc. Providing modular telephony service
US8799478B2 (en) * 2004-03-01 2014-08-05 Avaya Inc. Web services and session initiation protocol endpoint for converged communication over internet protocol networks
US7840681B2 (en) * 2004-07-30 2010-11-23 International Business Machines Corporation Method and apparatus for integrating wearable devices within a SIP infrastructure

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004059502A1 (en) 2002-12-30 2004-07-15 Nokia Corporation Content and service registration, query and subscription, and notification in networks
US20040153547A1 (en) 2003-01-31 2004-08-05 Dirk Trossen Service provisioning in a communication system

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
BERGER S ET AL: "Web services on mobile devices - implementation and experience", MOBILE COMPUTING SYSTEMS AND APPLICATIONS, 2003. PROCEEDINGS. FIFTH IEEE WORKSHOP ON 9-10 OCT. 2003, PISCATAWAY, NJ, USA,IEEE, 9 October 2003 (2003-10-09), pages 100 - 109, XP010662879, ISBN: 0-7695-1995-4 *
FENG LIU ET AL: "WSIP - web service sip endpoint for converged multimedia/multimodal communication over IP", WEB SERVICES, 2004. PROCEEDINGS. IEEE INTERNATIONAL CONFERENCE ON SAN DIEGO, CA, USA 6-9 JULY 2004, PISCATAWAY, NJ, USA,IEEE, 6 July 2004 (2004-07-06), pages 690 - 697, XP010708889, ISBN: 0-7695-2167-3 *
HONG CAI ET AL: "Session initiation protocol and web services for next generation multimedia applications", MULTIMEDIA SOFTWARE ENGINEERING, 2002. PROCEEDINGS. FOURTH INTERNATIONAL SYMPOSIUM ON DEC. 11-13, 2002, PISCATAWAY, NJ, USA,IEEE, 11 December 2002 (2002-12-11), pages 70 - 80, XP010632736, ISBN: 0-7695-1857-5 *
NEILL WILKINSON: "Next Generation Network Services - Chapter 8: Representing Information", ISBN 0470858567, 23 April 2002 (2002-04-23), pages 99 - 113, XP002327626, Retrieved from the Internet <URL:http://www3.interscience.wiley.com/cgi-bin/bookhome/93516012> *
SENS T: "Next Generation of Unified Communication for Enterprise: New communication applications that are accessible on any device are helping businesses to be more competitive in the age of the borderless enterprise", ALCATEL TELECOMMUNICATIONS REVIEW, ALCATEL, PARIS CEDEX, FR, October 2002 (2002-10-01), XP007005900, ISSN: 1267-7167 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1993254A1 (en) * 2007-05-16 2008-11-19 Doga Armangil A method and a system for the composition of services
US8266632B2 (en) 2007-05-16 2012-09-11 Doga Armangil Method and a system for the composition of services
EP2058988A1 (en) * 2007-09-13 2009-05-13 Huawei Technologies Co., Ltd. A method and system for route selecting
EP2058988A4 (en) * 2007-09-13 2010-02-24 Huawei Tech Co Ltd A method and system for route selecting
US8266297B2 (en) 2007-09-13 2012-09-11 Huwei Technologies Co., Ltd. Method and system for routing

Also Published As

Publication number Publication date
US8775640B2 (en) 2014-07-08
US20080263212A1 (en) 2008-10-23
EP1790143A1 (en) 2007-05-30

Similar Documents

Publication Publication Date Title
US8775640B2 (en) Method and system of interaction between entities on a communication network
US9112902B2 (en) Service subscription associated with real time composition of services
US8832230B2 (en) Content aggregation service for mobile environment
US20060168319A1 (en) Systems and methods for multipoint service invocation
CN101388837B (en) Route selection method, service network, network appliance and terminal
US20040128344A1 (en) Content and service registration, query and subscription, and notification in networks
JP2008503952A (en) Method, system and computer program enabling discovery based on SIP events of community services and content configured for context information
Ohnishi et al. Service delivery platform for telecom-enterprise-Internet combined services
US20090113077A1 (en) Service discovery associated with real time composition of services
US7610386B1 (en) Stateful messaging gateway
US20090106428A1 (en) Service intermediary Addressing for real time composition of services
Chou et al. Web services for communication over IP
Loreto et al. IMS service development API and testbed
US20070208804A1 (en) System for invoking web services by means of SIP signaling
US20020069257A1 (en) Provisioning mechanism for a service gateway
US20050256962A1 (en) Method for updating a web client on a non ip based home network, and devices for implementing the process
Falcarin et al. Communication web services and JAIN-SLEE integration challenges
US9130873B2 (en) Real time composition of services
CN101690114B (en) Real time composition of services
EP1861985A1 (en) Method and arrangement for services running on service execution platform
Rosenberg A Framework for Application Interaction in the Session Initiation Protocol (SIP)
Chou et al. Web services for service-oriented communication
Hsieh Service Provisioning in Two Open-source SIP Implementation, Cinema and Vocal
Carvalho et al. Java technologies for NGN service creation: Discussion and architecture to improve SIP addresses discovery
Falcarin et al. Broadening JAIN-SLEE with a Service Description Language and Asynchronous Web Services

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REEP Request for entry into the european phase

Ref document number: 2004765317

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2004765317

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2004765317

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11663060

Country of ref document: US