Subject: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence

From: <[email-masked]>
Date: Mon, 21 Sep 2009 14:28:43 +0200

Hello,

Below is the draft charter text for our proposal on combining SIP voice with XMPP IM and presence.

Comments are very welcome!

Regards,
Simo

-----------------

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 voice as well as 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 infrastrucure. 

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 voice sessions with IM/Presence such 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.

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

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

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

-----------------

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Sep 2009 15:33:14 -0600

> Comments are very welcome!

Hi Simo,

Do you think that this proposed working group would incorporate or
complete work on the existing I-Ds I have listed below?

http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media

It would be nice to find a home for those I-Ds, and a focused group of
people who want to finish them.

Peter

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 21 Sep 2009 18:03:09 -0500

At 04:33 PM 9/21/2009, Peter Saint-Andre wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>

+1 to what Peter asked.

I'd like to add a comment about the charter as written emphasizing 
"SIP voice" at the expense of "SIP video" (i.e., there is no mention 
of video)...

Since SIP doesn't care which codec(s) are in the offer/answer 
exchange, video needs to be stated explicitly if voice is called out.

James

>Peter
>
>- --
>Peter Saint-Andre
>https://stpeter.im/
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.8 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iEYEARECAAYFAkq38RoACgkQNL8k5A2w/vwgiACfUzJTMSaaH7hc+9u8JrPwgQ2S
>QQEAoMcAOMhkYNVHxNxJs7GIJye5XPoT
>=QMet
>-----END PGP SIGNATURE-----
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: Roni Even <[email-masked]>
Date: Tue, 22 Sep 2009 09:16:41 +0300

Hi,
I see similarity in the objectives to the disaggregated media discussed in a
separate thread, see my inline comments in the objectives. I believe that
there is a general case here and not only a specific use case. 
 
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.

Roni: Same in disaggregated media where you have two separate call legs that
you want to look like one

- session correlation; endpoints need to be able to correlate voice sessions
with IM/Presence such that they can be presented to the end user in a
seamless fashion

Roni: need to correlate for example between a call on a Phone device and
video from a conference room video system. The audio will be on the phone
and the video on the room system with two SIP call legs.

- presence; it should be possible to change the XMPP presence status based
on the user's activity in the SIP domain.

Roni: In the disaggregated media case the calling user should be able to
know if the called party can have a separate video call before trying to
start the second call leg. 

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, September 21, 2009 3:29 PM
> To: [email-masked]
> Subject: [dispatch] Charter proposal on combining SIP voice with XMPP
> IM and presence
> 
> Hello,
> 
> 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 voice as well as 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 infrastrucure.
> 
> 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 voice
> sessions with IM/Presence such 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.
> 
> The goal is to rely on existing service infrastructre, and new
> requirements should be imposed only to the endpoint.
> 
> Dec 2010 Specification on combining SIP based voice and XMPP based
> IM/Presence in a seamless manner submitted to IESG as Proposed
> Standard.
> 
> -----------------

---

From: Roni Even <[email-masked]>
Date: Tue, 22 Sep 2009 09:20:25 +0300

Hi,
The charter looks good, what I am missing is the multiparty issue. XMPP is
used for a multiparty chat and I think that in that case the users will
expect an audio/video conference to run in parallel

Roni Even

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 13:16:29 +0200

Hi James, 

James M. Polk wrote:
>
>I'd like to add a comment about the charter as written 
>emphasizing "SIP voice" at the expense of "SIP video" (i.e., 
>there is no mention of video)...
>

I agree. I think we can pretty much replace "voice" with "voice and video" throughout the charter.

The reason voice was emphasized was simply due to its dominance over video in current SIP deployments. However, if we look at the potential framework for combined use of SIP and XMPP, it's quite clear that the setup of video sessions would belong into the domain of SIP. There's no technical difference between voice and video in this regard.

Markus

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Sep 2009 14:00:39 +0200

Hey Simo,

We've been considering and playing a similar mode of operation for a
couple of years now and some of the most delicate issues that we've come
across include "disambiguation of overlapping services and information"
and "behaviour in cases of "half-failure". Here's what I mean:

What happens for example if a mixed client receives a message over
SIMPLE rather than XMPP. Should it be accepted and displayed to the
user? If yes, then where should a client reply (i.e. SIMPLE or XMPP)? If
we choose SIMPLE for how long should the client privilege SIMPLE over
XMPP and under what conditions.

What happens if a mixed client detects presence agent capabilities in a
SIP service? Should it ignore them and only go for XMPP, use them for
certain destinations only (e.g. destinations that we only have a SIP
address for such as conventional SIP phones), or duplicate all
information over the two protocols in which case: How should clients
handle conflicting presence information received via the two protocols?

How should we handle failures for only one of the services. For example:
 I am a mixed UA and am unable to connect to a SIP registrar but can
still use XMPP. Should I declare complete failure to the user? Should I
declare success but warn the user that some features won't work? If
possible, should I try to make up for the missing SIP services using
XMPP (and vice versa).

