Subject: [dispatch] Updated SIP and XMPP combined use charter proposal

From: <[email-masked]>
Date: Mon, 26 Apr 2010 12:12:45 +0200

Hi all,

We held a DISPATCH mini-BoF on SIP and XMPP combined use back at the November IETF with a fair amount of interest. A charter proposal was discussed around December/January, and most people on DISPATCH were happy with the outcome. After that the activity has been limited but there have been discussions with the ADs and some interested folks how the charter proposal should be updated to make it more clear what the mini-WG would be about, and especially what is out of scope. Several people were asking me about the topic before or during Anaheim IETF so I expect the interest for this is still relatively high and we should go forward.

Based on the feedback Simo and myself have drafted an updated charter proposal, see below. 

The use cases and requirements draft has also been updated:
http://datatracker.ietf.org/doc/draft-veikkolainen-sip-xmpp-coex-reqs/

Also, Emil and Enrico submitted a draft on provisioning BCP:
http://datatracker.ietf.org/doc/draft-ivov-sipxmpp-auth/

Please comment especially on the charter if it looks clear and concise enough.

Regards,
	Markus 

Combining SIP Voice and Video with XMPP IM and Presence =======================================================

Session Initiation Protocol (SIP) and Extensible Messaging and Presence Protocol (XMPP) are both enjoying a widespread deployment over the Internet. SIP was originally intended for setting up real-time media sessions, while XMPP's roots are with instant messaging (IM) and presence. While both protocols have mushroomed in functionality, the real deployments still correlate highly with their original scope; SIP is mostly used for voice and video and for interconnect with circuit switched telephony systems, while most of XMPP deployments offer IM and presence services. So far the success with fully integrated voice, video, IM and presence services with either SIP or XMPP has been limited. 

One approach to make the best out of this situation is to integrate a SIP User Agent and an XMPP client into a single application. The application would use SIP for voice and video and XMPP for IM and presence. The best part of this approach would be that no changes to existing SIP or XMPP server infrastructures would be required, and there would be no issues with interoperability between the integrated endpoints and ordinary SIP- or XMPP-only endpoints. This would enable incremental deployment, which is an important success factor. In this "fully independent" form no new SIP or XMPP standards extensions would be either needed.

When two integrated SIP and XMPP endpoints communicate with each other, it would be possible to make the user experience even more seamless by making the two protocols more "aware" of each other through minor protocol extensions. For instance an incoming SIP voice call could be explicitly correlated with an ongoing IM exchange, or XMPP presence could include explicit SIP voice availability status. For the sake of deployment feasibility, it would be mandatory for such protocol extensions not to require any changes to SIP or XMPP server implementations, and to remain backwards compatible with non-updated SIP and XMPP endpoints. 

The objective of this Working Group is to document best practices and develop protocol extensions for combining SIP based voice and video with XMPP based IM and presence such that a unified user experience can be offered to end user. 

Specifically, the WG will address the following use cases: 
-    User identifier discovery; it should be possible for a user to learn other user's SIP identifier based on her XMPP identifier and vice versa for future use without needing to engage in an active communication session with the other user. Mapping of address schemes (sip:, xmpp:, im:, pres: etc.) is out of scope of this Working Group. 
-    Presence integration; it should be possible for user's XMPP presence status to explicitly include her capability and willingness for SIP based voice and video communication. It is desired that only XMPP presence extension mechanisms described in RFC3921 or its successor are used; presence format translation and mapping are out of scope of this Working Group.
-    Session or conversation capability discovery and correlation; it should be possible to combine XMPP IM with SIP voice and video communication between two endpoints so that the endpoints can discover each others' capabilities and explicitly relate the communication across the two protocols.  
-    Provisioning; it should be possible to configure integrated SIP and XMPP endpoints with as small extra burden as possible compared to SIP- or XMPP-only endpoints, especially if both SIP and XMPP are offered by the same service provider. However, it is desired that no protocol changes are needed for this. Also, cross-domain authentication is out of scope of this Working Group.

The protocol extensions developed in the WG must meet the following criteria:
-    The extensions must work without changes to SIP or XMPP server infrastructures (including typical SIP B2BUAs), and across SIP and XMPP deployments that are independent from each other (such as that they are offered by two different non-coordinated domains). 
-    The extensions must not break backwards compatibility with non-updated SIP and XMPP endpoints.

