Open AIM 2.0

I was a big fan of AOL chat while in 1999 time, later i don't know why , i left.

Some days before, found an interesting article on AOL's new Open AIM .

read more on http://dev.aol.com/aim.

AOL published its protocol and inviting developers.

Now my question is where all a developer need to concentrate - XMPP, SIMPLE, AIM or some more as they get published.

A simple 2.0 dilemma :-)

© yankandpaste®

A Hitchhikers Guide on Jingle

Abstract

The Jingle is subject of numerous specifications produced by XSF. It can be difficult to locate the set of documents or lot of documents where the big picture lies in a different group.This document serves as a guide to the jingle series. It lists the specifications under Jingle umbrella, briefly summarizes and groups into categories.



Table of Contents

1. Introduction 
2. Scope of this Document 
3. Jingle Session management Specifications
3.1 Overall session management 
      Jingle
      XMPP Core
3.2 Content formats
      Jingle Audio
      Jingle Video
      Jingle File Transfer
3.3 Transport formats
      Raw UDP
      ICE
3.4 General Support specifications
      Resource Application Priority 
      Service Discovery
      External service Discovery
      Jingle DTMF
3.5 Other documents
      Bootstrapping Implementation of Jingle

4. Interworking

5. Security Mechanisms 

1.0 Introduction

The Jingle is subject to numerous specifications produced by XSF. It is tough to get the big picture of the related technologies and relevance with jingle as the different technologies spread across different standard bodies. By giving emphasis on the big picture, this document tries to give the big picture and helps to identify the areas and importance.


2.0 Scope of this Document:


This document does not update jingle or related specifications. This is an informational document meant to guide newcomers, implementers and deployers to the Jingle suite of specifications.


3.0 Jingle Session management Specifications

Jingle consists of three parts, each with its own syntax, semantics, and state machine

         Overall session management 
         Content description formats (the "what") 
         Content transport methods (the "how")

3.1 Overall session management

The Overall session management represents the group of specifications that defines the core session generation,maintenance and tear down.

Jingle Core

This document defines a framework for initiating and managing peer-to-peer multimedia sessions (e.g., voice and video chat) between two Jabber/XMPP endpoints in a way that is interoperable with existing Internet standards.

Jingle is defined in XSF XEP 0166 http://www.xmpp.org/extensions/xep-0166.html


Extensible Messaging and Presence Protocol (XMPP): Core

This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.

Extensible Messaging and Presence Protocol (XMPP): Core is defined in IETF RFC 3920 ( http://www.faqs.org/rfcs/rfc3920.html )


Content description formats


Jingle Audio

This document defines methods for negotiating Jingle audio sessions that use the Real-time Transport Protocol (RTP) for media exchange.

Jingle Audio is defined in XSF XEP 0167 http://www.xmpp.org/extensions/xep-0167.html


Jingle Video

This document defines methods for negotiating Jingle video sessions that use the Real-time Transport Protocol (RTP) for media exchange.

Jingle Video is defined in XSF XEP 0180 http://www.xmpp.org/extensions/xep-0180.html

Jingle File Transfer

This document defines methods for negotiating Jingle file transfer sessions that use the Real-time Transport Protocol (RTP) for media exchange.

Jingle File transfer is defined in an expired draft in XSF http://www.xmpp.org/extensions/inbox/jingle-ft.html

This is a not an approved standard.

Transport description formats

Raw UDP

This document defines a Jingle transport method that results in sending data over a raw User Datagram Protocol (UDP) connection.

Jingle Raw UDP Transport is defined in http://www.xmpp.org/extensions/xep-0177.html


ICE

This document defines a Jingle transport method that results in sending data between two entities using the Interactive Connectivity Establishment (ICE) methodology.

Jingle Ice transport is defined in http://www.xmpp.org/extensions/xep-0176.html


General Support specifications


Resource Application Priority

This document defines an XMPP protocol extension to indicate the presence priority of XMPP resources for applications other than messaging.

Resource Application Priority is defined in http://www.xmpp.org/extensions/xep-0168.html


Service Discovery
This document defines an XMPP protocol extension for discovering (1) information about Jabber entities and (2) the items associated with such entities.


Service discovery is defined in http://www.xmpp.org/extensions/xep-0030.html


External service discovery

This document specifies an XMPP protocol extension for discovering services external to the XMPP network.

External Service discovery is defined in http://www.xmpp.org/extensions/xep-0215.html

Jingle DTMF

This document specifies an XML format for encapsulating DTMF data in informational messages sent within the context of Jingle audio interactions.

jingle DTMF is specified in http://www.xmpp.org/extensions/xep-0181.html

Other support Documents

Bootstrapping Implementation of Jingle

This document provides guidelines to client and library developers for bootstrapping implementation of the encrypted sessions technology.

Bootstrapping Implementation of Jingle is defined in http://www.xmpp.org/extensions/xep-0208.html

4. Interworking
In progress, A draft is in progress for interworking with SIP.

5. Security Mechanisms

Currently jingle supports secure transport as specified in RTP Over DTLS via a profile of "UDP/TLS/RTP/AVP".


DTLS extensions for SDP is defined in XSF http://tools.ietf.org/html/draft-fischl-mmusic-sdp-dtls-03

gOOgle phOne

talks on google phone :-), says a five facts

