Re: [sixpac] Capability and preference expression and interrogation

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 11 March 2011 09:18 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 9FBEC3A687E for <sixpac@core3.amsl.com>; Fri, 11 Mar 2011 01:18:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.607
X-Spam-Level:
X-Spam-Status: No, score=-4.607 tagged_above=-999 required=5 tests=[AWL=1.692, 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 lqSxRFY3KVYc for <sixpac@core3.amsl.com>; Fri, 11 Mar 2011 01:18:26 -0800 (PST)
Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 437573A686A for <sixpac@ietf.org>; Fri, 11 Mar 2011 01:18:24 -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>; Fri, 11 Mar 2011 10:19:35 +0100 (CET)
Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id D4D5E3A225; Fri, 11 Mar 2011 10:19:34 +0100 (CET)
Message-ID: <4D79E927.40600@omnitor.se>
Date: Fri, 11 Mar 2011 10:19:35 +0100
From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= <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> <4D78EE55.3060900@omnitor.se> <F9E2FDAF48D4544F874A56A3A8BD68B1010AF1CD@008-AM1MPN1-002.mgdnok.nokia.com>
In-Reply-To: <F9E2FDAF48D4544F874A56A3A8BD68B1010AF1CD@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: Fri, 11 Mar 2011 09:18:27 -0000

The caller preferences - callee capabilities decisions can be automated 
in the sip server or the ua.

I think it is important to maintain such well structured functionality 
on the routing and negotiation level even when new ways to transport 
call contents are introduced.

Gunnar

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


Simo.Veikkolainen@nokia.com skrev 2011-03-11 08:23:
>
>> -----Original Message-----
>> From: ext Gunnar Hellström [mailto:gunnar.hellstrom@omnitor.se]
>> Sent: 10 March, 2011 17:29
>> To: Veikkolainen Simo (Nokia-MS/Helsinki)
>> Cc: joe.hildebrand@webex.com; sixpac@ietf.org
>> Subject: Re: [sixpac] Capability and preference expression and
>> interrogation
>>
>> 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.
> I was mainly wondering could a dual-stack SIP/XMPP client learn the same capabilities just using XMPP presence or XEP-115, as opposed to using SIP caller prefs. In other words, what is the reasoning for using SIP for this purpose? ( I have copied your proposed REQ below.)
>
> ---
> 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.)
> ---
>
> Regards,
> Simo
>
>> 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