The following is out of scope of the initial charter of the WG: 
-    Multiparty communication, for instance the combined use of SIP voice conferencing and XMPP IM chatrooms. 
-    Advanced services such as SIP session transfer combined with XMPP IM. 
-    Protocol interworking, that is, translation gateways from SIP to XMPP or vice versa. 
-    New routing logic; the WG should rely on existing routing mechanisms defined for SIP and XMPP, and not define cross-domain routing for example in case when a user's SIP AOR is known but that user is not registered for SIP service.

Milestones

Dec 2010 Use cases and protocol requirements document submitted to IESG (Informational).

Aug 2011 Document  defining mechanisms for discovering user's SIP identifier based on her XMPP identifier submitted to IESG (Standards Track).

Aug 2011 Document defining XMPP presence extensions for SIP voice and video communication capability and willingness submitted to IESG (Standards Track).

Aug 2011 Document defining protocol extensions that allow combined SIP voice and video and XMPP IM capable endpoints to discover each others' capabilities and correlate their communication across the two protocols submitted to IESG (Standards Track).

Aug 2011 Document defining best practises document for configuration and provisioning of combined SIP and XMPP endpoints submitted to IESG (BCP).

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Apr 2010 12:39:34 +0200

Markus,

Looks good in general.

"Mapping of address schemes (sip:, xmpp:, im:, pres: etc.) is out of scope of this Working Group."

That's fine, but shouldn't this also be mentioned later in the list of out of scope topics?

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 26 April 2010 11:13
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> Elwell, John; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Updated SIP and XMPP combined use charter proposal
> 
> Hi all,
> 
> We held a DISPATCH mini-BoF on SIP and XMPP combined use back 
> at the November IETF with a fair amount of interest. A 
> charter proposal was discussed around December/January, and 
> most people on DISPATCH were happy with the outcome. After 
> that the activity has been limited but there have been 
> discussions with the ADs and some interested folks how the 
> charter proposal should be updated to make it more clear what 
> the mini-WG would be about, and especially what is out of 
> scope. Several people were asking me about the topic before 
> or during Anaheim IETF so I expect the interest for this is 
> still relatively high and we should go forward.
> 
> Combining SIP Voice and Video with XMPP IM and Presence 
> =======================================================
> 
> Session Initiation Protocol (SIP) and Extensible Messaging 
> and Presence Protocol (XMPP) are both enjoying a widespread 
> deployment over the Internet. SIP was originally intended for 
> setting up real-time media sessions, while XMPP's roots are 
> with instant messaging (IM) and presence. While both 
> protocols have mushroomed in functionality, the real 
> deployments still correlate highly with their original scope; 
> SIP is mostly used for voice and video and for interconnect 
> with circuit switched telephony systems, while most of XMPP 
> deployments offer IM and presence services. So far the 
> success with fully integrated voice, video, IM and presence 
> services with either SIP or XMPP has been limited. 
> 
> One approach to make the best out of this situation is to 
> integrate a SIP User Agent and an XMPP client into a single 
> application. The application would use SIP for voice and 
> video and XMPP for IM and presence. The best part of this 
> approach would be that no changes to existing SIP or XMPP 
> server infrastructures would be required, and there would be 
> no issues with interoperability between the integrated 
> endpoints and ordinary SIP- or XMPP-only endpoints. This 
> would enable incremental deployment, which is an important 
> success factor. In this "fully independent" form no new SIP 
> or XMPP standards extensions would be either needed.
> 
> When two integrated SIP and XMPP endpoints communicate with 
> each other, it would be possible to make the user experience 
> even more seamless by making the two protocols more "aware" 
> of each other through minor protocol extensions. For instance 
> an incoming SIP voice call could be explicitly correlated 
> with an ongoing IM exchange, or XMPP presence could include 
> explicit SIP voice availability status. For the sake of 
> deployment feasibility, it would be mandatory for such 
> protocol extensions not to require any changes to SIP or XMPP 
> server implementations, and to remain backwards compatible 
> with non-updated SIP and XMPP endpoints. 
> 
> The objective of this Working Group is to document best 
> practices and develop protocol extensions for combining SIP 
> based voice and video with XMPP based IM and presence such 
> that a unified user experience can be offered to end user. 
> 
> -    User identifier discovery; it should be possible for a 
> user to learn other user's SIP identifier based on her XMPP 
> identifier and vice versa for future use without needing to 
> engage in an active communication session with the other 
> user. Mapping of address schemes (sip:, xmpp:, im:, pres: 
> etc.) is out of scope of this Working Group. 
> -    Presence integration; it should be possible for user's 
> XMPP presence status to explicitly include her capability and 
> willingness for SIP based voice and video communication. It 
> is desired that only XMPP presence extension mechanisms 
> described in RFC3921 or its successor are used; presence 
> format translation and mapping are out of scope of this Working Group.
> -    Session or conversation capability discovery and 
> correlation; it should be possible to combine XMPP IM with 
> SIP voice and video communication between two endpoints so 
> that the endpoints can discover each others' capabilities and 
> explicitly relate the communication across the two protocols.  
> -    Provisioning; it should be possible to configure 
> integrated SIP and XMPP endpoints with as small extra burden 
> as possible compared to SIP- or XMPP-only endpoints, 
> especially if both SIP and XMPP are offered by the same 
> service provider. However, it is desired that no protocol 
> changes are needed for this. Also, cross-domain 
> authentication is out of scope of this Working Group.
> 
> -    The extensions must work without changes to SIP or XMPP 
> server infrastructures (including typical SIP B2BUAs), and 
> across SIP and XMPP deployments that are independent from 
> each other (such as that they are offered by two different 
> non-coordinated domains). 
> -    Multiparty communication, for instance the combined use 
> of SIP voice conferencing and XMPP IM chatrooms. 
> -    New routing logic; the WG should rely on existing 
> routing mechanisms defined for SIP and XMPP, and not define 
> cross-domain routing for example in case when a user's SIP 
> AOR is known but that user is not registered for SIP service.
> 
> Milestones
> 
> Aug 2011 Document  defining mechanisms for discovering user's 
> SIP identifier based on her XMPP identifier submitted to IESG 
> (Standards Track).
> 
> Aug 2011 Document defining XMPP presence extensions for SIP 
> voice and video communication capability and willingness 
> submitted to IESG (Standards Track).
> 
> Aug 2011 Document defining protocol extensions that allow 
> combined SIP voice and video and XMPP IM capable endpoints to 
> discover each others' capabilities and correlate their 
> communication across the two protocols submitted to IESG 
> (Standards Track).
> 
> Aug 2011 Document defining best practises document for 
> configuration and provisioning of combined SIP and XMPP 
> endpoints submitted to IESG (BCP).

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 27 Apr 2010 11:55:37 +0200