So, if you think the above are worth considering how about adding
something along these lines:

disambiguation: both XMPP and SIP define semantics that allow each of
the protocols to offer the complete set of services discussed in this
charter (i.e. voice, video, messaging, and presence). In environments
where one or more of these services are supported with both protocols
clients should be able to use a common procedure for determining which
one to use and under what conditions.

half-failures: in cases where use of one of the protocols becomes
impossible (e.g. due to a server failure) clients should be able to
follow clear procedures on how to behave, which services could they try
to reuse over the protocol that is still available and under what
conditions.

WDYT?

Emil

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
[email-masked]                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Sep 2009 09:23:56 -0400

The issues Emil raises are good ones.
I think they should be in scope for this effort.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Sep 2009 09:25:36 -0400

> expect an audio/video conference to run in parallel

Agree.

Similarly, other features will also be expected to work, such as transfer.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Sep 2009 09:31:44 -0400

> start the second call leg. 

I've been arguing that in the all-sip case the burden of aggregating the 
disparate media/devices should fall on the end that wants it, not on the 
other end that is happy to have a single multimedia session. That 
eliminates the question of whether the called party can support a 
separate video call.

That of course doesn't work when aggregating two protocols that 
different approaches to session initiation, such as SIP and XMPP. 
(Unless one can function as a subordinate to the other, such as 
negotiating an "XMPP session" using sip.

	Thanks,
	Paul

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Sep 2009 15:43:08 +0200

How would this work relate to the item in the XMPP WG charter?  

> Many of the core and extended features of XMPP have also been
implemented in technologies based on the Session Initiation Protocol
(SIP). To ensure interworking between XMPP systems and SIP systems, a
number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been
produced. The group will define a framework within which this work could
be completed.

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Tuesday, September 22, 2009 12:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [dispatch] Charter proposal on combining SIP 
> voice with XMPP IM and presence
> 
> Do you think that this proposed working group would 
> incorporate or complete work on the existing I-Ds I have listed below?
> 
> It would be nice to find a home for those I-Ds, and a focused 
> group of people who want to finish them.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
>

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 15:44:08 +0200

Hi, 

Paul Kyzivat wrote:
>
>Roni Even wrote:
>> Hi,
>> The charter looks good, what I am missing is the multiparty issue. 
>> XMPP is used for a multiparty chat and I think that in that case the 
>> users will expect an audio/video conference to run in parallel
>
>Agree.
>

We could add such things on the charter at later dates. I think it would be important to get something concrete solved first, and preferably even implemented and deployed before going forward. Initially we should IMHO only have features that can be relatively easily implemented by using existing SIP and XMPP client codebases. Otherwise we loose the whole point of this work. 

In general I agree that we need to have a way for the combined client to be able to take part into a SIP based voice/video conference and XMPP based multiparty IM chat and if the server side supports the proper extensions, actually know that these two are part of the same multimedia conference. Perhaps even the rosters can be correlated. But at least we shouldn't require the full XCON suite for this.

Markus

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 22 Sep 2009 16:53:57 +0300

I have only followed parts of the email thread but I would favor of keeping
the two efforts separately since the problem statements are quite different.
Don't re-write them in a way that nobody understands them anymore. 

The SIP / XMPP interworking is also a topic of relevance today, i.e. not a
research topic.

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 15:51:02 +0200

Hi,

That's exactly the same work. I guess Peter is asking if that SIP-related work could be moved from XMPP WG to happen together with the proposed SIP-XMPP combined use work, as a new (mini-)WG for instance.

To me Peter's request makes sense. Of course only if we manage to get the new SIP/XMPP group setup.) It's a bit odd thing currently in XMPP WG. That's the same reason we are bringing the SIP/XMPP combined use proposal to DISPATCH rather than XMPP WG, i.e. it does not really fit that well with the other items XMPP WG is working on.

Markus

>[mailto:[email-masked]] On Behalf Of ext Romascanu, 
>Dan (Dan)
>Sent: 22 September, 2009 16:43
>To: Peter Saint-Andre; Veikkolainen Simo (Nokia-D/Helsinki)
>Cc: [email-masked]
>implemented in technologies based on the Session Initiation 
>Protocol (SIP). To ensure interworking between XMPP systems 
>and SIP systems, a number of Internet-Drafts 
>(draft-saintandre-sip-xmpp-*) have been produced. The group 
>will define a framework within which this work could be completed.
>
>Dan
>
>
>> Subject: Re: [dispatch] Charter proposal on combining SIP voice with 
>> XMPP IM and presence
>>

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 16:05:29 +0200

Hannes,

Which two efforts are you talking about? At least three efforts have been brought up that have some relationship:

1. SIP and XMPP combined use (the charter proposed in this thread, draft-veikkolainen-...) 
2. SIP - XMPP interworking (already a WG item in XMPP WG, draft-saintandre-sip-...)
3. Disaggregated media proposal (sent to DISPATCH by Salvatore Loreto)

My take is that 1. and 2. are relatively orthogonal but probably the same set of people are interested in them. 1 and 3. are related in a sense that if we define some kind of session correlation header in SIP (to correlate two or more SIP dialogs/sessions) we might ideally use the same for SIP/XMPP correlation purposes. But that's a minor optimization and either work should not get stuck behind the other. There's still room for new SIP headers, right :-)

