Subscribe to News
OSAmI-ES Developments
From TechnologicalWiki
Bluetooth Localization Agent
Bluetooth Localization Agent (called codename:Garbo) is an application that is part of the localization mechanism designed to be part of the OSAmI platform. This particular application uses bluetooth broadcasting messages to track devices while they are moving and entering into the detection range of different bluetooth agents.
After installing and configuring this application, it sends XMPP messages reporting when bluetooth provided devices enters or leaves the detection range. These data is used by the Localization Server to provide the information required to perform localization based services.
Bluetooth localization information comes mainly from smartphones, but it also could come from other mobile devices such as headphones, laptops, etc.
- Download here the [Windows installer].
- Download here the source code.
Follow this link to see the codename:Garbo Quick Start Guide, and this one to Test codename:Garbo
If you are wondering why this spy application is called codename:Garbo, the answer is here.
Partner: Telefónica I+D
License: TBD
D2D Communications
D2D communications is a software initiative to provide devices and software with a efficient, fast, lightweight and ubiquitous communication mechanism.
In our first approach, only standard XMPP communications will be available and format checking and parsing should be done at the clients side.
Follow this instructions to integrate D2D to provide your software development with D2D communications.
You can use any of the free XMPP servers on the internet, create your own one or use Telefónica I+D OSAmI XMPP server (osami.tid.es). Currently there is no restriction, and you can register as many accounts as you need. After creating a new account, the server don't let you create another one from the same IP address for a while.
Remember that you can interface with your software from any standard XMPP software (Psi, Pidgin, Pandion, etc) just adding your device address as a buddy (for instance: upnp_render_lounge@osami.tid.es) and sending it a message afterwards. To have your own XMPP account you can use Telefónica I+D OSAmI XMPP server, or any other, such as jabber.com or google talk. XMPP protocol takes care to send messages to the right server when both clients are not on the same domain (for instance: sending a message from myself@gmail.com to upnp_render_lounge@osami.tid.es). Also remember that there are a lot of information sources about XMPP protocol over the internet.
Current enhancement work in progress:
- Automated grouping: Devices belonging to certain system, such as a home, a company, etc should be grouped and linked automatically
- XML checking: Messages may be formated into XML, and standard acknowledge and error messages send from client to client.
Future enhancements:
- Stream Web Service and DPWS communication over XMPP: Provide WS with an ubiquitous addressing mechanism
- Include device status information: Availability, busyness and other device status should be taken into account when sending messages.
Partner: Telefónica I+D
License: TBD
Data Sharing Service (DSS)
One of the main requirements and objectives of the OSAmI platform is to provide the maximun interoperability between services and devices.
In this context, the OSAmI Data Sharing Service aims to provide a data-centric, resource-oriented collaboration framework for services to interoperate by means of data publication and subscription, allowing all the relevant data in an OSAmI System to be addressable through URLs from any OSAmI domain within the system.
Some general constraints on the data must be fullfiled in order to be able to share it. These constraints and the operations that can be performed on the shared data are presented in the following subsections.
Constraints on the shared data
The DSS will support the publication of objects qualifed as shareable. An object is shareable if it complies with one of the following constraints:
- It is a number, a string or a boolean value. From now on we will refer to these kind of objects as basic objects.
- It is a set of key/value pairs, where the keys are strings and the values are in turn shareable objects. From now on we will refer to these kind of objects as compound objects.
- It is an unordered set of shareable objects. From now on we will refer to these kind of objects as container objects.
Operations on the shared data
The DSS offers a uniform interface that will support the basic CRUD operations on resources, and then some a bit more advanced.
In particular, the basic CRUD operations are:
- Publication of an object as a resource under a particular URL.
- Update of an object under a particular URL.
- Retrieval of an object published under a particular URL.
- Deletion of a resource under a particular URL.
The rest of the operations supported are:
- Addition of an object to an existing container resource.
- Retrieval of a fltered set of objects in a container resource.
- Deletion of a fltered set of objects in a container resource.
The interface of the Java Client is:
package osami.dss.client;
public interface OSAmIDSSClient {
<T> T get (String url, Class<T> clazz);
void put (String url, Object obj);
void post (String url, Object obj);
void delete(String url);
}
Publishing a resource
A java object fulflling the constraints specifed can be published as a shared resource by invoking the PUT method in the Java DSS Client, passing as arguments a valid URL and the object to publish.
Device mytv = new Device(); mytv.setDescription(“Blah blah blah”); ... osamidss.put(“osami://myhome/mytv”, mytv);
In the case of compound objects, their properties are also accessible directly by adding the name of the particular property to the URL of the object, i.e. each property of a compound object is also an object which is published under its own URL, relative to the URL of the compound object, adding the property name.
In the example above, the operation would result in the publication of the whole device under the URL "osami://myhome/mytv", but the description property would also be accessible under the URL "osami://myhome/mytv/description".
Updating a resource
A resource is updated exactly the same way it is published, by the invoking PUT method passing URL and object.
For example, we could update the description of the device in the previous example this way:
osamidss.put(“osami://myhome/mytv/description”, “some new description”);
Retrieving a resource
In order to read a resource, the GET method must be invoked and two arguments passed to it:
- The URL under which the required resource is published.
- The data type to be used to hold the information, i.e. a Class object of the requested resource.
Then, the GET method returns an instance of the specifed class containing the information published in the requested resource.
Following the same example as in the previous subsections, if we invoke the following command:
Device mytv = osamidss.get(“osami://myhome/mytv”, Device.class);
We get a Device instance in which the description property contains the string "some new description".
If we instead had invoked:
String mytvdescription = osamidss.get(“osami://myhome/mytv/description”, String.class);
We would have obtained only the String object "some new description".
Deleting a resource
The URL of the resource to delete is the only thing required to invoke the DELETE method.
osamidss.delete(“osami://myhome/mytv”);
Then, the "osami://myhome/mytv" resource would not exist anymore.
Adding a resource to a container resource
To add an object to a container resource (array), the POST method must be invoked, receiving two arguments:
- The URL of the container resource (the resource must already exist).
- The object to add.
So, this would be an example:
Book newbook = new Book();
newbook.setTitle("El Club Dumas");
newbook.setISBN("84-226-9489-1");
newbook.setAuthor("Pérez-Reverte, Arturo");
newbook.setYear(2000);
osamidss.post("osami://abc-library.com/bookcatalog", newbook);
Where "osami://abc-library.com/bookcatalog” would be a pre-existing container resource to which the newbook is added.
Querying a container resource
Container resources can be retrieved as any other resource, as a whole, just specifying its URL and type:
Book[] books = osamidss.get(”osami://abc-library.com/bookcatalog”, Book[].class);
However, it is possible to flter the elements to retrieve by specifying flters in the URL. This flters are key-value pairs that have to be matched by the elements in order for them to be included in the returned resource:
Book[] booksFrom2000 = osamidss.get(”osami://abc-library.com/bookcatalog?year=2000”, Book[].class);
Removing resources from a container resource
Similarly, container resources can also be deleted completely, or also remove from it only the elements passing a filter:
// To remove only the books published in 2000 osamidss.delete(”osami://abc-library.com/bookcatalog?year=2000”); // To remove the container itself osamidss.delete(”osami://abc-library.com/bookcatalog”);
Subscribing to data. Eventing.
TBD
Partner: Telvent
License: TBD
Device Abstraction (DA)
To be approved. Code and documentation available soon
Partner: Telvent
License: TBD
Data remote persistence
To be approved. Code and documentation available soon
Partner: Telvent
License: TBD
Edutainment client
The edutaiment client will be the responsible of showing the course player to the user that is using some computer. It will be activated through XMPP messages received from the EdutaimentRuleService. This service will subscribe to the location events generated by the location server and it will apply a set of rules to this events and decide in which user computer it has to launch the course player. When starting the course player in some user computer, the rule service can tell the edutainment client to show the list of available courses to the user or to start some course in a certain point of it. The XMPP messages exchanged between the rule service and the edutainment client will be the following:
-One type of message to start the course player:
#The rule service will send this message to the edutainment client to start the course player
<edutainment type="clientStartReq">
<course> #This tag is optional, it lets the rule service to specify which course to play
<id>[course_id]</id> #An identifier for the course that is going to be played
<sco id="[id_sco]" timestamp="[timestamp]"/> #This tag is optional, it lets the rule service
#to specify from which SCO start the course, id is an identifier for the SCO, timestamp
#is the instant to start the SCO if it has a video
</course>
<user id="[user_id]"/> #This tag specifies the user that is going to use the edutainment service,
#id is an identifier for the user
</edutainment>
#This is a reply message for start request message
<edutainment type="clientStartRes"> <status>ok/error</status> #ok if the course player was started, error otherwise </edutainment>
-One type of message to stop the course player:
#The rule service will send this message to the edutainment client to ask it for stopping the course player
<edutainment type="clientStopReq"/> #This messages doesn't require any parameter
#This is the reply message for the stop request message
<edutainment type="clientStopRes">
<status>ok/error</status> #ok if the course player was stopped, error otherwise
<course> #This tag is optional, only required in the case a course was being played by the time
#the stop request was received
<id>[course_id]</id> #An identifier for the course
<sco id="[id_sco]" timestamp="[timestamp]"/> #This tag is optional, only required if the user
#was inside of an SCO by the time the stop request was received, id is an identifier
#for the SCO and timestamp is the instant in which the video was (just for the SOCs
#with videos)
</course>
</edutainment>
The architecture needed for deploying this kind of context aware service is showed in the next figure:
First the edutainment rule service is configured to be subscribed to the location events captured in the places where a computer with the edutainment client deployed is available. Every time a location event is received the edutainment rule services evaluates the received event through a set of rules that let it decide to start or to stop the edutainment client in the place where the event was generated. If it has to start the course player, firts it looks if there is a previous saved state for the user and then it generates a XMPP message that will be send to the edutainment client. If it has to stop the course player it generates a XMPP message and sends it to the edutaiment client, then waits for the repply, once it is received it stores the state information received for the user. Every Edutainment client needs to be configured with its own XMPP account in order to be able to receive the XMPP messages from the rule service (which needs a xmpp account too). In the figure we can see that the Bluetooth location service is the deployed in the same computer as the Edutainment client, when a user device (e.g. a mobile phone) enters its range it will send a XMPP message to the location server, this will trigger an event in the location server that will send a XMPP message to the rule service to tell it that a user device was detected in the range of that computer, then the rule service will decide if it has to send a XMPP message to the edutainment client to start the course player. If the user device leaves the range of the Bluetooth location service the same kind of XMPP messages will be exchanged with the difference that the rule service will have to decide if it has to stop or not the course player in the corresponding Edutainment Client.
Partner: University of Vigo
License: TBD
Edutainment Auditor
The Edutainment auditor is a desktop application that lets the users create and publish e-learning courses. It is not an application launchend by some context-aware mechanism but it is launched by the user whenever he needs to use it. The edutainment auditor lets the user define the rules about in which context a course will be played, e.g. a course could be the designed to only be played in the job computers of the users but not in the home computers, or to only be played in the mornings. These courses will be also adapted to the user profile, in the way that its contents and display will be matched to the user preferences.
Partner: University of Vigo
License: TBD
GPS Location agent
GPS Location agent is a background service running on Android OS capable to send GPS and Cell locations to the Location Server.
There's an Internet-Draft discussed on 2009 Dec OGC Indoor Location, 3d, indoor navigation special meeting [1] that suits our needs of transmit location data: Presence Information Data Format (PIDF) [2]
An Example of PIDF document:
Examples
<civicAddress xml:lang="en-AU"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AU</country>
<A1>NSW</A1>
<A3>Wollongong</A3>
<A4>North Wollongong</A4>
<RD>Flinders</RD><STS>Street</STS>
<NAM> Video Rental Store </NAM>
<PC>2500</PC>
<INT N='Room' R='A'>Westerns and Classics</INT>
</civicAddress>
There are also some extensions for indoor location [3] where an indoor location is encoded by proximity to a reference location, a shape, and x,y,z offsets.
4 shapes are defined:
Point
The point shape includes the reference, the shape type, and offset measurement values for X, Y, and optionally Z.
<INT N='Reference'>Front Door</INT> <INT N='Point'/> <INT N='SHAPE-OFFSET-X'>+25</INT> <INT N='SHAPE-OFFSET-Y'>+10</INT> <INT N='SHAPE-OFFSET-Z'>+10</INT> (optional)
+--------------------------------------x
| SHAPE-OFFSET-X
|
|
|
| SHAPE-OFFSET-Y
|
|
REF
Point example:
<country>US</country>
<A1>Florida</A1> <A3>Miami</A3> <HNO>8200</HNO> <PRD>NW</PRD> <RD>41st</RD> <STS>Street</STS> <PC>33166</PC> <FLR>4</FLR> <INT N='Suite'>400</INT> <INT N='Reference'>Front Door</INT> <INT N='Point'/> <INT N='SHAPE-OFFSET-X'>+25</INT> <INT N='SHAPE-OFFSET-Y'>+10</INT> <INT N='SHAPE-OFFSET-Z'>+10</INT>
Circle:
The circle shape includes the reference, shape type, offset
measurement values for the X, Y, and optionally Z of the center point of the circle, and a radius value. See Figure 2.
<INT N='Reference'>Front Door</INT> <INT N='Circle'/> <INT N='SHAPE-OFFSET-X'>+34</INT> <INT N='SHAPE-OFFSET-Y'>-9</INT> <INT N='SHAPE-OFFSET-Z'>+5</INT> (optional) <INT N='Radius'>4</INT>
REF
|
|
|
|
| SHAPE-OFFSET-Y _,...._
| ,-' `-.
| ,' --,`. RADIUS
| / ,'| \
| .' / '.
| | ,' |
+-----------------------------+---------x |
SHAPE-OFFSET-X \ /
\ /
`. ,'
`. ,'
`--...--'
Circle Example
<country>US</country> <A1>Florida</A1> <A3>Miami</A3> <HNO>8200</HNO> <PRD>NW</PRD> st <RD>41 </RD> <STS>Street</STS> <PC>33166</PC> <FLR>4</FLR> <INT N='Suite'>400</INT> <INT N='Reference'>Front Door</INT> <INT N='Circle'/> <INT N='SHAPE-OFFSET-X'>+34</INT> <INT N='SHAPE-OFFSET-Y'>-9</INT> <INT N='SHAPE-OFFSET-Z'>+5</INT> <INT N='Radius'>4</INT>
Arcband
The arcband shape includes the reference, shape type, offset measurement value of the central point, the optional Z value, the inner and outer radius values, the start angle, and the opening angle.
<INT N='Reference'>Front Door</INT> <INT N='Arcband'/> <INT N='SHAPE-OFFSET-X'>+17</INT> <INT N='SHAPE-OFFSET-Y'>-2</INT> <INT N='SHAPE-OFFSET-Z'>+2</INT> (optional) <INT N='InnerRadius'>8</INT> <INT N='OuterRadius'>18</INT> <INT N='StartAngle'>329</INT> <INT N='Opening'>82</INT>
_,,..,--------....__
`--..
\ ``-.
REF \ `-._
| \ `.
| \ ;>
| \ ,'
| \ __......__ ,'
| .- `--._ ,'
| \ `. / OuterRadius
| `. `.,'
| SHAPE-OFFSET-Y | Opening ,'
| | Angle ,'
| `. /
| | ,'
| | ,'
| Start `. ,' InnerRadius
| Angle | /
| | ,'
+------------------------------------x
SHAPE-OFFSET-X
Arcband example
An example of an arcband shape included in the whole of the civic location elements would be:
<country>US</country> <A1>Florida</A1> <A3>Miami</A3> <HNO>8200</HNO> <PRD>NW</PRD> <RD>41st</RD> <STS>Street</STS> <PC>33166</PC> <FLR>4</FLR> <INT N='Suite'>400</INT> <INT N='Reference'>Front Door</INT> <INT N='Arcband'/> <INT N='SHAPE-OFFSET-X'>+17</INT> <INT N='SHAPE-OFFSET-Y'>-2</INT> <INT N='SHAPE-OFFSET-Z'>+2</INT> <INT N='InnerRadius'>8</INT> <INT N='OuterRadius'>18</INT> <INT N='StartAngle'>329</INT> <INT N='Opening'>82</INT>
Polygon
The polygon shape includes the reference, the shape type, the number of polygon points, the offset measurement value for each point, optionally a calculated geo center point of the polygon, and the optional Z value. This example shows a single Z value for the entire shape. See Figure 4.
<INT N='Reference'>Front Door</INT> <INT N='Polygon'/> <INT N='PolygonPoints'>5</INT> <INT N='SHAPE-OFFSET-X'>-18</INT> <!-A-X--> <INT N='SHAPE-OFFSET-Y'>-8</INT> <!-A-Y--> <INT N='SHAPE-OFFSET-X'>-20</INT> <!-B-X--> <INT N='SHAPE-OFFSET-Y'>-5</INT> <!-B-Y--> <INT N='SHAPE-OFFSET-X'>-25</INT> <!-C-X--> <INT N='SHAPE-OFFSET-Y'>-6</INT> <!-C-Y--> <INT N='SHAPE-OFFSET-X'>-25</INT> <!-D-X--> <INT N='SHAPE-OFFSET-Y'>-10</INT> <!-D-Y--> <INT N='SHAPE-OFFSET-X'>-20</INT> <!-E-X--> <INT N='SHAPE-OFFSET-Y'>-13</INT> <!-E-Y--> <INT N='SHAPE-OFFSET-X'>-18</INT> <!-A-X--> <INT N='SHAPE-OFFSET-Y'>-8</INT> <!-A-Y--> <INT N='SHAPE-GEOCENTER-X'>-10</INT> <!-Center-X--> (optional) <INT N='SHAPE-GEOCENTER-Y'>-20</INT> <!-Center-Y--> (optional) <INT N='SHAPE-OFFSET-Z'>+10</INT> (optional)
REF
|
|
|
|
| SHAPE-
| OFFSET-Y(A)
|
|
|
SHAPE-OFFSET-X(A) |
_,.-------------------------------------+ SHAPE-
_,,-' `. | OFFSET-Y(B)
_,.- \ SHAPE-OFFSET-X(B) |
'------------------\--------------------------------+
| \ | SHAPE-
| `. | OFFSET-Y(C)
| \ |
| \ SHAPE-OFFSET-X(C) |
| ;--------------------------+ SHAPE-
| ,-' | OFFSET-Y(D)
| ,' SHAPE-OFFSET-X(D) |
':----------------;----------------------------------+
`-. ,' | SHAPE-
`. ,-' | OFFSET-Y(E)
`-. ,' SHAPE-OFFSET-X(E) |
'------------------------------------------+
Figure 4 - Polygon Shape
Polygon example
An example of a polygon shape included in the whole of the civic location elements would be:
<country>US</country> <A1>Florida</A1> <A3>Miami</A3> <HNO>8200</HNO> <PRD>NW</PRD> <RD>41st</RD> <STS>Street</STS> <PC>33166</PC> <FLR>4</FLR> <INT N='Suite'>400</INT> <INT N='Reference'>Front Door</INT> <INT N='Polygon'/> <INT N='PolygonPoints'>5</INT> <INT N='SHAPE-OFFSET-X'>-18</INT> <!-A-X--> <INT N='SHAPE-OFFSET-Y'>-8</INT> <!-A-Y--> <INT N='SHAPE-OFFSET-X'>-20</INT> <!-B-X--> <INT N='SHAPE-OFFSET-Y'>-5</INT> <!-B-Y--> <INT N='SHAPE-OFFSET-X'>-25</INT> <!-C-X--> <INT N='SHAPE-OFFSET-Y'>-6</INT> <!-C-Y--> <INT N='SHAPE-OFFSET-X'>-25</INT> <!-D-X--> <INT N='SHAPE-OFFSET-Y'>-10</INT> <!-D-Y--> <INT N='SHAPE-OFFSET-X'>-20</INT> <!-E-X--> <INT N='SHAPE-OFFSET-Y'>-13</INT> <!-E-Y--> <INT N='SHAPE-OFFSET-X'>-18</INT> <!-A-X--> <INT N='SHAPE-OFFSET-Y'>-8</INT> <!-A-Y--> <INT N='SHAPE-GEOCENTER-X'>-10</INT> <!-Center-X--> <INT N='SHAPE-GEOCENTER-Y'>-20</INT> <!-Center-Y-->
[1] http://www.ogcnetwork.net/node/624
[2] http://tools.ietf.org/html/draft-rosen-geopriv-pidf-interior-00
[3] http://portal.opengeospatial.org/files/?artifact_id=36484
Partner: Prodevelop
License: TBD
Location server
Location server is an Internet service that allows devices and users to report their position to be stored into a database, processed by a event triggering software and used by location based services. The service communicates with devices and agents by means of D2D infrastructure and XMPP messages addressed to
- locserver@osami.tid.es
and formated as an XML file.
All XML files have the same structure, and the content changes depending on the nature of the message:
Examples:
- device localization report
- search devices on the database and server answer
- link or unlink a user to a device
- define a new rule, define another one, search rules on the database, server answers the search, and delete a rule
- Server sends an event
- XML validation DTD file
Partner: Telefónica I+D
License: TBD
Mobile map client
Mobile map client is an application running on Android OS that is capable to show exterior maps from several sources (Open Street Maps and other tile serveres, WMS-c servers) and indoor plans of buildings. It can receive messages from Location Server and Bluetooth Agents to show the location of other devices over the maps and plans.
The format to specify indoor buildings plans is being evaluated. There are several OGC proposals such as IndoorML, Open floor plan, etc. More info [1]
[1] http://www.ogcnetwork.net/node/624
Partner: Prodevelop
License: TBD
Osamidroid
Not available yet.
Partner: Telefónica I+D
License: TBD
OSGI base driver for Zigbee
Not available yet.
Partner: Aicia
License: TBD
Position transformation server
This service is intended to be used by other services at the location server. Not designed to be used from mobile devices. It aims at providing a transformation between agent identifiers and their location, as well as for getting semantic information about a location. Two public methods will be provided:
- getPosition(). Given an agent identifier, it returns its location.
- Inputs:
- Identifier and agent type. E.g:
- agent type="BT"> #Tipo: bluetooth
- <id>08:00:69:02:01:FC</id> # Agent's ethernet MAC address
- </agent>
- User identifier. e.g:
- <address>mmontesinos@prodevelop.es</address> # User xmpp address
- Identifier and agent type. E.g:
- Output: Location info, which comprises:
- Building.
- Floor.
- Room/Area.
- X-Y / Polygon geometry. TBD (WKT, GML or GeoJSON).
- SRS (Spatial Reference System) using EPSG codes.
- Inputs:
- getZone(). Given an X-Y pair of coordinates, it returns the room/area in the building:
Here, a sequence diagram of a mobile device going into a building for the first time is displayed.
Partner: Prodevelop
License: TBD
Secure Localization Agent
At this stage we have focused on providing a localization mechanism that makes use of a secure challenge response mechanism. For secure we mean that one person can not impersonate another one and that only trusted entities are able to track the location of the users in the system.
For this purpose we have first developed an early implementation using TinyOS and Wireless Sensors whit also provides shorter range localization. In this first version we have focused on providing an scheme that avoid tracking of users by untrusted entities. All trusted entities share a commong key that is used to cipher the comunications. In this way, users that are outside of this circle of trust can not track legitimate users.
We have also add XMPP capabilities to our localization service and will connect it to the localization service from TID soon.
No public development is available yet
Partner: University of Malaga
License: TBD
SIP Agent and Proxy server
The SIP Agent provide the functionality of SIP protocol to UPnP devices. We use it to stablish videocall with UPnP devices that they are in others networks and due to his mobility they change of network
TheProxy server registers the SIP address of each device.
Both elements are developed.
Partner: University Carlos III of Madrid
License: TBD
Total Videconf
The goal of “Total Videoconference” can be resumed in the following steps:
- a)When some person accesses the videoconference room, a presence sensor detects him.
- b)The system checks the calendar of this person and checks if there is a planned event in short and where. In this case, a videoconference is planned at a certain hour with a customer in the videoconference room.
- c)The customer’s videoconference number is retrieved from the contacts of this person.
- d)A videoconference with the customer is established automatically at the scheduled time.
Total VideoConference is based on the orchestration of several Web Services using WS-BPEL. BPEL is the standard language defining structures to write and orchestrate business processes.It defines a set of basic control structures like conditions or loops as well as elements to invoke web services and receive messages from them.
We have several orchestrated web services to fulfil our purpose. One of this web services is the Xmpp Web Service.It is responsible for sending the location of the detected bluetooth device to the location server locserver@osami.tid.es via xmpp. The information sent is formatted as an XML file, having the same structure defined by the DTD file provided by Telefonica i+d on this Osami Media Wiki.
To realise the xmpp connections the web service uses an own java client using the java smack API directly. Once the xmpp location server response is received, our system can continue the normal work flow and the video conference could take place.
If the desired response from the server is not received, the TotalVideoConference service is interrupted. In other words, the response received from the location server acts as a necessary permission for the performance of our service.
Actual development status:
- The development of the Xmpp Web Service is completed. To testing the xmpp interaction of the localization server we have been using some testing accounts on the “osami.tid.es” domain simulating the hypothetical response of the localization server (by using some instant messaging clients like pidgin or pandion or by using perl scripts to implementing an echo response).
Partner: Vodafone
License: TBD
UPnP Control Point
The Control Point devices have the aim of cotrolling and detecting through UPnP protocol others devices in the same UPnP local network. In our case, beside that it is able to comunicate with SIP agent to register it and it finds devices that are in external networks.
It's posible change messages with others devices through XMPP protocol too. it is based on Cidero.
Partner: University Carlos III of Madrid
License: TBD
UPnP MediaServer and UPnP MediaRenderer
The UPnP MediaServer is a server that stores and shares its multimedia content, this devices use the UPnP protocol to comunicate with others devices its presence and to give information about its contents.
The MediaServer's aim in our case is to provide the video captured by a webcam to others devices with UPnP. It is implemented and its based in Cibermediagate.
The MediaRenderer devices are media players that play the mediasever's content. This devices are controlled by ControlPoint devices throught UPnP protocol and in our case, they show the video captured by the camera of the MediaServer.
we have implemented the device.
Partner: University Carlos III of Madrid
License: TBD
MediaWorld server
MediaWorld server is an Intranet service that allows to communicate with UPnP devices to request resources information or command actions over the intranet. The service communicates with devices and resouerces by means of D2D infrastructure and XMPP messages formated as an XML file.
All XML files have the same structure, and the content changes depending on the nature of the message:
Partner: Telefónica I+D
License: TBD
Return to OSAmI-ES
