Re: [sixpac] charter proposal - correlation between SIP and XMPP

<Simo.Veikkolainen@nokia.com> Mon, 13 December 2010 08:05 UTC

Return-Path: <Simo.Veikkolainen@nokia.com>
X-Original-To: sixpac@core3.amsl.com
Delivered-To: sixpac@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41143A6CDE for <sixpac@core3.amsl.com>; Mon, 13 Dec 2010 00:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.266
X-Spam-Level:
X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPRXJfPOhXfY for <sixpac@core3.amsl.com>; Mon, 13 Dec 2010 00:05:15 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 2EBC83A6900 for <sixpac@ietf.org>; Mon, 13 Dec 2010 00:05:15 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBD86oV2030296; Mon, 13 Dec 2010 10:06:51 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Dec 2010 10:06:39 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Dec 2010 10:06:39 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 13 Dec 2010 09:06:39 +0100
From: Simo.Veikkolainen@nokia.com
To: peter.musgrave@magorcorp.com, rjsparks@nostrum.com
Date: Mon, 13 Dec 2010 09:06:37 +0100
Thread-Topic: [sixpac] charter proposal - correlation between SIP and XMPP
Thread-Index: AcuVnwEOWIVNIQLpTbyFVTcvMfIc2QE+2rug
Message-ID: <B23B311878A0B4438F5F09F47E01AAE051397A5353@NOK-EUMSG-01.mgdnok.nokia.com>
References: <4CDB9E64.6070704@stpeter.im> <B3F72E5548B10A4A8E6F4795430F841840CEE9EC2F@NOK-EUMSG-02.mgdnok.nokia.com> <B2BBC4E3-F851-4190-AD33-6366E27ECE50@nostrum.com> <6E942205-7EDC-47CF-81C5-D8AFD163C0E8@magorcorp.com>
In-Reply-To: <6E942205-7EDC-47CF-81C5-D8AFD163C0E8@magorcorp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Dec 2010 08:06:39.0342 (UTC) FILETIME=[AB8580E0:01CB9A9C]
X-Nokia-AV: Clean
Cc: sixpac@ietf.org
Subject: Re: [sixpac] charter proposal - correlation between SIP and XMPP
X-BeenThere: sixpac@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." <sixpac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sixpac>
List-Post: <mailto:sixpac@ietf.org>
List-Help: <mailto:sixpac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Dec 2010 08:05:17 -0000

-----Original Message-----
From: sixpac-bounces@ietf.org [mailto:sixpac-bounces@ietf.org] On Behalf Of ext Peter Musgrave
Sent: 07 December, 2010 01:40
To: Robert Sparks
Cc: sixpac@ietf.org
Subject: Re: [sixpac] charter proposal - correlation between SIP and XMPP

Hi all,

I have returned to http://tools.ietf.org/html/draft-veikkolainen-sip-xmpp-coex-reqs-01 (now expired). 

