Parlay

Abstract: A method, system, and service provider for program-on-demand service in a telecommunications network, wherein a Session Initiation Protocol (SIP) terminal sends to a service provider, preferably over an HTTP link, a program request for a plurality of selected programs. The service provider determines which content provider stores the first program, and establishes an SIP session between that content provider and the SIP terminal, session which is used for streaming the first selected program to the SIP terminal, preferably using Real-Time Protocol (RTP). At the termination of a first program, the service provider releases the first SIP session and establishes a second SIP session between the SIP terminal and a second content provider storing the second program. The service provider may have a Web Server for selecting programs, and may be connected to an SIP functionality having a Parlay/SIP converter and an SIP server for handling SIP sessions using Parlay/OSA-based messages.

Abstract: A gateway ( 1 ) has a platform on which resides a CORBA bus ( 22 ) an inner layer ( 23 ) of Parlay APIs, and an outer layer ( 24 ) of network service interfaces for controlling network resources ( 2 ). The gateway ( 1 ) also comprises application interfaces ( 20 ) and Parlay APIs ( 21 ) residing on remote platforms which also host applications ( 10, 13, 14 ) wishing to access the network resources ( 2 ). The network resources ( 2 ) interface directly with the Parlay APIs ( 23 ) if they have Parlay APIs themselves, or otherwise with the interfaces ( 24 ). On the application side, the application interfaces ( 20 ) are provided as Java Beans which may be instantiated by an XML interpreter in response to high level XML commands defining application-side interfacing requirements.

Abstract: Recently there has been an enormous increase in efforts to open up telecommunication networks for application development. In opening up the network, new business models emerge where applications can be developed and provided by enterprises outside the traditional network operator domain. This new business model, combined with the fact that applications can be built using standardized API with off-the-shelf IT technology and tools, will result in new innovative applications that will hit the market with drastically reduced development cycles. This article provides an overview of the Parlay/OSA initiatives concerning the specification of a set of open standardized API. Furthermore, the article outlines some architectural aspects that are implied and implicitly contained in the Parlay/OSA specifications. These are critical for understanding the implications when allowing access to the network via Parlay/OSA. The article then outlines different types of applications that can be built using Parlay/OSA. Finally, we conclude with an analysis of the future of Parlay/OSA.

Abstract: A packet-based communication system comprises first and second endpoints, an application manager and a policy server. When establishing a connection between the endpoints the application manager sends, to the policy server, application control related information about the required connection. The policy server then selects at least one application control parameter, such as a codec to be used by the endpoints, and returns this information to the application manager. The application control information can be carried between the application manager and policy server by an application control protocol, such as the Session Initiation Protocol (SIP), or by modified forms of policy control protocols such as the Common Open Policy Service (COPS), Diameter, SOAP/XML or Parlay.