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

Peter Musgrave <peter.musgrave@magorcorp.com> Mon, 13 December 2010 14:22 UTC

Return-Path: <peter.musgrave@magorcorp.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 C17A03A6E96 for <sixpac@core3.amsl.com>; Mon, 13 Dec 2010 06:22:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.643
X-Spam-Level:
X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 ELKBylmXNPX4 for <sixpac@core3.amsl.com>; Mon, 13 Dec 2010 06:22:21 -0800 (PST)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id E0CDD3A6D99 for <sixpac@ietf.org>; Mon, 13 Dec 2010 06:22:20 -0800 (PST)
Received: by gxk8 with SMTP id 8so3073086gxk.27 for <sixpac@ietf.org>; Mon, 13 Dec 2010 06:23:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.90.136.14 with SMTP id j14mr5135116agd.17.1292250238391; Mon, 13 Dec 2010 06:23:58 -0800 (PST)
Received: by 10.91.1.2 with HTTP; Mon, 13 Dec 2010 06:23:58 -0800 (PST)
In-Reply-To: <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> <B23B311878A0B4438F5F09F47E01AAE051397A5353@NOK-EUMSG-01.mgdnok.nokia.com>
Date: Mon, 13 Dec 2010 09:23:58 -0500
Message-ID: <AANLkTinp87XjhyAPrYgBiwJeKY3Vb=cB=hSJLwQuSMEf@mail.gmail.com>
From: Peter Musgrave <peter.musgrave@magorcorp.com>
To: Simo.Veikkolainen@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 14:22:21 -0000

> 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?

Hi,

Yes, the case you describe is one. The other would be one dual-stack
device and two other devices, one with a SIP reg and the other with an
XMPP reg.

I agree that the response could be to e.g ring the SIP device by AOR
or GRUU (and the converse would be send an IM to both clients).

I don't see a need for anything more than that - but I think thinking
about how what is prescribed works in this environment will be
helpful.

Peter Musgrave