The operating system will be a "mobile variant of Linux" capable of running Java Virtual Machines.

Second, all the on-board applications will be Java-based, including the music/video player.

Third, the user interface is based in Java, is "very responsive", features a "search box", and will be "typical of mobile phones."

Fourth, the web browser -- also in Java -- will have pan and browse.

Lastly, there was initially one prototype, but since then the mobile OS has been seen running on between 3 and 5 devices, all of which rock the QWERTY.


Our view : google phone will be a mobile device capable of surfing internet (may be WIFI or WIMAX or 1X or EVDO or GPRS ( we dont expect GPRS because of low speed).
It will not be the normal mobile phone and will be running a linux OS and capable of running all the google app including gmail, search, talk ( expect call out and callin from googletalk with a dial pad ).google apps, maps youtube videos and all other google applications. The main focus will be adv displays with content.

It's time of voip and web to common man, every body needs it.

© yankandpaste®

mundu - The garment IM

The mundu is a garment worn around the waist in Kerala and Maldives related to the Dhoti as well as the Lungi. In South Canara district of Karnataka state the Tulu speaking folk and Beary community do use mundu. It is normally woven in cotton and coloured white or cream. The colour is dependent on whether the cotton is bleached or unbleached. Kaddar mundu is another kind which is made using handlooms. When unbleached the mundu is called a neriyathu. In modern times, two types of mundu are prevalent - the single and the double. A single mundu is draped once around the waist, while the double is folded in half before draping. A mundu is usually starched before use.


http://www.mundu.com/ talks about an IM product which claims: A comphrehensive Instant Messaging platform to help you build, grow and monetize your user community.


Another web 2.0 company playing with multi messaging ( i am not sure whetehr there 'll be a day when i can have one account and talk to different servers).The sadest part is i was not able to find even a single reference to any standards in the site. so i assume it as another propratory IM.

Unfortunatley the http://www.mundu.com/platform/platformfeatures.php?top=3&leftIndex=3 link gave more than enough confusion. Just put some blocks and say its a platform features without any explantion

any way i think the wed designers managed to push a lot of open standard words in the platform features as features (looks the person who made the picture never know what he was drawing ).It more resembled me a preson who dont know english draws "To let" as "Toilet".I tried to download but looks slow , so i left it as it is :-)

© yankandpaste®

All new True life IMS

Got the link from a friend http://www.truelife.com/quicktour.html

Yep another IM service, Not at all conventioanl looks,

looks good in the link,
Chat, Call, TV , Radio, Music sharing, Blogs , Content reading--- man its all in one.

Didn't get a chance to download the software and try:
Some body informed me that its a sip-XMPP hybrid model.

The main page ( www.truelife.com ) says they have 296,761 users


May be world's biggest sip-XMPP hybrid service :-)
© yankandpaste®

Meebo - last year's most grown IM

Was reading research report : meebo is the last year's most grown network ( i am not sure how correct it is as PR can make research reports ).

The first thing i did was going to www.meebo.com ,

Nice Gui, allowing me to login to a lot IM services without any registration to meebo and no software to install ( the all AJAX game )

My comments :=============
Impressed ? yep a bit, not on the technology, on the GUI

Why not on technology ? Because i one time worked on a gaim kind of project and we took all the reverse engineered libs and made applications except for googletalk ( google talk is XMPP ). So if we make a full application with the reverse eng: libs we dont have any control and its a pain in the neck when feature changes.

How to realize it with open software ?=======================================WOW you can do that.

Install ejabberd server ( http://ejabberd.jabber.ru/ ), take compnents from http://www.jabber.org/software/components.shtml

Install the required Gateway components and run.

Install http://jwchat.sourceforge.net/ and configure for ejabberd. Look http://ejabberd.jabber.ru/node/11 for details.

WOW with some installations and configs, your multi IM service is UP and running.

Now Job begins : GUI changes and customizations.
thatz a big job and meebo has done a very decent work on it. Way to go !!

© yankandpaste®

Embrace, extend, and exterminate

Do you think "Embrace, extend, and exterminate" is microsoft specific ??

Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.

Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to remain neutral.

Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support Microsoft's extensions and create an obstacle to new competitors.

Interesting to find a document which describes the Voice mail call flow used by google talk.

http://www.scribd.com/doc/123347/Google-Talk-Voice-Mail-Call-flow

Looks this document is googletalk reverse eng:.As you know the libjingle protocol and Jingle are very similar, they are not the same, and are not interoperable.

tailpiece: corporate always carry their ego, and keen in their interests.They are not interoperable with public standards.

© yankandpaste®

Real world Multimedia with Jingle

What ?

What is Realworld needs Multimedia with Jingle means ?

Developing real world needs ( phone, fax, whiteboard , video etc etc ) application using jingle.

What is Jingle ?

'Jingle' is a set of extensions to XMPP for use in VoIP, video, and other peer-to-peer multimedia sessions.

What is XMPP ?

Extensible Messaging and Presence Protocol (XMPP) is an open, XML-based protocol for near-real-time, extensible instant messaging (IM) and presence information (aka buddy lists). It is the core protocol of the Jabber Instant Messaging and Presence technology. The protocol is built to be extensible and other features such as Voice over IP and file transfers have been added

What is XML ?

The Extensible Markup Language (XML) is a general-purpose markup language. Its primary purpose is to facilitate the sharing of data across different information systems, particularly via the Internet

When ?

When i have the know how ?
Now itself.


why ?

Why Jingle ?

XMPP has an all ready big, developed network which a lot ISP's provide jabber services for the clients. As voip is replacing the traditional PSTN.The options in front of the ISP's are
1) Use SIP
2) Use MGCP
3) Use H323

