Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Dean Bubley’s Mobile and wireless predictions for 2008: http://disruptivewireless.blogspot.com/2007/12/mobile-and-wireless-predictions-for.html
  • http://www.netlab.tkk.fi/tiedotus/seminar/
  • Planned presentation length 30-60min.
  • An XML STREAM is a container for the exchange of XML elements between any two entities over a network. An XML STANZA is a discrete semantic unit of structured information that is sent from one entity to another over an XML stream. A SERVER is an entity whose primary responsibilities are to: - Manage XML streams (XML Streams) with local clients and deliver XML stanzas (XML Stanzas) to those clients over the negotiated XML streams. - Subject to local service policies on server-to-server communication, manage XML streams (XML Streams) with foreign servers and route XML stanzas (XML Stanzas) to those servers over the negotiated XML streams. Client – server protocol. P2P only possible for multimedia communication services (voice, video). One session; no need to authenticate each message. Always-on connections for the life of the client's session on the server. XML stream acts as an envelope for all the XML stanzas sent during a connection. One TCP connection necessary between client and server. Two TCP connections between servers. Three stanza options: presence, message and iq (information query). Strict stanza structure. Tthere can be own x-elements inside stanzas. If recipient don’t understand some elements, those are skipped. As XMPP is stream based it is well suited for real time services. Moreover, the fact that it is XML based makes it usable in real life (simple protocol, interoperability, parsing, extensibility, …, coder friendly)
  • Any number of stanzas sent during the life of the stream.
  • After a client has connected to a server or two servers have connected to each other, either party can send XML stanzas over the negotiated stream. After the possible channel encryption, authentication and resource binding a common first stanza from client to server is initial presence, which in its simplest form is “<presence>”.
  • A client sends presence to its server, and server then broadcasts that information to all of the client's contacts who have a subscription to the client's presence (such contacts are those that are present in the user's roster with the 'subscription' attribute set to a value of "from" or "both“). Server adds from and to fields to the presence stanza ( from field is always overwriten by the server to the stanzas sent by a client; from field spoofing difficult ) Presence stanza can have multiple attributes that define the presence state more in detail. Show element describes the availability of the client. It can have the following potential values: away -- The entity or resource is temporarily away. chat -- The entity or resource is actively interested in chatting. dnd -- The entity or resource is busy (dnd = "Do Not Disturb"). xa -- The entity or resource is away for an extended period (xa = "eXtended Away"). Status element is meant for human readable description, e.g., <status>On the phone</status> Priority element specifies the priority level of the resource, e.g., <priority>5</priority>. Default = 0, min = -128, max = 127.
  • After a client has connected to a server or two servers have connected to each other, either party can send XML stanzas over the negotiated stream. Here is an example of iq (information query) type stanza. Client queries for user’s roster (buddy list), which is stored in the server. Server returns the roster. An item (contact) in roster can belong to a group (in the example romeo belongs to Friends) and can have a nickname (name=‘Romeo’). Contacts in the roster can be from different domains (example.net and example.org). Subscription attribute can have one of the values: "none", "to", "from", or "both". Subsctiption means whether contacts have subscripted to see each other’s presence information. There may be no subscription (none), only to other direction (to or from) or both ways (both). XMPP server has buddy list management inherently.
  • After a client has connected to a server or two servers have connected to each other, either party can send XML stanzas over the negotiated stream.
  • Jabber is now 9 years old. Jeremie Miller started the jabberd IM server implementation nine years ago in 1998 (an open-source, GPL-licensed project from start) http://slashdot.org/article.pl?sid=99/01/04/1621211 Refined in Jabber community (nowadays XMPP is the protocol and Jabber is the community ) Standardization work started in 2002 in the IETF XMPP WG. Base specs released in Oct 2004: RFC3920 Core RFC3921 IM and presence RFC3922 Mapping XMPP to Common Presence and Instant Messaging (CPIM) RFC3923 End-to-End Signing and Object Encryption for XMPP Peter Saint-Andre is Executive Director of the XMPP Standards Foundation (XSF) and the most active contributor currently in the XMPP standardisation. Most standardisation work happens in XSF (xmpp.org) where XMPP extension protocols (XEPs) are defined. Only the core protocol etc. are defined in the IETF. Strong commitment to interoperability Implementations drive standardisation Keep the protocol simple Open and standard protocol XMPP sponsors: Google, HP, Jabber Inc, AG Software, Antepo, Coversant, DreamHost, Jive Software, Zettai,..
  • One can say that XMPP approached under the radar for years. XMPP was noticed only after Google talk was launched (Aug 2005). Later on (Feb 2006) Google integrated chat to Gmail, which most likely multiplied the amount of presence traffic by X. A video describing GTalk scalability: http://googletalk.blogspot.com/2007/09/lessons-in-building-scalable-systems.html Gizmo project used XMPP for presence and IM (SIP for voice) already before Google. LiveJournal LJ username is automatically user’s XMPP username Notifications, voice posting and text messaging LJ talk can be used with any XMPP client One
  • There are companies that make money with XMPP and the money is not just in basic presence and IM solutions. XMPP server providers concentrate on enterprises . Consumer IM space is crowded. XMPP-based servers can be hosted in-house (IBM, Microsoft, et co. as competitors). XMPP suitable for interdomain federation. XMPP support by other presence server vendors is increasing Gatewaying is an important part of presence server solutions. Adobe acquired Antepo in January 2007. Strongest players are building on top of open source servers by adding scalability and fault tolerance. Jabberd (Jabber, Inc), ejabberd (Process-One) and Openfire (Ignite Realtime) XMPP is strongly client-server oriented, which gives power to the server vendors. Enterprises: HP, EDS, FedEx, Oracle, Sun, Wall Street banks US Government: SIPRnet, Defense Information Systems Agency (DISA) approved, … In 2006 XMPP was approved by the US Department of Defense’s (DoD) for inclusion in the official DoD IT Standards Registry (DISR). XMPP the only approved IM standard approved by the DISR. Universities: MIT, Penn, Duke, Wisconsin, … (see DNS entries: http://utility.nokia.net/~lars/meter/data/2007-12-25-ietf-xmpp.txt ) Standardisation still driven mostly by the same companies/persons than previously, just more actively. Industry push still small.
  • Telecom sector also uses XMPP, but solutions are still mainly presence and IM: Portugal Telecom Large scale deployment in use Sponsor for Psi (maybe the most popular XMPP PC client) SAPO Messenger for Windows (Psi recommended for Mac / Linux) France Telecom (Orange, Wanadoo) Jabber, Inc’s investor (acquired 23% stake of Jabber, Inc. already in 2001) Jabber, Inc.’s Jabber XCP platform BT Jabber Inc. (Jabber XCP platform) provides IM Common Capabilities for BT 21st Century Network NTT Secure instant messaging system using XMPP AT&T (former BellSouth solution) AT&T Messenger XMPP PC client available for certain AT&T customers Earthlink Mindspring Messenger PC client that has / had voice with SIP, IM & presence with XMPP GMX (German ISP) MultiMessenger PC client with voice, video, IM and presence
  • XMPP is suitable for services that need a session to send messages. These messages may contain basically anything (text, images, commands, etc.), but streamed voice or video. Session initiation for multimedia communication can be done by exchanging XMPP messages, but compared to, e.g., SIP the session initiation process misses a lot of details that are defined in SIP. Framework that defines initiating and managing of peer-to-peer multimedia sessions (e.g., voice and video chat) between two XMPP endpoints is called Jingle . It is an XMPP extension, but still under work. No intension to standardise, e.g., supplementary services. Extension initiated and driven by Google. Incentive for other players to implement voice is to call to Gtalk. Source code and documentation for libjingle available. Gtalk implementation varies slightly from the proposed XEPs. Implementations currently support Google Talk version. Good interoperability as basically everyone uses the same libjingle library. ICE for firewall traversal. Lacking PBX, PSTN gateway, SBC and hardphone solutions. So, good enough for pure VoIP. Keep the protocol simple and easy to implement. No intension to standardise, e.g., supplementary services. No intension to replace SIP, but instead to interwork. Jingle (initiating and managing p2p interactions) seen important in order to add basic voice chat, video chat, and real-time multimedia functionality (e.g., screen sharing) to existing and future XMPP clients Nokia Internet tablet (N700) was the first device to support Jingle. THE VOICE logo is registered mark of SBS Broadcasting Networks Limited; www.voice.fi
  • New XMPP extensions are popping up more often than couple of years ago. And a lot of new ideas are waiting in the “inbox” http://www.xmpp.org/extensions/inbox/ XMPP is client-server No proxy elements. Scalability not part of XMPP as such , so service providers have to consider scalability themselves. However, clustering is a common solution implemented in XMPP servers (ejabberd, Openfire), but that is not defined in XMPP standardisation. Basically any XMPP feature (commonly gateways to other protocols or chat rooms) can be implemented as XMPP server components . There is a standard interface between XMPP server and the server component (XMPP ;-), so no server vendor lock-in. Also plugins can be done, but they are server specific. XMPP service discovery is used to find available services. It works and is simple. XMPP has a lot of features that are supported by the servers: publish-subscribe, multiuser chat, chat rooms, buddy-list management, etc. XMPP works through NATs; by default it uses TCP and also http bindings exists.
  • XMPP has good potential to be used as a real-time protocol for Internet services. XMPP is used, e.g., by: Twitter, Jaiku, Joost (IP TV), me.dium (shared browsing), chesspark, Inkscape (whiteboarding), trakm8 (vehicle tracking), One Laptop per Child (OLPC), FreeSwitch, Asterisk, Apple iChat & Bonjour (link-local messaging; also used in OLPC), meebo (browser based IM), Nokia Internet tablets… XMPP is used in the IETF meetings. Current Internet XMPP implementations can be roughly divided into three categories: presence & IM (e.g. meebo, Joost), micro blogging (Jaiku, twitter) and others (Me.dium, TiVo). We might see a lot more use cases for XMPP in the future. XMPP can be described as an open standardised enabler/protocol for real time services . XMPP is suitable for interdomain federation and there are components available to connect to MSN, Yahoo!, AOL, etc. One important point is that XMPP has http bindings . XMPP library available for Adobe Flash, but that is not offered by Adobe. Also http implementation still missing. XMPP extensions personal eventing protocol (PEP) and heavier publish-subscribe (pubsub) profile for personal data publishing adapt XMPP, e.g., to social networking applications. Problem is that especially pubsub is considered to be too heavy; consequently, developers may implement proprietary extensions. TiVo (digital video recording in USA and Canada) switched from polling to XMPP: “ TiVo is using XMPP now instead.”… “Yep, TiVo is basically using instant messaging for real-time communication. Now when the TiVo server has a new recording to schedule, it will IM the TiVo to tell it. Or if there is a download to pull, it will IM the TiVo to tell it to do so. This is a much more efficient system and it eliminates latency. It is really a clever idea.” “ Replacing polling with XMPP opens the door to all kinds of improvements. Instant starts to downloads of TiVoCast or Unbox video, or any other video source, such as Music Choice music videos. If there is a schedule change that impacts your TiVo, TiVo could tell your box to grab it right now instead of waiting a day. It even opens the door to possibly handling last minute changes such as sporting events running long, Presidential addresses, and other events that bump the schedule at the last minute. TiVo’s servers could instantly IM units to warn them of the changes. “ http://www.tivolovers.com/2008/01/08/some-more-on-tivo-desktop-plus-26-web-video/
  • Publish-Subscribe an enabler for social networking services; user mood, user tune, user avatar, etc. Google is the main driving force behind the Open Handset Alliance (OHA), which is a consortium of over 30 hardware, software and telecom companies. Android is a Linux mobile phone platform developed by OHA. SDK is available for developers and first actual phones should be out in the end 2008. Google offers its own services and APIs on top of the Android platform, consequently; these services, such as XMPP, are fixed to using Google services. http://www.openhandsetalliance.com/ http://code.google.com/android/toolbox/google-apis.html
  • Jabber.org for list of available projects, products, etc. “ Developer friendly ” means a lot in the Internet. In the end it’s a question about cost of byte (to make money) and possibilities to extend the service (to keep and atract users). Security is not touched too deeply in this presentation. XMPP has security mechanisms and already the fact that XMPP is client-server protocol and uses TCP, gives XMPP services a better shield towards attacks compared to, e.g., email.
  • PSTN replacement services are the most visible SIP services. Good support for SIP exists in PBXs, PSTN gateways, hard phones, etc. VoIP RFC Watch illustrates the enormus growing rate of RFCs which are related to SIP or VoIP in general . http://rfc3261.net/ SIP has looser structure, which causes interoperability problems and results in more specifications. Interdomain presence analysis revealed that XMPP requires only about 3,8 - 4,4% of the bandwidth required by SIMPLE XMPP: http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-02.html SIMPLE: http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-02 Roughly 1/3 of the messages with XMPP In XMPP no 200 OK for each message, no refresh for subscriptions, … Smaller messages with XMPP No complicated header structures, which also cause interoperability problems and are difficult to parse Analysis did not take into account any optimisations, such as compressions. We cannot say what is the final answer as there are no SIMPLE large scale implementations that could be used as reference (except for MSN, Yahoo, that have something similar). In case of XMPP there are several implementations available so facts are better known. SIP can use either UDP or TCP. UDP causes troubles with NATs and firewalls. SIP is message based protocol whereas XMPP has a constant TCP connection. Consequently, SIP needs more messages to transfer the same amount of information. The proxy functionality in SIP enables use cases that are difficult to achieve with XMPP ; these uses cases relate especially to voice services. Lately activity around specifiyng SIP-XMPP interconnectivity has risen. Internet-Drafts exists for core, presence, IM, chat and media. http://www.xmpp.org/internet-drafts/ Most popular IM services (Yahoo, MSN, AOL, ICQ) use proprietary protocols. XMPP gateway server components exists that can connect to these domains. Need for gateways seems to be a growing trend . Broker functions already exist between SIP domains to offer interconnectivity. XMPP Federation (xmpp.net) offers free digital certificates for use on the XMPP network. By default XMPP offers interconectivity between XMPP domains.
  • 20080111.ppt

    1. 1. <ul><ul><li>“” How much richer would it be if the network could extract more useful 'state' information about the device and/or user, especially if it is enriched with embedded sensors... &quot;phone on charge&quot;, &quot;user is on a Bluetooth headset&quot;, &quot;battery low&quot;, &quot;at location xyz&quot;, &quot;moving in a way that looks like it's on train&quot;, &quot;in a darkened room&quot; and so on.... . “” </li></ul></ul><ul><ul><li>Dean Bubley 2008 </li></ul></ul>
    2. 2. XMPP - Extensible Real-Time Services Research Seminar for Dept. Communications and Networking (TKK) Matti Vesterinen 11.1.2008 Note: Slide notes contain more info!
    3. 3. agenda <ul><li>Protocol basics </li></ul><ul><li>History, standardisation </li></ul><ul><li>& current implementations </li></ul><ul><li>Extensible Messaging and Presence Protocol </li></ul><ul><li>Near future </li></ul><ul><li>Potential </li></ul><ul><li>Other protocols </li></ul><ul><li>Q&A </li></ul>
    4. 4. XML stream <ul><li><stream> </li></ul><ul><li><presence> </li></ul><ul><li><show/> </li></ul><ul><li></presence> </li></ul><ul><li><message to='foo'> </li></ul><ul><li><body/> </li></ul><ul><li></message> </li></ul><ul><li><iq to='bar'> </li></ul><ul><li><query/> </li></ul><ul><li></iq> </li></ul><ul><li>[ ... ] </li></ul><ul><li></stream> </li></ul>stanza
    5. 5. open stream <ul><li><?xml version='1.0'?> </li></ul><ul><li><stream:stream </li></ul><ul><li>from='juliet@example.com' </li></ul><ul><li>to='example.com' </li></ul><ul><li>version='1.0' </li></ul><ul><li>xml:lang='en' </li></ul><ul><li>xmlns='jabber:client' </li></ul><ul><li>xmlns:stream='http://etherx.jabber.org/streams'> </li></ul>Client initiates a stream to server Server response <?xml version='1.0'?> <stream:stream from='example.com' id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' to='juliet@example.com' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>
    6. 6. <ul><li>[…] </li></ul>
    7. 7. close stream <ul><li></stream:stream> </li></ul><ul><li></stream:stream> </li></ul>Either entity may close the stream Other entity will reply
    8. 8. <ul><li><presence/> </li></ul>initial presence I’m now available
    9. 9. presence <ul><li><presence> </li></ul><ul><li><show>away</show> </li></ul><ul><li></presence> </li></ul><ul><li><presence from='juliet@example.com/balcony' </li></ul><ul><li>to='romeo@example.net'> </li></ul><ul><li><show>away</show> </li></ul><ul><li></presence> </li></ul>Client updates presence to away Contact receives the update
    10. 10. iq:roster <ul><li><iq from='juliet@example.com/balcony' </li></ul><ul><li>type='get‘ </li></ul><ul><li>id='roster_1'> </li></ul><ul><li><query xmlns='jabber:iq:roster'/> </li></ul><ul><li></iq> </li></ul>Client queries for roster Server returns user’s roster <iq to='juliet@example.com/balcony‘ type='result' id='roster_1'> <query xmlns='jabber:iq:roster'> <item jid='romeo@example.net‘ name='Romeo' subscription='both'> <group>Friends</group> </item> <item jid='mercutio@example.org' name='Mercutio' subscription='from'/> </query> </iq>
    11. 11. <ul><li><message </li></ul><ul><li>from='juliet@example.com/balcony' </li></ul><ul><li>to='romeo@example.net' </li></ul><ul><li>type='chat' </li></ul><ul><li>xml:lang='en'> </li></ul><ul><li><body>How do you do ?</body> </li></ul><ul><li></message> </li></ul>
    12. 12. 9
    13. 14. not just presence & IM <ul><ul><li>“” There are mission-critical XMPP deployments at most Wall Street banks, numerous major corporations, high-profile agencies of the U.S. federal government , and countless universities and small businesses worldwide. And the percentage of those organizations participating in the process of standardizing XMPP extensions continues to grow significantly, including contributions regarding voice and video integration from Google and on real-time language translation from the U.S. Department of Defense . “” </li></ul></ul><ul><ul><li>Peter Saint-Andre, January 2007 </li></ul></ul>
    14. 16. session vs. session initiation
    15. 17. extensibility – scalability <ul><li>Protocol </li></ul><ul><li>XMPP Extension Protocols (XEPs): </li></ul><ul><li>publish-subscribe, multi-user chat, chat rooms, multimedia sessions (Jingle), link-local messaging, … </li></ul><ul><li>Services </li></ul><ul><li>Server components </li></ul><ul><li>Service discovery </li></ul><ul><li>Servers </li></ul><ul><li>Clustering a common solution but not part of XMPP </li></ul><ul><li>Server components help as well </li></ul>
    16. 18. near future potential IETF meetings real-time protocol for Internet
    17. 19. potential in mobile / Internet XMPP is a protocol that can deliver what Dean Bubley descriped in his 2008 prediction (1 st slide) Contextual data fits well with Publish-Subscribe Android, mobile platform, has XMPP support Any kind of messages between devices Part of Google APIs and services (fixed to Google)
    18. 20. enablers <ul><li>Open, standard protocol </li></ul><ul><li>Code libraries for your favorite language </li></ul><ul><li>Open source projects </li></ul><ul><li>Clients </li></ul><ul><li>Servers </li></ul><ul><li>Server components </li></ul><ul><li>Code libraries </li></ul><ul><li>Security </li></ul><ul><li>TLS, SASL, SPIM prevention, TCP stream, etc. </li></ul>
    19. 21. other protocols <ul><li>SIP/SIMPLE </li></ul><ul><li>Voice drives SIP development </li></ul><ul><li>Implementation getting difficult due to enormous number of specifications </li></ul><ul><li>Bandwidth inefficient </li></ul><ul><li>NATs and firewall troubles (UDP, message based) </li></ul><ul><li>Proxy functionality (does not exist in XMPP) </li></ul><ul><li>Proprietary protocols </li></ul><ul><li>Fast development for specific needs </li></ul><ul><li>Need gateways to interconnect </li></ul><ul><li>One initial idea behind XMPP was to offer transparent comunication to other IM systems </li></ul>
    20. 22. conclusions <ul><li>Open and standard protocol </li></ul><ul><li>Strong commitment to interoperability </li></ul><ul><li>Implementations drive standardisation </li></ul><ul><li>A lot of available extensions while easy to extend as needed </li></ul><ul><li>One client – server XML stream </li></ul><ul><li>TCP; http bindings available </li></ul><ul><li>Transfer any smallish content over IP </li></ul><ul><li> in real-time using XMPP </li></ul>
    21. 23. <ul><li>Questions & Answers </li></ul><ul><li>? </li></ul>