Markus

>[mailto:[email-masked]] On Behalf Of ext Hannes Tschofenig
>Sent: 22 September, 2009 16:54
>To: 'Paul Kyzivat'; 'Roni Even'
>Cc: Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]
>I have only followed parts of the email thread but I would 
>favor of keeping the two efforts separately since the problem 
>statements are quite different.
>The SIP / XMPP interworking is also a topic of relevance 
>today, i.e. not a research topic. 
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 22 Sep 2009 17:11:20 +0300

Sorry, I should have been more precise. I was referring to "SIP and XMPP
combined use" and "Disaggregated media proposal". Even if we envision
solutions to be similar (some form of SIP header) does not mean that they
need to be mashed together. 

>From: [email-masked] [mailto:[email-masked]] 
>Sent: 22 September, 2009 17:05
>To: [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: RE: [dispatch] Charter proposal on combining SIP 
>voice with XMPP IMand presence
>
>Hannes,
>
>Which two efforts are you talking about? At least three 
>efforts have been brought up that have some relationship:
>
>1. SIP and XMPP combined use (the charter proposed in this 
>thread, draft-veikkolainen-...) 2. SIP - XMPP interworking 
>(already a WG item in XMPP WG,  draft-saintandre-sip-...) 3. 
>Disaggregated media proposal (sent to DISPATCH by Salvatore Loreto)
>
>My take is that 1. and 2. are relatively orthogonal but 
>probably the same set of people are interested in them. 1 and 
>3. are related in a sense that if we define some kind of 
>session correlation header in SIP (to correlate two or more 
>SIP dialogs/sessions) we might ideally use the same for 
>SIP/XMPP correlation purposes. But that's a minor optimization 
>and either work should not get stuck behind the other. There's 
>still room for new SIP headers, right :-)
>
>Markus
>
>
>>I have only followed parts of the email thread but I would favor of 
>>keeping the two efforts separately since the problem statements are 
>>quite different.
>>The SIP / XMPP interworking is also a topic of relevance today, i.e. 
>>not a research topic.
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Sep 2009 09:13:32 -0600

> produced. The group will define a framework within which this work could

Right, that refers to the drafts I noted in my previous message. As Simo
points out, the same people would be interested in both the "combined
SIP/XMPP" use cases and the "SIP/XMPP interworking" use cases. IMHO it
would be more productive to complete the interworking tasks in a WG that
is dedicated to SIP and XMPP, rather than in the XMPP WG.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Sep 2009 09:15:25 -0600

On 9/22/09 7:51 AM, [email-masked] wrote:
> Hi,
> 
> That's exactly the same work. I guess Peter is asking if that
> SIP-related work could be moved from XMPP WG to happen together with
> the proposed SIP-XMPP combined use work, as a new (mini-)WG for
> instance.
> 
> To me Peter's request makes sense. Of course only if we manage to get
> the new SIP/XMPP group setup.) It's a bit odd thing currently in XMPP
> WG. That's the same reason we are bringing the SIP/XMPP combined use
> proposal to DISPATCH rather than XMPP WG, i.e. it does not really fit
> that well with the other items XMPP WG is working on.

Agreed.

Peter

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Sep 2009 17:47:13 +0200

> From: Peter Saint-Andre [mailto:[email-masked]] 

> As Simo points out, the same people would be 
> interested in both the "combined SIP/XMPP" use cases and the 
> "SIP/XMPP interworking" use cases. 

Can you shortly explain what is the difference between the two or point
me to a reference that explains this? 

> IMHO it would be more 
> productive to complete the interworking tasks in a WG that is 
> dedicated to SIP and XMPP, rather than in the XMPP WG.

Yes, but the XMPP WG was (re)chartered just a few months ago, and I am
trying to understand what changed since then, or what happened in the
XMPP WG for this work to look so soon for another home. 

Thanks and Regards,

Dan

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Sep 2009 10:06:54 -0600

> me to a reference that explains this? 

Combinations are things like "invoke an XMPP groupchat session from a
SIP UA" or "show XMPP presence in a SIP UA".

Interworkings are things like "gateway instant messages between a SIP
network and an XMPP network".

> XMPP WG for this work to look so soon for another home. 

The XMPP WG was the best home we had for the SIP-XMPP interworking
effort at the time and IMHO will not receive a great deal of attention
within the XMPP WG because that WG is prioritizing XMPP-specific tasks
such as:

1. Completion of revisions to RFC 3920 and RFC 3921

2. Replacement of RFC 3923 (end-to-end signing and encryption) with
technologies that will be more widely deployed (probably based on TLS
for encryption and XMLDSIG for signing, though that is yet to be worked
out in detail)

3. Improvement of the server-to-server communications model for secure
federation between large-scale service providers.