Or use an approch using XMPP Jingle ( low cost, low complexity )


Who makes these standards :
XMPP : www.jabber.org

How ?

Using Jingle you can write applications which helps the real world needs, The jingle is the core protocol which defines the session and the other content and trasport format definitons help to build application.

Content /Transport formats ?
Jingle Audio - for audio content format definition
Jingle Video- for video content format definition
Jingle UDP transport - transport using UDP
Jingle ICE transport - transport using ICE ( ICE - look previous post on ICE )
Jingle DTMF - a DTMF trasport using Jingle.

these format specifications uses XML mapped SDP for describing the session.

The problem with these definitions are
1) its only a subset of actual SDP.
2) These documents never gives the big picture as the RFC's descrbing the actual SDP and feature/extension definition( ex: ICE ).
3) Lot limitations as of now ( long way to go to become a full fledged telephony supoort ) (ex: early media , cancel a call ).


Options now ?

http://www.scribd.com/doc/95534/Jingle-Multimedia-Description-Using-SDP

Use SDP for session description and jingle for session initation.

Advantages :

1) SDP is an IETF protocol ( Open ).
2) SDP is well used by other protocols ( SIP, MGCP, RTSP etc etc ).This makes easy interoperability.
4) Avoiding duplicate information documents (copy paste of actual RFCs ) ex: ICE
5) Bringing in standard procedures for development ( ex: offer answer model ( rfc3264 rfc4317 ) ,PINT services (rfc2848), IPV6 rfc3266), Grouping of Media Lines ( rfc3388 ),Content Attribute (rfc4796), )
6) No IPR issues on usage of SDP because it is tracked by IETF.
7) New technologies have SDP extension ( ex: ICE-TCP, ICE etc etc ). Due to this addition of new standard applications
8) Already well written/matured documents for help on deployment and proved to best + good knowledge base.


Looks this is what the industry was looking for -

No more buzz words like sip trunking etc , XMPP has a server to server comminication defined and multimedia for all Jabber users using the Industry adapted applications using well defined SDP.


Where ?

Where i can find details ?

XMPP : RFC 3920
XMPP IM : RFC 3920

Jingle : XEP-0166
Jingle Audio : XEP-0167
Jingel Video : XEP-0180
Jingle DTMF : XEP-0181

Jingle UDP transport :XEP-0177
Jingle ICe transport :XEP-0176

The xeps can be found at :http://www.xmpp.org/extensions/
Jingle SDP content description: http://www.scribd.com/doc/95534/Jingle-Multimedia-Description-Using-SDP




© yankandpaste®

Interactive Connectivity Establishment (ICE): Tutorial

Thanks for the Overwhelming responses for the ICE post, most asking for a good ICE tutorial. The link goes below

http://www.jdrosen.net/papers/ice-basic-tutorial.pdf

© yankandpaste® :

The Many Faces of Interactive Connectivity Establishment (ICE)

By J.D. Rosenberg



