Subject: Re: [sixpac] Capability and preference expression and interrogation

From: Gunnar Hellström <[email-masked]>
Date: Mon, 07 Mar 2011 08:40:52 +0100

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
>
> ______________________________________________________________________________-- 
>
> [email-masked] 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.txt
>>
>> 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:[email-masked]]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sixpac
> _______________________________________________
> sixpac mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sixpac

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 07 Mar 2011 06:56:07 -0700

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.

> The requirement to express the capability of XMPP messaging in SIP 
described
> below also may need  an extension for declaration of 
capability
> details.

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:
> 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.
> 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.)
>
> he
> can receive and read the poems and comment them in their voice 
>
> conversation.
>
> ---
>
>> In REQ-1: ³SIP contact² changed to
> ³SIP address²
>>
>> 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 
>> 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.
>>
>>
>> Presence
> Service.
>> This memo defines use
> cases and requirements for combining Session
_________________________________
> ______________
sixpac mailing
> list
[email-masked]

-- 
Joe Hildebrand

---

From: <[email-masked]>
Date: Thu, 10 Mar 2011 11:28:29 +0000

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Joe Hildebrand
> Sent: 07 March, 2011 15:56
> To: Gunnar Hellström; [email-masked]
> Subject: Re: [sixpac] Capability and preference expression and
> interrogation
> 
> _______________________________________________________________________
> _______
> > --
> >
> > http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmpp-coex-
> reqs-02.t
> > xt
> >>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 10 Mar 2011 16:29:25 +0100

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
[email-masked]
+46708204288

[email-masked] skrev 2011-03-10 12:28:
>> On 3/7/11 12:40 AM, "Gunnar Hellström"<[email-masked]>
>> wrote:
>>

---

From: <[email-masked]>
Date: Fri, 11 Mar 2011 07:23:15 +0000

> From: ext Gunnar Hellström [mailto:[email-masked]]
> Sent: 10 March, 2011 17:29
> Cc: [email-masked]; [email-masked]

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

> > 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
> >
> >> as a part of the presence of a device.  115 usually takes folks a
> while
> >> to

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 11 Mar 2011 10:19:35 +0100

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