IMHO those activities will keep the XMPP WG chugging along for a while
and the SIP-XMPP work will not receive a lot of attention. If we can
move it over to a new, more focused WG then I am in favor, because that
will encourage faster progress, I think.

Peter

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Sep 2009 18:10:52 +0200

Got it, thanks for the explanations. The differences between the two
approaches could be caught in text in the proposed charter - BTW. Moving
work from an existing WG to a new one is an interesting exercise,
because you are implicitly requiring some kind of rechartering of the
XMPP WG as well, but (much) better schedules in a better focused effort
are a good argument. 

Dan

> Sent: Tuesday, September 22, 2009 7:07 PM
> To: Romascanu, Dan (Dan)
> >> As Simo points out, the same people would be interested in 
> both the 
> >> "combined SIP/XMPP" use cases and the "SIP/XMPP interworking" use 
> >> cases.
> > 
> > Can you shortly explain what is the difference between the two or 
> > point me to a reference that explains this?
> 
> Combinations are things like "invoke an XMPP groupchat 
> session from a SIP UA" or "show XMPP presence in a SIP UA".
> 
> Interworkings are things like "gateway instant messages 
> between a SIP network and an XMPP network".
> 
> >> IMHO it would be more
> The XMPP WG was the best home we had for the SIP-XMPP 
> interworking effort at the time and IMHO will not receive a 
> great deal of attention within the XMPP WG because that WG is 
> prioritizing XMPP-specific tasks such as:
> 
> 2. Replacement of RFC 3923 (end-to-end signing and 
> encryption) with technologies that will be more widely 
> deployed (probably based on TLS for encryption and XMLDSIG 
> for signing, though that is yet to be worked out in detail)
> 
> 3. Improvement of the server-to-server communications model 
> for secure federation between large-scale service providers.
> 
> IMHO those activities will keep the XMPP WG chugging along 
> for a while and the SIP-XMPP work will not receive a lot of 
> attention. If we can move it over to a new, more focused WG 
> then I am in favor, because that will encourage faster 
> progress, I think.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> iEYEARECAAYFAkq49h4ACgkQNL8k5A2w/vzSBgCcCW1gmIkfa21x9xrfY2oQIH59
> DdQAnRI/hoskAt5Rja+fH46zo/EqEnnI
> =aWhG

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 22 Sep 2009 18:33:38 +0200

>network and an XMPP network".

I think both your combination examples requires interworking. What  
I've seen discussed here are multiprotocol clients so combination  
would rather be something like

"invoke a SIP conference call and XMPP groupchat simultaneously"

or

"Avoid SIP calls if XMPP presence is DND"

> will encourage faster progress, I think.

Will a new working group mean a whole set of fresh new members with  
more time?

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Sep 2009 10:40:20 -0600

On 9/22/09 10:33 AM, Olle E. Johansson wrote:
> Will a new working group mean a whole set of fresh new members with more
> time?

Last I checked, fresh new members don't materialize out of thin air. :)

My point is that *if* a new SIP-XMPP group is being chartered anyway, it
would be more productive to have all the SIP-XMPP work happening there,
because (1) most people involved in the XMPP WG are only interested in
XMPP and the SIP-XMPP work is not top-of-mind for them, and (2) we might
be able to attract interest in SIP-XMPP work among implementers for whom
SIP-XMPP interworking/combinations are a pain point (that would include
client developers, server developers, and operators). If we reach out to
those folks and define a problem statement that captures what they are
seeing in the implementation and deployment space, then yes we might be
able to attract some fresh new members.

Peter

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 22 Sep 2009 18:43:50 +0200

22 sep 2009 kl. 18.40 skrev Peter Saint-Andre:

>> more
I am aware of that issue... ;-)

> able to attract some fresh new members.

Agreed. I am very interested in the SIP-XMPP work.
I might just materialize at some point. Maybe not out of thin air  
though.

/O

---

From: <[email-masked]>
Date: Wed, 23 Sep 2009 09:49:26 +0200

Hi Paul and Emil,

>From: ext Paul Kyzivat [mailto:[email-masked]] 
>Sent: 22 September, 2009 16:24
>To: Emil Ivov

I also think the issues Emil raises are very valid, and we would need to consider those.

>> couple of years now and some of the most delicate issues that we've 
>> come across include "disambiguation of overlapping services 
>and information"
>> user? If yes, then where should a client reply (i.e. SIMPLE 
>or XMPP)? 
>> If we choose SIMPLE for how long should the client privilege SIMPLE 
>> over XMPP and under what conditions.
>> 
>> What happens if a mixed client detects presence agent 
>capabilities in 
>> a SIP service? Should it ignore them and only go for XMPP, use them 
>> for certain destinations only (e.g. destinations that we only have a 
>> SIP address for such as conventional SIP phones), or duplicate all 
>> still use XMPP. Should I declare complete failure to the 
>user? Should 
>> I declare success but warn the user that some features won't 
>work? If 