Without a doubt, one of the most challenging issues that VoIP system designers and network operators face is firewall and Network Address Translator (NAT) traversal. These days, almost every home with broadband Internet access has a NAT device — after all, NAT is the primary function of the broadband home router, the little magic that allows you to connect multiple computers to a single Internet connection. Most enterprises have one or more firewalls, and many smaller ones run NAT as well. Even some service providers use NAT; it is not uncommon for a cellular phone to have a private IP address. While NAT and firewalls are not a problem for traditional client-server protocols like those used for the web and e-mail, they are a huge problem for VoIP.

The industry has responded to this problem with many different solutions. These include Application Layer Gateways (ALGs), which add SIP awareness to NAT and firewalls, Simple Traversal of UDP Through NAT (STUN), which uses a “ping server” of sorts to allow low-cost traversal in consumer applications, and Session Border Controllers (SBCs), a close cousin to ALGs. SBCs have won the largest part of the market share of NAT and firewall traversal solutions. All of these techniques have their problems, and so the IETF worked steadily on producing a one-size-fits-all solution. That solution is called ICE: Interactive Connectivity Establishment.

ICE is a peer-to-peer cooperative NAT traversal solution, in which endpoints work with each other to discover paths through the network via a series of connectivity checks. This discovery is done in concert with network servers that help provide relaying and address translation functions. Work on ICE began in early 2003, and finally, a long four years later, it is now complete. ICE is extremely effective. It is robust, finding media paths even in the most complex network topologies. ICE makes sure that the called phone won’t ring unless a bidirectional media path is up and running. No more ghost rings and oneway audio that are common problems in VoIP. ICE is efficient, using relays and suboptimal paths only when absolutely necessary. It works across a broad range of environments without changes in configuration. It also provides lots of hooks for policy and allows for an evolutionary path from existing SBCs to ICE-based SBCs.


However, an interesting thing has begun to happen. ICE is also solving problems having little or nothing to do with firewall and NAT traversal. These include security, IPv6 transition, and dual-homing.

What does ICE have to do with security? Many VoIP systems today allow a malicious client to use the VoIP network to launch a denial-of-service (DoS) attack against a desired target. This attack, called the voice hammer, allows a single callsetup message to direct an 80 Kbps stream of packets (and possibly higher bandwidths) at a target device. This attack is easy to launch: An attacker sends a SIP INVITE message but lies about its media address, pointing to the target of the attack instead. Once the call is established, the called party will begin sending media toward the target. ICE prevents this attack. The called party won’t send any media at all until the ICE connectivity checks have taken place. Those checks happen along the media path, and in this case, they will fail since the target of the attack won’t respond to the checks. Consequently, no media is ever sent and the attack is prevented.

What does ICE have to do with IPv6 transition? One of the primary transition techniques is to use a dual-stack client, one that has both an IPv4 address and an IPv6 address. This introduces an interesting problem: When the dual-stack client makes a call, which address does it include in its INVITE as the target for media, IPv4 or IPv6? At the time it makes the call, it doesn’t know the capabilities of the called party, which could be IPv4 only, IPv6 only or dual stack. ICE has emerged as the solution to this problem. The caller includes both addresses, uses ICE’s connectivity checks to figure out which pairs work, and then uses them.

More generally, ICE helps dual-homed endpoints — those with more than one IP address. They are more common than you might think. My laptop has three IP addresses — one on the Wi-Fi network, one on the wired Ethernet, and one on my VPN. When I make a call from my softphone, which one should my laptop use? With ICE, my softphone would include all three, and then ICE would be used to dynamically figure out which one works. In fact, ICE can help me pick the one with the lowest latency, in order to optimize my experience in the call. ICE can also have configured policies to ensure only a specific address (such as my VPN), gets used.

These three applications are just the beginning. ICE can address other problems because it adds an important piece of functionality to SIP — exchange of messaging that follows the media path prior to call establishment and prior to the transmission of media. This small but important change will, I predict, make ICE a protocol for all seasons, not just the winter of NAT and firewall traversal. ICE is already considered one of the core SIP specifications by the IETF, and I anticipate we’ll see more and more reasons for this over time.


© yankandpaste® from : http://www.tmcnet.com/sip/0507/columns_speaking_sip_the_many_faces_of_ice.htm

a 3GPP IMS Blog

looks interesting :

http://theimslantern.blogspot.com/

I am still looking what to yankandpaste from here, some times its better to readfromthesource also.

yankandpaste from : http://www.tech-invite.com/Ti-sip-service-6.html

Vonage Case

It's not hot any more, but did you ever thought what was the claims and what was the patents.

now a days patents looks some form of evil which stops creativity( creativity is defined as "making workarounds" so that ppl can reinvent wheels than using them.

Here goes the list of patents vonage infringled and an analysis

6,104,711
6,359,880
6,282,574

A Detailed analysis :

http://blogs.zdnet.com/ip-telephony/?p=1517

yankandpaste from : hey man, i am also making workarounds , I am creative :-))