Re: [sixpac] Capability and preference expression and interrogation

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 10 March 2011 15:28 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 D57BE3A69DF for <sixpac@core3.amsl.com>; Thu, 10 Mar 2011 07:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.481
X-Spam-Level:
X-Spam-Status: No, score=-4.481 tagged_above=-999 required=5 tests=[AWL=1.818, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3]
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 twSBBWhAbZvI for <sixpac@core3.amsl.com>; Thu, 10 Mar 2011 07:28:18 -0800 (PST)
Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 036813A69E2 for <sixpac@ietf.org>; Thu, 10 Mar 2011 07:28:10 -0800 (PST)
Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for <sixpac@ietf.org>; Thu, 10 Mar 2011 16:29:20 +0100 (CET)
Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 3958B3A17F; Thu, 10 Mar 2011 16:29:20 +0100 (CET)
Message-ID: <4D78EE55.3060900@omnitor.se>
Date: Thu, 10 Mar 2011 16:29:25 +0100
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Simo.Veikkolainen@nokia.com
References: <4D748C04.9090509@omnitor.se> <C99A3207.4C4F3%joe.hildebrand@webex.com> <F9E2FDAF48D4544F874A56A3A8BD68B1010AE731@008-AM1MPN1-002.mgdnok.nokia.com>
In-Reply-To: <F9E2FDAF48D4544F874A56A3A8BD68B1010AE731@008-AM1MPN1-002.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: joe.hildebrand@webex.com, sixpac@ietf.org
Subject: Re: [sixpac] Capability and preference expression and interrogation
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: Thu, 10 Mar 2011 15:28:22 -0000

Hi Simo,
Yes, it is good to check if there seems to be suitable mechanisms for 
implementing the requirements before we settle the requirements.

One requirement was to be able to check the capabilities by the caller 
preferences callee capabilities functions in
RFC 3840, RFC 3841 etc.

I think that is implementable by on the combined SIP ua/XMPP client to  
use SIP Media Feature Tags to reflect its XMPP client's capabilities. 
There may be a need to register new SIP Media Feature Tags for this 
requirement.

The other requirement was to be able to check for details of the 
capabilities once a basic capability is discovered. For that, I think it 
may be suitable to use XEP-115 or XMPP presence info.


The result should be that both requirements can be included in the

sip-xmpp-coex-reqs with no risk for complex work to invent solutions.

Gunnar

___________________________________________________
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288