Without addressing each issue separately, I would say we can provide normative statements for some situations, but most likely some issues listed above will have to be left for the implementation to deal with.

As has been pointed out in earlier emails, there is no automatic correlation of SIP and XMPP user id's and thus an AOR [email-masked] may not belong to the same person as the JID [email-masked]. This rules out the possibility of responding to a SIP MESSAGE with an XMPP <message> stanza without some a priori knowledge on Alice's identity in XMPP domain. 

>From an end user's point of view it makes no difference which protocol is used. Personally, I would not mind having all my messaging (IM's via different service providers, SMS, email etc.) visible in a single application view, and let the application hide some of the complexity. 

We have only covered some use cases in our document, but I agree we probably need to take a look at other situations as well. We just need to be careful in not exploding the scope of the work and thus delay the work. 

Simo

>> follow clear procedures on how to behave, which services could they 
>> try to reuse over the protocol that is still available and 
>under what 
>> conditions.
>> 
>> WDYT?
>> 
>> Emil
>> 
>> 
>>> Below is the draft charter text for our proposal on 
>combining SIP voice with XMPP IM and 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 voice as well as 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 
>infrastrucure. 
>>>
>>> - 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.
>>> - presence; it should be possible to change the XMPP 
>presence status based on the user's activity in the SIP domain.
>>>
>>> The goal is to rely on existing service infrastructre, and 
>new requirements should be imposed only to the endpoint. 
>>>
>>> Protocol interworking, that is, translation from one 
>protocol to another, is out of scope of this WG.
>>>
>>> Milestones
>>> Feb 2010 Problem statement and use cases submitted to IESG as 
>>> Informational Dec 2010 Specification on combining SIP based 
>voice and XMPP based IM/Presence in a seamless manner 
>submitted to IESG as Proposed Standard.
>>>
>>> -----------------

---

From: <[email-masked]>
Date: Wed, 23 Sep 2009 09:53:05 +0200

>[mailto:[email-masked]] On Behalf Of ext Olle E. Johansson
>Sent: 22 September, 2009 19:44
>To: Peter Saint-Andre
>Cc: [email-masked]
>>>> IMHO those activities will keep the XMPP WG chugging along for a 
>>>> while and the SIP-XMPP work will not receive a lot of 
>attention. If 
>>>> we can move it over to a new, more focused WG then I am in favor, 
>>>> because that will encourage faster progress, I think.
>>>
>> seeing in the implementation and deployment space, then yes 
>we might  
>> be

I wouldn't expect new resources to pop up to complete the draft-saintandre-* documents just by moving that work to another WG (if such was formed), but otherwise I think it makes sense to concentrate this bulk of work together.

Simo

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Sep 2009 14:46:24 +0200

Hey Simo,

[email-masked] wrote:
> As has been pointed out in earlier emails, there is no automatic 
> correlation of SIP and XMPP user id's and thus an AOR 
> [email-masked] may not belong to the same person as the JID 
> [email-masked]. This rules out the possibility of responding to a 
> SIP MESSAGE with an XMPP <message> stanza without some a priori 
> knowledge on Alice's identity in XMPP domain.

I understand why we would not want to rely on an implicit correlation
like for example JID == AOR. However an explicit correlation such as an
XMPP contact header in SIP messages and a SIP URI in the XMPP vcards
would be very helpful. A XMPP+SIP user receiving a call from someone not
on their contact list is likely to wish to add the remote party to their
roster or send them instant messages. Not being able to do so would feel
awkward to the user.

