Hiroshima follow-up

We had some good discussions about SIP-XMPP interworking in Hiroshima,
although my involvement was limited to the "Hallway WG" because I had to
leave before the more formal discussion on Friday. Does anyone have
notes from the Friday meeting?

The primary interest right now seems to be in dual-stack clients.
Related to that, I have three work items in my personal notes:

1. Investigate Reachability Addresses (XEP-0152) as a way to advertise
your SIP address on the XMPP side (either via presence or PEP).

2. Define a special XMPP message format to warn your chat partner that
you'll be sending a session initiation via SIP (including the full JID
of the sending resource).

3. Define a SIP header that includes information about the XMPP
discussion thread (or JID) that triggered the SIP message.

These seem to be the "low-hanging fruit" from discussions in Hiroshima.
Who wants to work on these?

And is there anything else that I missed?

Peter

Peter Saint-Andre wrote:
> We had some good discussions about SIP-XMPP interworking in Hiroshima,
> although my involvement was limited to the "Hallway WG" because I had to
> leave before the more formal discussion on Friday. Does anyone have
> notes from the Friday meeting?
the notes from the Friday meeting are here
( http://www.ietf.org/proceedings/09nov/minutes... )

Ad-hoc Meeting on SIP-XMPP

Friday, November 13th, 2009
===========================

Meeting chaired by: Gonzalo Camarillo and Simo Veikkolainen

Minutes produced by Simo Veikkolainen based on detailed notes by
Spencer Dawkins and Shida Schubert.


Topic: Agenda Bashing

Jon Peterson requested to present slides on voice-presence
interaction. It was agreed to take the presentation as the last agenda
item.


Topic: SIP-XMPP Combined Use Motivation and Use Cases

Markus Isomäki presented the slides covering the motivation, assumed
architecture, use cases and requirements. Adam Roach and Roni Even
expressed their concern that the requirements already address the
solution. The requirements should state that the initial use cases
only need support in the endpoints, so that deployment would not
require upgrades in the existing SIP or XMPP servers. Robert Sparks
commented that it should also be clearly stated that interworking
between SIP-only endpoint and XMPP-only endpoint is out of scope. Emil
Ivov would like to see some text on how to handle overlapping
information (e.g. presence).

B2BUA concerns were also discussed. It was noted that we cannot
prevent B2BUA's from modifying/stripping any header they like, but at
least we should avoid relying on those headers which B2BUA's are known
to modify (like Call-ID).


Topic: Technical overview on SIP-XMPP co-existence

Simo Veikkolainen presented the slides covering the technical approach
to SIP-XMPP co-existence as described in
drat-veikkolainen-sip-voip-xmpp-im. The goal is to offer the user a
seamless user experience as if only one protocol is used, even though
actually two protocols are used to provide the voice and IM/presence
components. About seven people had read the draft (out of the 20 or so
in the room).

Main topics in the discussion that followed were:

- we need to check that the proposed solution does not break anything
  in the way SIP and XMPP are used today (for example, SIP
  supplementary services),

- we need GRUU and JID Resource to be able to point to a specific user
  agent/endpoint instance. The Resource in particular can be dynamic
  in nature, which needs to be taken into account.

- the effects of B2BUAs was also discussed. Adam Roach proposed that
  the correlation related information could be carried in the SDP,
  which would be safer from B2BUA point of view. 

- scoping: Robert Sparks reconfirmed that the scope is only about
  integrated endpoint, and that SIP-XMPP interworking is out of
  scope. 

A hum was taken to see whether the IETF should be working on the
problem space, and there was full consensus for doing so. There was
also strong consensus with little opposition to take the proposed
charter text as a starting point. It was agreed to modify the charter
to clearly state that the focus is only on the integrated endpoint.

When asked who are willing to contribute to the work, about five
people expressed their interest.

Charter will be scoped/revised according to the debate and will be
sent for AD for further treatment.

On 12/9/09 8:49 AM, Salvatore Loreto wrote:

> Charter will be scoped/revised according to the debate and will be
> sent for AD for further treatment.
Thanks, Sal! So is the dispatch list the right place to continue this
discussion? Given that some of this work might happen in the XSF (cf.
XEP-0252 and the XMPP "warning message"), we might want to continue to
use this list for some aspects of the discussion.

Peter

yes for the time being Dispatch ml is the place of discussion

I guess that at some point it will be created an ad-hoc mailing list for 
the new mini wg that Dispatch will charter...
at least this is the normal Dispatch process
Peter Saint-Andre wrote:
> On 12/9/09 8:49 AM, Salvatore Loreto wrote:
>
>   
>> Charter will be scoped/revised according to the debate and will be
>> sent for AD for further treatment.
>>     
>
> Thanks, Sal! So is the dispatch list the right place to continue this
> discussion? Given that some of this work might happen in the XSF (cf.
> XEP-0252 and the XMPP "warning message"), we might want to continue to
> use this list for some aspects of the discussion.
>
> Peter
>
>

Hi Peter,

Here's the proposed charter that Simo just submitted on DISPATCH WG list. In spirit it matches your "low-hanging fruit" thinking and the three needed solutions (addressing, session correlation, presence) are pretty much just abstractions on your three bullets below. 

Some further comments inline.
Peter Saint-Andre wrote:
>
>We had some good discussions about SIP-XMPP interworking in 
>Hiroshima, although my involvement was limited to the "Hallway 
>WG" because I had to leave before the more formal discussion 
>on Friday. Does anyone have notes from the Friday meeting?
>
>The primary interest right now seems to be in dual-stack clients.
>Related to that, I have three work items in my personal notes:
>
>1. Investigate Reachability Addresses (XEP-0152) as a way to 
>advertise your SIP address on the XMPP side (either via 
>presence or PEP).
In principle we should have a way to map a XMPP bare JID to a SIP AoR. This is typically somewhat static mapping (it's valid as long as the user keeps her XMPP and SIP accounts and the way how a "dual stack" client would be configured with them), so it's close to a directory lookup. However, rather than relying on external mechanism (LDAP etc.), it would be good if we had a way to do that within the XMPP infrastructure. 

As a second thing, it would be good to have a way how the XMPP presence (not sure if this is the right term here since XMPP seems to have all kinds of user-specific state) could show the more dynamic state of the SIP account, e.g. whether the user is available, on the phone etc. The combo-client would know it's SIP related state and update that via XMPP. That dynamic info could also contain endpoint specific SIP URI (called GRUU), although those are quite rare in SIP.
>
>2. Define a special XMPP message format to warn your chat 
>partner that you'll be sending a session initiation via SIP 
>(including the full JID of the sending resource).
What is exactly needed depends on what is seen as the best way to discover the chat partner's endpoint specific SIP address. If that can be looked-up from e.g. presence, it does not need to be exchanged during the chat. However, if that option is not viable, the chat partners would first have to exchange their SIP addresses so they know where to call to. And in that case they could exchange a token that means "if you get a SIP INVITE with this token it's related to this chat" (so maybe the UI could take a hint on that when the INVITE does come). So, there might be other options than the warning that you talk about.
>
>3. Define a SIP header that includes information about the 
>XMPP discussion thread (or JID) that triggered the SIP message.
>
That sounds like the counterpart of mechanism 2. on the SIP side. Again, one way would be that the XMPP chat partners would exchange their SIP addresses + the correlation token tied to the discussion thread (so it would need to be exchanged only once per thread), and then that token would be replayed in the SIP INVITE header.

Similarly, we would need a SIP header whereby the SIP calling parties could exchange their full JIDs + the token and the token would then be carried in the first XMPP Messages.
>These seem to be the "low-hanging fruit" from discussions in Hiroshima.
>Who wants to work on these?
>
The charter defines an initial deliverable which is a draft that only explains the problem statement and the use cases (and requirements), so we can agree on those. Myself and Simo are planning to submit a strawman on that as the first thing. So we are definitely working on this and in the BOF there were 7-8 other people who expressed interest. 

It's of course OK to work on the protocol stuff already, I hope we have a pretty good picture of the use cases, but it's still good to write those down. If people want to join that work please let us know or just wait for -00 draft to comment (or actually, you can already comment Section 3 in http://tools.ietf.org/html/draft-veikkolainen...).

>And is there anything else that I missed?

During the Friday discussion some people proposed that in SIP, instead of using headers, we could use SDP offer/answer. So, if the starting point for the communication is SIP call, in addition to the VoIP/RTP you could negotiate XMPP IM "virtual session". That's another way, but since SDP offer/answer is quite complicated in SIP (offer and answer can be exchanged and updated in various kinds of SIP requests/responses etc.), it might be more difficult for implementors to get it right that way. Especially, if in practice the offer vs. answer semantics are not that complex, we just want the clients to exchange their full JIDs and agree on a correlation token.

Some people also brought up cases where the SIP and XMPP are actually offered by the same provider, and maybe we could further optimize that case. I'm not sure how, though, there were no concrete examples. Also a couple of people have wanted to look into cases where the two protocols have overlapping functionality, for instance both have presence. I think we should now start with the simple assumption that the "dual stack" client does VoIP ( + video) with SIP and all the rest with XMPP, at least in the scenarious we are talking about.
>
>Peter
>
>--
>Peter Saint-Andre
>https://stpeter.im/
>
Markus
Hello,
Below is the proposed charter text for Combining SIP and XMPP revised according to the discussions in Hiroshima. Basically the changes are

- include video in addition to voice
- mention that existing SIP and XMPP endpoints are not affected
- update milestones.

Comments are very welcome.

Regards,
Simo


-----8<------8<------8<------

Combining SIP VoIP and XMPP IM/Presence
=======================================

Currently most standards-based Voice over IP (VoIP) deployments use the Session Initiation Protocol (SIP).  In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN).  SIP is also gaining popularity in the field of video communication. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is enjoying widespread usage in instant messaging and presence services.  

Both SIP and XMPP offer extensions for integrating voice and video with IM and presence (XMPP voice via the Jingle extension, and SIP IM/presence via SIMPLE protocols). However, widespread deployment of these extensions has not so far taken place. In order to speed up deployment of integrated VoIP and IM systems, SIP based voice and XMPP based IM/Presence could be combined in endpoints to offer a voice, IM and presence service without any changes to existing SIP and XMPP service infrastructure. 

The objective of this Working Group is to develop solutions for combining SIP based voice with XMPP based IM and Presence such that a unified user experience can be offered to end user. Specifically, solutions are needed on 
- addressing; end users should be able to initiate sessions to a user identity in either SIP or XMPP domain. The corresponding user identity in the other protocol domain needs to be learned automatically.
- session correlation; endpoints need to be able to correlate SIP voice and video sessions with XMPP IM/Presence in such a manner that they can be presented to the end user in a seamless fashion
- presence; it should be possible to change the XMPP presence status based on the user's activity in the SIP domain.

Existing SIP and XMPP endpoints are not affected and can interoperate with the implementations that comply with the extensions defined by this Working Group (but obviously without the additional functionality provided by these extensions).

The goal is to rely on existing service infrastructure, and new requirements should be imposed only on the endpoints. 

Protocol interworking, that is, translation from one protocol to another, is out of scope of this WG.

Milestones
Jun 2010 Problem statement and use cases submitted to IESG as Informational.
Jun 2011 Specification on combining SIP based voice and video and XMPP based IM/Presence in a seamless manner submitted to IESG as Proposed Standard.

-----8<------8<------8<------

On 12/9/09 1:02 PM,  wrote:
> Hi Peter,
> 
> Here's the proposed charter that Simo just submitted on DISPATCH WG
> list.
As I posted on the dispatch list, that looks good to me.
> In spirit it matches your "low-hanging fruit" thinking and the
> three needed solutions (addressing, session correlation, presence)
> are pretty much just abstractions on your three bullets below.
> 
> Some further comments inline.
> 
> Peter Saint-Andre wrote:
>> We had some good discussions about SIP-XMPP interworking in 
>> Hiroshima, although my involvement was limited to the "Hallway WG"
>> because I had to leave before the more formal discussion on Friday.
>> Does anyone have notes from the Friday meeting?
>> 
>> The primary interest right now seems to be in dual-stack clients. 
>> Related to that, I have three work items in my personal notes:
>> 
>> 1. Investigate Reachability Addresses (XEP-0152) as a way to 
>> advertise your SIP address on the XMPP side (either via presence or
>> PEP).
> 
> In principle we should have a way to map a XMPP bare JID to a SIP
> AoR. This is typically somewhat static mapping (it's valid as long as
> the user keeps her XMPP and SIP accounts and the way how a "dual
> stack" client would be configured with them), so it's close to a
> directory lookup. However, rather than relying on external mechanism
> (LDAP etc.), it would be good if we had a way to do that within the
> XMPP infrastructure.
Static mappings could go in a vCard.
> As a second thing, it would be good to have a way how the XMPP
> presence (not sure if this is the right term here since XMPP seems to
> have all kinds of user-specific state) could show the more dynamic
> state of the SIP account, e.g. whether the user is available, on the
> phone etc. The combo-client would know it's SIP related state and
> update that via XMPP. That dynamic info could also contain endpoint
> specific SIP URI (called GRUU), although those are quite rare in SIP.
We could, naturally, put the complete PIDF into XMPP presence. That
seems a bit heavy, though.
>> 2. Define a special XMPP message format to warn your chat partner
>> that you'll be sending a session initiation via SIP (including the
>> full JID of the sending resource).
> 
> What is exactly needed depends on what is seen as the best way to
> discover the chat partner's endpoint specific SIP address. If that
> can be looked-up from e.g. presence, it does not need to be exchanged
> during the chat. However, if that option is not viable, the chat
> partners would first have to exchange their SIP addresses so they
> know where to call to. And in that case they could exchange a token
> that means "if you get a SIP INVITE with this token it's related to
> this chat" (so maybe the UI could take a hint on that when the INVITE
> does come). So, there might be other options than the warning that
> you talk about.
True.
>> 3. Define a SIP header that includes information about the XMPP
>> discussion thread (or JID) that triggered the SIP message.
>> 
> 
> That sounds like the counterpart of mechanism 2. on the SIP side.
> Again, one way would be that the XMPP chat partners would exchange
> their SIP addresses + the correlation token tied to the discussion
> thread (so it would need to be exchanged only once per thread), and
> then that token would be replayed in the SIP INVITE header.
> 
> Similarly, we would need a SIP header whereby the SIP calling parties
> could exchange their full JIDs + the token and the token would then
> be carried in the first XMPP Messages.
Or the token could simply be the XMPP thread-id (not that many clients
really support that!).
>> These seem to be the "low-hanging fruit" from discussions in
>> Hiroshima. Who wants to work on these?
>> 
> 
> The charter defines an initial deliverable which is a draft that only
> explains the problem statement and the use cases (and requirements),
> so we can agree on those. Myself and Simo are planning to submit a
> strawman on that as the first thing. So we are definitely working on
> this and in the BOF there were 7-8 other people who expressed
> interest.
That's great.
> It's of course OK to work on the protocol stuff already, I hope we
> have a pretty good picture of the use cases, but it's still good to
> write those down. If people want to join that work please let us know
> or just wait for -00 draft to comment (or actually, you can already
> comment Section 3 in
> http://tools.ietf.org/html/draft-veikkolainen...).
> 
>> And is there anything else that I missed?
> 
> During the Friday discussion some people proposed that in SIP,
> instead of using headers, we could use SDP offer/answer. So, if the
> starting point for the communication is SIP call, in addition to the
> VoIP/RTP you could negotiate XMPP IM "virtual session". That's
> another way, but since SDP offer/answer is quite complicated in SIP
> (offer and answer can be exchanged and updated in various kinds of
> SIP requests/responses etc.), it might be more difficult for
> implementors to get it right that way. Especially, if in practice the
> offer vs. answer semantics are not that complex, we just want the
> clients to exchange their full JIDs and agree on a correlation token.
That sounds similar to the very old draft by Robert Sparks:

http://tools.ietf.org/html/draft-sparks-simpl...
> Some people also brought up cases where the SIP and XMPP are actually
> offered by the same provider, and maybe we could further optimize
> that case. I'm not sure how, though, there were no concrete examples.
> Also a couple of people have wanted to look into cases where the two
> protocols have overlapping functionality, for instance both have
> presence. I think we should now start with the simple assumption that
> the "dual stack" client does VoIP ( + video) with SIP and all the
> rest with XMPP, at least in the scenarious we are talking about.
Yes, I think that is the right starting-point.

Peter