Simo.Veikkolainen@nokia.com skrev 2011-03-10 12:28:
> Hi,
> I'm now updating the sip-xmpp-coex-reqs draft.
>
> Gunnar, regarding your proposal, do you think it would not be sufficient to use XEP-115 (for detailed capabilities) or just XMPP presence for finding out the capabilities of the other endpoint?
>
> Simo
>
>> -----Original Message-----
>> From: sixpac-bounces@ietf.org [mailto:sixpac-bounces@ietf.org] On
>> Behalf Of ext Joe Hildebrand
>> Sent: 07 March, 2011 15:56
>> To: Gunnar Hellström; sixpac@ietf.org
>> Subject: Re: [sixpac] Capability and preference expression and
>> interrogation
>>
>> In XMPP, this sort of thing is done with XEP-115
>> (http://xmpp.org/extensions/xep-0115.html).  It's end-to-end, and is
>> borne
>> as a part of the presence of a device.  115 usually takes folks a while
>> to
>> get used to, so please set aside the time to do more than skim.
>>
>>
>> On 3/7/11 12:40 AM, "Gunnar Hellström"<gunnar.hellstrom@omnitor.se>
>> wrote:
>>
>>> The requirement to express the capability of XMPP messaging in SIP
>> described
>>> below also may need  an extension for declaration of
>> capability
>>> details.
>> REQ-y: Negotiable features  in XMPP must be possible to express and
>> interrogate at SIP Session establishment level.
>>
>> Use case:  Alice want to
>>> send a nice HTML-formatted invitation letter to
>> Bob. She wonders if she can
>>> do it in a SIP session with messaging
>> enabled. Therefore, when she calls Bob,
>>> she indicates a desire to use
>> Rich formatted messages. The resonse shows that
>>> Bob has no capability
>> for such features, so Alice decides to send an e-mail
>>> instead and
>> discuss it in a plain vice phone
>>> call.
>> Gunnar
>>
>> -------------------------------------
>>
>> Gunnar Hellström skrev
>>> 2011-02-08 20:16:
>>> I think it is important that the capability to do XMPP
>>> messaging with
>>> a SIP endpoint is expressed in regular SIP ways, so that
>>> capability
>>> checking for that function even can be done before a session is
>>>
>>> initiated, and also during session initiation. E.g. the functionality
>>>
>>> should have the possibility to influence the outcome of caller
>>> preferences
>>> - callee capabilities interrogations (RFC 3840, RFC 3841 ).
>>>
>>> It seems to me
>>> that that is easily achieved, but that is not the issue
>>> at the moment, when
>>> collecting requirements.
>>> I cannot find exactly that need described in the
>>> current requirements,
>>> so I suggest to add a requirement like this:
>>>
>>>
>>> REQ-x: The capability or preference to initiate and accept XMPP
>>> messages
>>> must be possible to express and interrogate by the standard
>>> mechanisms for
>>> such functions in SIP for caller preferences and callee
>>> capabilities. ( RFC
>>> 3840, RFC 3841 etc.)
>>>
>>> Use case: Alice want to call Bob to have his view of
>>> some new poems
>>> she has written. She has a SIP phone with XMPP chat
>>> addition. She
>>> makes sure that her phone expresses a preference for audio
>>> and text
>>> messaging in the call. Bob has two phones registered on his
>>> address.
>>> One only with audio functionality, the other with both audio and
>>> text
>>> messaging. The SIP server can match the Alice's preferences with the
>>>
>>> capabilities of Bob's phones, and direct the call to the device where
>>> he
>>> can receive and read the poems and comment them in their voice
>>>
>>> conversation.
>>>
>>> ---
>>>
>>> I am not sure if similar standardised features are
>>> available for XMPP
>>> so that it is relevant to express the symmetric
>>> requirements on the
>>> XMPP side.
>>>
>>> Gunnar
>>>
>>>
>>>
>> _______________________________________________________________________
>> _______
>>> --
>>>
>>> Simo.Veikkolainen@nokia.com skrev 2011-01-26 21:20:
>>>> You're right,
>>> we should get some discussion going on.
>>>> I have just uploaded a new
>>> version of
>>>> draft-veikkolainen-sip-xmpp-coex-reqs, which can be found at
>>> http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmpp-coex-
>> reqs-02.t
>>> xt
>>>> The changes in this version address the comments made by Peter
>>>>
>>> Musgrave (mainly clarifications):
>>>> In REQ-1: ³SIP contact² changed to
>>> ³SIP address²
>>>> In REQ-3: "It must be possible to include SIP real-time
>>> media related
>>>> contact and status in XMPP presence information." changed to
>>> "It must
>>>> be possible to include SIP address and status information in XMPP
>>>> presence."
>>>>
>>>> And a couple of typos.
>>>>
>>>> One further comment made by
>>> Peter might merit a bit more discussion,
>>>> namely saying something about
>>> cases where two SIP devices are
>>>> registered to the same AOR and two XMPP
>>> clients are logged in. This
>>>> is related to the discussion we had an
>>> correlation, and whether or
>>>> not it should be mentioned in the charter or
>>> not.
>>>> Opinions on this would be helpful.
>>>>
>>>> Also, please take a fresh
>>> look at the draft and express your opinions
>>>> on whether the approach in
>>> general makes sense, do you agree with the
>>>> use cases and requirements, is
>>> something missing etc.
>>>> Thanks
>>>> Simo
>>>>
>>>>
>>>> -----Original
>>> Message-----
>>>> From: ext IETF I-D Submission Tool
>>> [mailto:idsubmission@ietf.org]
>>>> Sent: 26 January, 2011 22:05
>>>> To:
>>> Veikkolainen Simo (Nokia-MS/Helsinki)
>>>> Cc: Isomaki Markus
>>> (Nokia-CIC/Espoo)
>>>> Subject: New Version Notification for
>>>>
>>> draft-veikkolainen-sip-xmpp-coex-reqs-02
>>>>
>>>> A new version of I-D,
>>> draft-veikkolainen-sip-xmpp-coex-reqs-02.txt
>>>> has been successfully
>>> submitted by Simo Veikkolainen and posted to
>>>> the IETF repository.
>>>>
>>>>
>>> Filename:     draft-veikkolainen-sip-xmpp-coex-reqs
>>>> Revision:     02
>>>>
>>> Title:         Requirements and Use Cases for Combining SIP Based
>>> Real-time Media Sessions With XMPP Based Instant Messaging and
>>>> Presence
>>> Service.
>>>> Creation_date:     2011-01-26
>>>> WG ID:         Independent
>>> Submission
>>>> Number_of_pages: 8
>>>>
>>>> Abstract:
>>>> This memo defines use
>>> cases and requirements for combining Session
>>>> Initiation Protocol (SIP)
>>> based real-time media sessions with
>>>> Extensible Messaging and Presence
>>> Protocol (XMPP) based instant
>>>> messaging and presence services in a seamless
>>> manner.
>>>>
>>>>
>>>> The IETF Secretariat.
>>>>
>>>>
>>>>
>>> _______________________________________________
>>>> 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
>>
>>
>> --
>> Joe Hildebrand
>>
>> _______________________________________________
>> sixpac mailing list
>> sixpac@ietf.org
>> https://www.ietf.org/mailman/listinfo/sixpac