> From an end user's point of view it makes no difference which
> protocol is used. Personally, I would not mind having all my
> messaging (IM's via different service providers, SMS, email etc.)
> visible in a single application view, and let the application hide
> some of the complexity.

Not sure I understand. Does this mean that you expect messages to be
traveling over both SIMPLE and XMPP? If yes, then we definitely need
some priority rules.

Cheers,
Emil

>>>  impossible (e.g. due to a server failure) clients should be able
>>>  to follow clear procedures on how to behave, which services
>>> could they try to reuse over the protocol that is still available
>>> and
>> under what
>>> conditions.
>>> 
>>> WDYT?
>>> 
>>> Emil
>>> 
>>> 
>>>> Regards, Simo
>> 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.
>> 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 infrastrucure.
>>>> 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 
>>>> voice sessions with IM/Presence such that they can be presented
>>>> 
>>>> 
>> to the end
>>>> user in a seamless fashion - presence; it should be possible to
>>>>  change the XMPP
>>>> Milestones Feb 2010 Problem statement and use cases submitted 
>>>> to IESG as Informational Dec 2010 Specification on combining 
>>>> SIP based
>> voice and XMPP based IM/Presence in a seamless manner submitted to 
>> IESG as Proposed Standard.
>>>> ----------------- 
>>>> _______________________________________________ dispatch 
>>>> mailing list [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Sep 2009 17:20:09 -0400

Simo,

It would be a good start to *identify* these issues in whatever is 
produced, and discuss their resolution - even if all that is said is 
that a particular issue is ruled out of scope or unsolved in an initial 
release. I'd just like to have them *considered* rather than not even 
being mentioned.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 24 Sep 2009 08:34:17 +0200

>From: Emil Ivov [mailto:[email-masked]] On Behalf 
>Of ext Emil Ivov
>Sent: 23 September, 2009 15:46
>To: Veikkolainen Simo (Nokia-D/Helsinki)
>Cc: [email-masked]; [email-masked]
>I understand why we would not want to rely on an implicit 
>correlation like for example JID == AOR. However an explicit 
>correlation such as an XMPP contact header in SIP messages and 
>a SIP URI in the XMPP vcards would be very helpful. A XMPP+SIP 
>user receiving a call from someone not on their contact list 
>is likely to wish to add the remote party to their roster or 
>send them instant messages. Not being able to do so would feel 
>awkward to the user.

Yes. Explicit correlation (carrying SIP identities in XMPP or vice versa) is what we proposed in our draft, and we think could indeed be useful.

>
>> From an end user's point of view it makes no difference 
>which protocol 
>> is used. Personally, I would not mind having all my messaging (IM's 
>> via different service providers, SMS, email etc.) visible in 
>a single 
>> application view, and let the application hide some of the 
>complexity.
>
>Not sure I understand. Does this mean that you expect messages 
>to be traveling over both SIMPLE and XMPP? If yes, then we 
>definitely need some priority rules.

What I meant was that from a UI point of view, all the end user needs to see is a contact name and possibility send a message (or call). A lot of the complexity of selecting the actual protocol *could* be hidden by the application. This may not be what all application developers wish, but for example the phonebooks in some mobile devices seem to be going to that direction, combining IM and SMS in one "conversation" view.

So, for example, if a user wants the send an initial message to a contact whose both SIP and XMPP IDs are known, the app could do the selection of protocol, depending on the other user's presence information. However, when responding to a message in a conversation, it probably is better to use the same protocol that was used when sending, unless the client knows that the other client's UI can render the messages in the same conversation view. 

So, I'll I'm saying is we need to carefully consider making normative statements that could potentially limit the application design and usability. 

Simo

>addition  
>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 infrastrucure.
>>>>> sessions with IM/Presence such that they can be presented
>>>>> 
>>>>> 
>>> to the end
>>>>> Milestones Feb 2010 Problem statement and use cases submitted to 
>>>>> IESG as Informational Dec 2010 Specification on combining 
>SIP based
>>>>> _______________________________________________ dispatch mailing 
>>>>> list [email-masked]

---

From: <[email-masked]>
Date: Thu, 24 Sep 2009 08:35:39 +0200

>Sent: 24 September, 2009 00:20
>Cc: [email-masked]; [email-masked]
>It would be a good start to *identify* these issues in 
>whatever is produced, and discuss their resolution - even if 
>all that is said is that a particular issue is ruled out of 
>scope or unsolved in an initial release. I'd just like to have 
>them *considered* rather than not even being mentioned.

Agreed. I also think we cannot just bypass these; they are anyways the practical problems implementors are going to face.

Simo

>> Without addressing each issue separately, I would say we can 
>provide normative statements for some situations, but most 
>likely some issues listed above will have to be left for the 
>implementation to deal with.
>> 
>> As has been pointed out in earlier emails, there is no 
>automatic correlation of SIP and XMPP user id's and thus an 
>AOR [email-masked] may not belong to the same person as the 
>JID [email-masked]. This rules out the possibility of 
>responding to a SIP MESSAGE with an XMPP <message> stanza 
>without some a priori knowledge on Alice's identity in XMPP domain. 
>> 
>which protocol is used. Personally, I would not mind having 
>all my messaging (IM's via different service providers, SMS, 
>email etc.) visible in a single application view, and let the 
>application hide some of the complexity. 
>> 
>> We have only covered some use cases in our document, but I 
>agree we probably need to take a look at other situations as 
>well. We just need to be careful in not exploding the scope of 
>the work and thus delay the work. 
>> 
>> Simo
>>

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 24 Sep 2009 11:50:29 +0200

There is another aspect of text communication that I would like to propose
to bring into this charter.

It is to provide a more "real-timish" text conversational mode, where the
text is sent time-sampled in short chunks during its composition rather than
waiting on user command to send a completed message. The presentation should
then present the chunks consecutively until a delimiter is received. 

We have defined the real-time text mode for transmission with RTP, in RFC
4103, and want of course continue supporting that transport. With RTP it is
realistic to get real real-time transmission, with transmission in 300 ms
intervals. With XMPP, the overead makes it perhaps more realistic to
transmit only once per second, but still get a quite useable real-timish
result, that would be appreciated by the users.

So, I suggest to bring real-timish text transmission of XMPP into this
charter.

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, September 24, 2009 8:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM
and presence

>From: Emil Ivov [mailto:[email-masked]] On Behalf Of ext 
>Emil Ivov
>would be very helpful. A XMPP+SIP user receiving a call from someone 
>not on their contact list is likely to wish to add the remote party to 
>their roster or send them instant messages. Not being able to do so 
>would feel awkward to the user.

Yes. Explicit correlation (carrying SIP identities in XMPP or vice versa) is
what we proposed in our draft, and we think could indeed be useful.

>traveling over both SIMPLE and XMPP? If yes, then we definitely need 

What I meant was that from a UI point of view, all the end user needs to see
is a contact name and possibility send a message (or call). A lot of the
complexity of selecting the actual protocol *could* be hidden by the
application. This may not be what all application developers wish, but for
example the phonebooks in some mobile devices seem to be going to that
direction, combining IM and SMS in one "conversation" view.

So, for example, if a user wants the send an initial message to a contact
whose both SIP and XMPP IDs are known, the app could do the selection of
protocol, depending on the other user's presence information. However, when
responding to a message in a conversation, it probably is better to use the
same protocol that was used when sending, unless the client knows that the
other client's UI can render the messages in the same conversation view. 

So, I'll I'm saying is we need to carefully consider making normative
statements that could potentially limit the application design and
usability. 

Simo

__________ NOD32 4452 (20090924) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: Emil Ivov <[email-masked]>
Date: Thu, 24 Sep 2009 12:07:09 +0200

Hey Gunnar,

I am not sure I understand how this fits the XMPP+SIP work.
Isn't it something that would be better suited by a pure XMPP entity
such as the XMPP WG or xmpp.org? Or do you think that there's some
aspect in this that can only be handled with SIP and another with XMPP?

IIRC, that's one of the features that appear in Google Wave's demos so
maybe there's already some XMPP related work in that direction.

Cheers,
Emil

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Sep 2009 07:52:12 -0600

There are XMPP implementations that transmit character-by-character
text, but no one has ever brought a proposal to standardize this feature
to the XMPP Standards Foundation, and the XSF hasn't sought one out.
That might change in the future with the Wave work.

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 24 Sep 2009 17:10:05 +0300

I support this proposal and will be happy to assist in the work.

--Avshalom

From:
<[email-masked]>
To:
<[email-masked]>
Date:
21/09/2009 03:29 PM
Subject:
[dispatch] Charter proposal on combining SIP voice with XMPP IM and 
presence
Sent by:
[email-masked]

Hello,

Below is the draft charter text for our proposal on combining SIP voice 
with XMPP IM and presence.

Regards,
Simo

-----------------

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 voice as well as 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 infrastrucure. 

experience can be offered to end user. Specifically, solutions are needed 
on 
sessions with IM/Presence such that they can be presented to the end user 
in a seamless fashion

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

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

-----------------

---

From: Schumann Sebastian <[email-masked]>
Date: Thu, 24 Sep 2009 16:27:00 +0200

Hello Everyone

>From SIP operator point of view, I see it very important to think about combined architecture exactly like Simo describes them: (More or less :) mature implementations of SIP and standardized and mature instant messaging/presence where clients exist: XMPP. Both candidates are deployed massively out there, however still separately. I see big Telco operator's not using XMPP for voice in the future as well as Google and other large XMPP deployments considering SIP for their IM services.

>From interworking point of view, I think the efforts should not only go into the direction where several drafts are available (communicate as SIP/XMPP user with XMPP/SIP user) but also the into the direction of merging identities (what Simo describes: it should be possible to change the XMPP presence status based on the user's activity in the SIP domain). It is more a proposal of users using both networks and "merging" their states. If you use, e.g., XMPP for presence, you might want to merge the user's SIP device presence state as an actual XMPP presence state (the phone as one resource, the user being busy when in a call). In other cases, you do not want him to appear online in the XMPP client, if only a SIP hardphone is registered. It is online, but cannot receive any IM communication...

I think a lot of use cases and scenarios can be created, even more will arise in the future, as both infrastructures are growing. Yet, I see both growing separately and in different "domains" (internet vs. Telco world).

I would like to participate in moving the consolidation forward, hence I second the proposal!

Best regards
Sebastian

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Avshalom Houri
Sent: Thursday, 24. September 2009 16:10
To: [email-masked]; [email-masked]
Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence

--Avshalom

From:   <[email-masked]>
To:     <[email-masked]>
Date:   21/09/2009 03:29 PM
Subject:        [dispatch] Charter proposal on combining SIP voice with XMPP IM and        presence
Sent by:        [email-masked]

________________________________

Hello,

Regards,
Simo

-----------------

Milestones

-----------------

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 24 Sep 2009 17:51:25 +0300

Quite agree with you. Seems that there should be integration also in the 
back end and not only on the clients.
The use cases and the requirements work here will determine the direction 
of this work.

--Avshalom

From:
Schumann Sebastian <[email-masked]>
To:
Avshalom Houri/Haifa/IBM@IBMIL, "[email-masked]'" 
<[email-masked]>, "[email-masked]'" <[email-masked]>
Date:
24/09/2009 05:27 PM
Subject:
RE: [dispatch] Charter proposal on combining SIP voice with XMPP IM and 
presence

Hello Everyone
 
>From SIP operator point of view, I see it very important to think about 
combined architecture exactly like Simo describes them: (More or less :) 
mature implementations of SIP and standardized and mature instant 
messaging/presence where clients exist: XMPP. Both candidates are deployed 
massively out there, however still separately. I see big Telco operator's 
not using XMPP for voice in the future as well as Google and other large 
XMPP deployments considering SIP for their IM services.
 
>From interworking point of view, I think the efforts should not only go 
into the direction where several drafts are available (communicate as 
SIP/XMPP user with XMPP/SIP user) but also the into the direction of 
merging identities (what Simo describes: it should be possible to change 
the XMPP presence status based on the user's activity in the SIP domain). 
It is more a proposal of users using both networks and "merging" their 
states. If you use, e.g., XMPP for presence, you might want to merge the 
user's SIP device presence state as an actual XMPP presence state (the 
phone as one resource, the user being busy when in a call). In other 
cases, you do not want him to appear online in the XMPP client, if only a 
SIP hardphone is registered. It is online, but cannot receive any IM 
communication...
 
I think a lot of use cases and scenarios can be created, even more will 
arise in the future, as both infrastructures are growing. Yet, I see both 
growing separately and in different "domains" (internet vs. Telco world).
 
I would like to participate in moving the consolidation forward, hence I 
second the proposal!
 
Best regards
Sebastian

From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Avshalom Houri
Sent: Thursday, 24. September 2009 16:10
To: [email-masked]; [email-masked]
Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP 
IM and presence

--Avshalom

From: 

Hello,

Regards,
Simo

-----------------

Milestones

-----------------

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 24 Sep 2009 20:07:19 +0200

Emil,
The link with other real-time media in the SIP part of the call makes it
valid to also discuss the real-time characteristics of the text part.

It may look strange to arrange real-time communication in video and audio,
but leave the text part in message-wise performance level. Especially now,
when real-time text is appearing as a performance enhancement in various
services as you have noticed yourself.

However, you are right in principle, real-time is a general presentation
function that could be defined in XMPP. 
So, it could be of interest to define this presentation feature in XMPP, and
resolve any interoperability and media offer/answer issues with RFC 4103 in
the new group.

For example, how would you express in SDP that you offer RFC 4013 in RTP and
real-timish mode of XMPP as equal alternatives to select from, in contrast
to offering RFC 4103 as the main real-time text medium in the session, and
message-based XMPP for side-bar discussion. Such aspects would need to be
defined under the new charter.

Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: Emil Ivov [mailto:[email-masked]] On Behalf Of Emil Ivov
Sent: Thursday, September 24, 2009 12:07 PM
To: Gunnar Hellstrom
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM
and presence

Hey Gunnar,

I am not sure I understand how this fits the XMPP+SIP work.
Isn't it something that would be better suited by a pure XMPP entity such as
the XMPP WG or xmpp.org? Or do you think that there's some aspect in this
that can only be handled with SIP and another with XMPP?

IIRC, that's one of the features that appear in Google Wave's demos so maybe
there's already some XMPP related work in that direction.

Cheers,
Emil

Gunnar Hellstrom wrote:
> There is another aspect of text communication that I would like to 
> propose to bring into this charter.
> 
> It is to provide a more "real-timish" text conversational mode, where 
> the text is sent time-sampled in short chunks during its composition 
> rather than waiting on user command to send a completed message. The 
> presentation should then present the chunks consecutively until a
delimiter is received.
> 
> We have defined the real-time text mode for transmission with RTP, in 
> RFC 4103, and want of course continue supporting that transport. With 
> RTP it is realistic to get real real-time transmission, with 
> transmission in 300 ms intervals. With XMPP, the overead makes it 
> perhaps more realistic to transmit only once per second, but still get 
> a quite useable real-timish result, that would be appreciated by the
users.
>> like for example JID == AOR. However an explicit correlation such as 
>> an XMPP contact header in SIP messages and a SIP URI in the XMPP 
>> vcards would be very helpful. A XMPP+SIP user receiving a call from 
>> someone not on their contact list is likely to wish to add the remote 
>> party to their roster or send them instant messages. Not being able 
>> to do so would feel awkward to the user.
> 
> Yes. Explicit correlation (carrying SIP identities in XMPP or vice 
> versa) is what we proposed in our draft, and we think could indeed be
useful.
> What I meant was that from a UI point of view, all the end user needs 
> to see is a contact name and possibility send a message (or call). A 
> lot of the complexity of selecting the actual protocol *could* be 
> hidden by the application. This may not be what all application 
> developers wish, but for example the phonebooks in some mobile devices 
> seem to be going to that direction, combining IM and SMS in one
"conversation" view.
> 
> So, for example, if a user wants the send an initial message to a 
> contact whose both SIP and XMPP IDs are known, the app could do the 
> selection of protocol, depending on the other user's presence 
> information. However, when responding to a message in a conversation, 
> it probably is better to use the same protocol that was used when 
> sending, unless the client knows that the other client's UI can render the
messages in the same conversation view.

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com