Real ID Phone
RID Phone

Goal

  • 本計畫基於 Real ID 進而實作出一無線通訊的手機.

Todo

  • Add a packet loss concealment algorithm to Sipdroid.
  • Integrate Real ID.

Abstract

Group Member

Introduction

Features

Framework

1 Integrating Real ID

There are two ways to integrate Real ID into our phone software. One method is simply constructing a mapping between SIP account and Real ID. The other is to build a user location service supporting Real ID directly. Like many other services, these two require the ability to get public information about the owners of Real ID. Moreover, the latter needs to writes some data back to Real ID. It forms a getter/putter interface much like the specification of OpenID Attribute Exchange except that information can be accessed with various permission.

  • Account Mapping
    This method largely depends on Real ID providers and the existing SIP infrastructure. RID Phone simply sends a query to the Real ID provider and expects to receive a SIP account of the specified user. Then it can make calls through the standard SIP mechanism. It is providers’ responsibility to maintain the mapping between SIP account and Real ID. This technique can also be applied to incorporate with other existing accounts such as MSN or web forums’ accounts. The drawback is that every user must first register a SIP account before making calls via RID Phone and the callee needs a SIP account too.
  • User Location Service
    In this method, we would like to implement a user location service which resembles a SIP service and supports Real ID directly. When a user signs into a provider of user location service, the provider sends a request to the Real ID provider to update a field in the user's record. The field contains the access point which can be used to find the user's current location. Information about users' locations is handled by user location service providers so the service can be a distributed system or even a peer-to-peer system and it is independent from Real ID's architecture. They only rely on the interface mentioned above to work in harmony.
    • Location Management
      Locations are treated as soft states so RID Phone needs to sends packets containing the current location periodically after signed into a provider. Generally, the server which the user contacts will be the access point. Other people can send queries to this server to discover the user’s location. Access point can be assigned in other ways, too. For example, one can distributed location information across many servers and choose the server with lowest load as the access point.
Fig.3.1.1 User Agent 1 Login User Location Service.
Fig.3.1.2 Creating a Channel from UA2 to UA1.
2 Packet Loss Concealment

Implementation

1 Required API from Real ID (for Account Mapping)

For the account mapping method, we required only one function:

String getMappedAccount(String id, String serviceType);

The first parameter specifies the Real ID of the target user and serviceType indicates which mapped account should be returned. The returned value is a string representing the mapped account.

Basically, this feature can be implemented in Real ID as a database query if it maintains a mapping table in its database. The table may look like:

SID serviceType account
0123456789 SIP test@iptel.org
1357924680 MSN someone@hotmail.com
…… …………
…… …………
…… …………

Experiment Result

  • TBD.

Conclusion

  • TBD.

Future Work

  • TBD.

Platform

PXA310

OpenMoko

Download

  • TBD.

Minutes

Reference

projects/ridphone/ridphone.txt · 上一次變更: 2009/09/30 15:53 由 whitestone
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0