Re: [sixpac] Capability and preference expression and interrogation

Gunnar Hellström <> Mon, 07 March 2011 07:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AC723A6928 for <>; Sun, 6 Mar 2011 23:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id giE8q9Wc3FJY for <>; Sun, 6 Mar 2011 23:39:47 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 919573A6920 for <>; Sun, 6 Mar 2011 23:39:45 -0800 (PST)
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP for <>; Mon, 7 Mar 2011 08:40:51 +0100 (CET)
Received: from [] ( []) by (Postfix) with ESMTPA id 11ABF3A1E0 for <>; Mon, 7 Mar 2011 08:40:51 +0100 (CET)
Message-ID: <>
Date: Mon, 07 Mar 2011 08:40:52 +0100
From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv: Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [sixpac] Capability and preference expression and interrogation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Mar 2011 07:39:48 -0000

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 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
> ______________________________________________________________________________-- 
> 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 
>> 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 []
>> 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 mailing list