[Simo] The -01 version expires Feb 23rd, 2011; maybe you took a look at the previous version? (But even that's ok since there are few changes only in -01.)

The use cases make sense to me. I think to make them crisper it would be useful to extend it to consider the cases where I have two SIP devices registered to the same AOR and two XMPP clients (one each on the same two devices) logged in. I think this encompasses the potential corner cases. 

[Simo] You mean a case when I have two dual-stack endpoints registered at the same time? I agree this might be something we want to say something on, since developers will be facing the issue anyway. The simplest way would probably be that everything works as they do currently: If the other party wants to extend the IM conversation we have with a SIP call, and he send a SIP INVITE to my AOR, all my registered UA instances ring. On the other hand, he might choose to send the SIP INVITE to my GRUU only, and in this case only a specific UA instance gets the call. And the same way around with SIP call extended with XMPP IM. Would that be enough, or do we want to build something more elaborate?

-Simo

If the charter decides to forgo session correlation then REQ-2 will need to reflect this (It speaks to XMPP carrying SIP session information). 

Other than that I think the identity correlation requirements it describes are useful. 

Regards, 

Peter Musgrave


On 2010-12-06, at 4:29 PM, Robert Sparks wrote:

> Discussion on this and the other threads appears to be stalling. Can we draw some conclusions?
> 
> For this thread, I think Markus was trying to soften (maybe remove?) this goal:
>>> - Correlating an XMPP IM session with a SIP voice/video session, and
>>> vice-versa
>> 
> 
> This is a place I think a group could get really stuck - as markus hints at below, how is this not going
> to run into the same set of issues (and run into the same set of problems trying to specify a solution for)
> that Hadriel's SIPSCOTCH proposal is having?
> 
> 
> RjS
> 
> 
> On Nov 11, 2010, at 11:06 AM, <Markus.Isomaki@nokia.com> <Markus.Isomaki@nokia.com> wrote:
> 
>> Hi,
>> 
>> The charter says:
>> 
>>> - There is no correlation between an XMPP IM session and a SIP voice
>>> or video session, thus preventing a dual-stack endpoint from providing
>>> integrated user interfaces and communications history
>> 
>> It has been pointed out that in SIP we may have practical challenges to achieve this with a high likelihood. This means that if our solution is based on some kind of token that is exchanged between the two SIXPAC clients over SIP (so that they can replay it later on over XMPP for correlation), and if we put that token in some kind of a new header, it is possible that B2BUA's on the path will "eat" such headers out. So as a practical consideration we have to think about what happens if that kind of exchange fails.
>> 
>> As a matter of fact, I don't think that such a correlation token is absolutely necessary for a good user experience. But we do need this:
>> 
>>> - Advertising a SIP account address over XMPP and an XMPP account
>>> address over SIP
>> 
>> I don't think there is a reason to change our charter at all because of this, but this is perhaps something that we could cover in the use cases and requirements document.
>> 
>> Markus
>> 
>> 
>>> -----Original Message-----
>>> From: sixpac-bounces@ietf.org [mailto:sixpac-bounces@ietf.org] On Behalf
>>> Of ext Peter Saint-Andre
>>> Sent: 11 November, 2010 09:42
>>> To: sixpac@ietf.org
>>> Subject: [sixpac] charter proposal
>>> 
>>> To kick off discussion, here is the charter as I sent it to the
>>> dispath@ietf.org list a while back, with removal of a clause about
>>> working on user configuration, which I think is a large rathole.
>>> 
>>> Let's discuss and get busy!
>>> 
>>> /psa
>>> 
>>> ========================================================================
>>> =
>>> SIXPAC (SIP Integration with XMPP in Presence Aware Clients)
>>> ========================================================================
>>> =
>>> 
>>> Problem Statement
>>> 
>>> Both the Session Initiation Protocol (SIP) and the Extensible Messaging
>>> and Presence Protocol (XMPP) are widely deployed technologies for real-
>>> time communication over the Internet.  In order to offer a complete
>>> suite of features as well as communication across multiple networks,
>>> several user-oriented software applications support both SIP and XMPP,
>>> and more software developers have expressed interest in building such
>>> "dual-stack" solutions.  Unfortunately, it is difficult to provide a
>>> good end-user experience in such applications because SIP and XMPP are
>>> not "aware" of each other.  For example:
>>> 
>>> - XMPP presence does not include availability states related to a SIP
>>> voice call or video call (e.g., "on the phone"), thus preventing an
>>> a dual-stack endpoint from showing presence-based communication hints
>>> 
>>> - There is no correlation between an XMPP IM session and a SIP voice
>>> or video session, thus preventing a dual-stack endpoint from providing
>>> integrated user interfaces and communications history
>>> 
>>> - SIP accounts and XMPP accounts are not directly correlated in contact
>>> lists or vCards (and not all deployed services support storage of such
>>> information), thus preventing a dual-stack endpoint from knowing that
>>> a contact has both SIP and XMPP capabilities
>>> 
>>> Although some proprietary solutions exist to the foregoing problems, it
>>> would be preferable to define standardized solutions for the sake of
>>> improved interoperability.
>>> 
>>> Objectives
>>> 
>>> Because both SIP and XMPP are easily extended through new SIP headers
>>> and XMPP elements, it should be possible to provide tighter integration
>>> within dual-stack SIP/XMPP user agents to improve the user experience.
>>> 
>>> Any such extensions should meet the following criteria:
>>> 
>>> - Be completely optional and backwards-compatible for all endpoints
>>> 
>>> - Work without changes to deployed infrastructure such as existing
>>> SIP and XMPP servers, B2BUAs, firewalls, etc.
>>> 
>>> The SIXPAC WG will define a small number of SIP and XMPP extensions to
>>> solve the following use cases in dual-stack endpoints:
>>> 
>>> - Including SIP-based availability states in XMPP presence (limited to
>>> basic presence and availability states only, not the full range of
>>> PIDF extensions)
>>> 
>>> - Correlating an XMPP IM session with a SIP voice/video session, and
>>> vice-versa
>>> 
>>> - Advertising a SIP account address over XMPP and an XMPP account
>>> address over SIP
>>> 
>>> Additional use cases are out of scope, including anything related to or
>>> requiring server integration, multiparty communication, SIP-based IM and
>>> presence, XMPP-based voice and video, file transfer, generalized service
>>> discovery and capabilities exchange, full protocol translation in
>>> communication gateways, shared credentials across both SIP and XMPP
>>> accounts, rich presence extensions for features such as geolocation,
>>> etc. Although such topics are important and interesting, they are out of
>>> scope for this group.
>>> 
>>> However, in addition to the protocol extensions explicitly mentioned
>>> above, the group may also define best practices related to the
>>> implementation and deployment of dual-stack SIP/XMPP endpoints.
>>> 
>>> Deliverables
>>> 
>>> - Use cases and protocol requirements
>>> 
>>> - XMPP presence extension for SIP-based availability states
>>> 
>>> - Media session correlation extensions for SIP and XMPP
>>> 
>>> - Contact address advertisement extensions for SIP and XMPP
>>> 
>>> - Best practices for implementation and deployment of dual-stack
>>> endpoints
>>> 
>>> Milestones
>>> 
>>> Feb 2011  Submit use cases and protocol requirements document to IESG
>>> (Informational)
>>> 
>>> Oct 2011  Submit XMPP presence extension document to IESG (Standards
>>> Track)
>>> 
>>> Oct 2011  Submit media session correlation extensions document to IESG
>>> (Standards Track)
>>> 
>>> Oct 2011  Submit contact address advertisement extension document to
>>> IESG (Standards Track)
>>> 
>>> Oct 2011  Submit best practices document to IESG (Informational)
>>> 
>> 
>> _______________________________________________
>> sixpac mailing list
>> sixpac@ietf.org
>> https://www.ietf.org/mailman/listinfo/sixpac
> 
> _______________________________________________
> sixpac mailing list
> sixpac@ietf.org
> https://www.ietf.org/mailman/listinfo/sixpac

_______________________________________________
sixpac mailing list
sixpac@ietf.org
https://www.ietf.org/mailman/listinfo/sixpac