Thanks Markus, this version addresses my previous concerns. I'm fine
with it.

Enrico

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 27 Apr 2010 07:17:01 -0400

Hi,

Overall I think the text is good.

One clarification. The charter says "one approach" is to combine the
XMPP and SIP into a single application. Do you regard cases where they
are in different applications and perhaps on different devices as "in
scope"?

If not, perhaps "The objective..." should be amended to make it clear
that only issues associated with combining them into a single
application are in scope?

If yes, then are mechanism for the applications to exchange info out of scope?

Thanks,

Peter Musgrave

On Tue, Apr 27, 2010 at 5:55 AM, Enrico Marocco
<[email-masked]> wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Apr 2010 14:13:06 -0600

> are in different applications and perhaps on different devices as "in

My understanding has always been that those problems are interesting but
out of scope for now -- the group wants to make progress on a
well-defined problem (dual-stack user agents) before trying to solve
other problems.

> application are in scope?

That seems appropriate.

> If yes, then are mechanism for the applications to exchange info out of scope?

I think that it is out of scope for this group to work on coordination
between single-stack (SIP only or XMPP only) user agents on the same
device (or multiple devices controlled by the same user).

But those who have proposed this work can correct me if I'm wrong. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Wed, 28 Apr 2010 08:13:46 +0200

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of ext Peter Saint-Andre
>Sent: 27 April, 2010 23:13
>To: Peter Musgrave
>Cc: [email-masked]; [email-masked]; Isomaki Markus
>(Nokia-CIC/Espoo)
>Subject: Re: [dispatch] Updated SIP and XMPP combined use charter
>proposal
>
>out of scope for now -- the group wants to make progress on a well-
>defined problem (dual-stack user agents) before trying to solve other
>problems.

That has indeed been our intention.

>> If yes, then are mechanism for the applications to exchange info out

How about "The objective of this Working Group is to document best practices and develop protocol extensions for combining SIP based voice and video with XMPP based IM and presence into a single application so that a unified user experience can be offered to end user."?

Simo