Subject: [dispatch] New topic proposal for DISPATCH

From: <[email-masked]>
Date: Fri, 4 Sep 2009 14:09:04 +0200

Hi,

We would like to propose a new DISPATCH topic on how SIP and XMPP can be used together in a complementary fashion.

We have been working on a solution which combines SIP based VoIP and XMPP based IM and Presence. The requirements and a proposed solution is outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01.

The motivation for this work comes from experience which shows that most standards based VoIP deployments use SIP. At the same time, the Extensible Messaging and Presence Protocol (XMPP) is widely used in instant messaging and presence services. An interesting scenario arises when a SIP based voice (and video) service is combined together with an XMPP based instant messaging and presence service.

Note that the goal in this work is not SIP-XMPP protocol translation, but to define protocol extensions and best practises such that SIP based VoIP and XMPP based IM and presence could be seamlessly combined and offered to the end user. For rapid deployment, we assume no changes in the server infrastructure, and instead impose new requirements and protocol extensions only to the endpoints.

We would like to get some discussion going on the use case itself as well as on the solution. Also, we would like to hear you thoughts on DISPATCH or a new "dispatched" mini-WG as the home for such work.

Exact charter proposal and problem statemen is to follow.

Regards,
Simo and Markus

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 4 Sep 2009 14:14:16 +0200

4 sep 2009 kl. 14.09 skrev <[email-masked]>:

> Hi,
>
> We would like to propose a new DISPATCH topic on how SIP and XMPP  
> can be used together in a complementary fashion.
>
> We have been working on a solution which combines SIP based VoIP and  
> XMPP based IM and Presence. The requirements and a proposed solution  
> is outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 
> .
>
> The motivation for this work comes from experience which shows that  
> most standards based VoIP deployments use SIP. At the same time, the  
> Extensible Messaging and Presence Protocol (XMPP) is widely used in  
> instant messaging and presence services. An interesting scenario  
> arises when a SIP based voice (and video) service is combined  
> together with an XMPP based instant messaging and presence service.
>
> Note that the goal in this work is not SIP-XMPP protocol  
> translation, but to define protocol extensions and best practises  
> such that SIP based VoIP and XMPP based IM and presence could be  
> seamlessly combined and offered to the end user. For rapid  
> deployment, we assume no changes in the server infrastructure, and  
> instead impose new requirements and protocol extensions only to the  
> endpoints.
>

The XMPP forum has a few drafts on this, so we should coordinate with  
them. There are a lot of issues to sort out. We had a workshop on this  
topic with Asterisk, Kamailio and a few other products at Inria in  
France and saw a lot of issues to sort out both in regards to IM and  
presence.

For Asterisk we have both SIP and XMPP telephony, for Kamailio we have  
modules that try to bridge presence updates and IM.

I think it's hard to separate protocol translation. It's all about  
making it work together seamlessly.

/O

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 4 Sep 2009 08:41:58 -0700

I would like to second such work, but a far deeper look under the hood is necessary, so we don't do another Elbonia project.
http://dilbert.com/strips/comic/2009-09-01/

Here are some not very mature thoughts on the scope of the work.
The most interesting, ROI estimate and REST architecture support are at the end.

Servers

Fundamentally, we need a registrar, a proxy and a presence server: Three in total

 *   What will be the duplication of servers and where specifically?
 *   How does the SIP registrar communicate with the XMPP server(s)?
 *   What may be the routing protocol(s) inside a SIP+XMMP network? Think of IMS as a stressing use case.

User Agents

 *   Same as with servers: How many and what protocol RFCs are there in the combination?
 *   Which of the "services" can be placed in the applications in the endpoints or in the network application protocols, such as SIP and XMPP. This is the topic on infrastructure vs. endpoint applications.

Application Protocol Stacks

 *   How many protocol stacks does this involve and more to the point, how many RFCs?
 *   For SIP alone, see http://rfc3261.net/. What will be the total combined RFC count?

NAT Traversal

 *   Will STUN/TURN/ICE work the same for SIP and for XMPP?

Return on Investment (ROI): Cost and effort by developers. More network infrastructure, not even counting B2B NEs.

 *   What is the additional time/money required for developers that know SIP to also learn XMPP and vice versa? This is all about return on investment.

Support for a REST-full architecture

The WWW has a REST architecture was formulated in 2000, after the emergence of SIP and XMMP.  As a result of its architecture, the WWW has had a transformational effect on the following (this is not a complete list). Some SIP work recommends already recommends REST, such as in RFC 4240 and in http://tools.ietf.org/html/draft-griffin-bliss-rest-00

 *   Web applications from mail to office apps
 *   Internet applications previously served by dedicated network applications protocols
 *   Many other industries, from banking to newsprint to travel. And Oh, social networks, they also have registrars...

Now please keep in mind the WWW architecture uses basically only 3 components*: The URI for addressing, HTTP for transport and HTML for data rendering, augmented by some other languages (XML) and namespaces. Can we benefit something from the WWW architecture? If yes what specifically?

Heresy: If the web developers could use HTTP only, what other application level protocols do we really need except RTP/UDP?
This includes in my mind TLS and DTLS for secure transport or even better IMO: HIP for many reasons.

* T.V. Raman: "Toward 2W, Beyond Web 2.0", Communications of the ACM, February 2009

Many or most of these points may be moot or make no sense, but maybe should be cleared up, in case there are more naive people like me that may be interested.

My strict personal 2 cents.

FRANK comments are most welcome.

Henry

On 9/4/09 7:09 AM, "[email-masked]" <[email-masked]> wrote:

Hi,

We have been working on a solution which combines SIP based VoIP and XMPP based IM and Presence. The requirements and a proposed solution is outlined in http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 <http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> .

Regards,
Simo and Markus

---

From: <[email-masked]>
Date: Wed, 9 Sep 2009 10:09:51 +0200

>-----Original Message-----
>From: ext Olle E. Johansson [mailto:[email-masked]] 
>Sent: 04 September, 2009 15:14
>To: Veikkolainen Simo (Nokia-D/Helsinki)
>Cc: [email-masked]; Mary Barnes; Camarillo Gonzalo; Isomaki 
>Markus (Nokia-CIC/Espoo); Saint-Andre Peter
>Subject: Re: [dispatch] New topic proposal for DISPATCH
>
>
>> We would like to propose a new DISPATCH topic on how SIP and 
>XMPP can 
>> be used together in a complementary fashion.
>>
>> is outlined in 
>> http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01
>> .
>>
>> arises when a SIP based voice (and video) service is 
>combined together 
>> with an XMPP based instant messaging and presence service.
>>
>translation, 
>> but to define protocol extensions and best practises such that SIP 
>> based VoIP and XMPP based IM and presence could be 
>seamlessly combined 
>> and offered to the end user. For rapid deployment, we assume no 
>> changes in the server infrastructure, and instead impose new 
>> requirements and protocol extensions only to the endpoints.
>>
>The XMPP forum has a few drafts on this, so we should 
>coordinate with them. There are a lot of issues to sort out. 
>We had a workshop on this topic with Asterisk, Kamailio and a 
>few other products at Inria in France and saw a lot of issues 
>to sort out both in regards to IM and presence.

We have presented the above draft in the XMPP WG BoF in San Francisco earlier this year. I agree both the IETF and the XSF would need to be aware, but preferably there should be one place where the concepting happens. We thought DISPATCH might be the right place for this. 

>For Asterisk we have both SIP and XMPP telephony, for Kamailio 
>we have modules that try to bridge presence updates and IM.
>
>I think it's hard to separate protocol translation. It's all 
>about making it work together seamlessly.

Our idea was to specify a solution which admittedly leaves some aspects untouched, but - on the other hand - would offer a solution to an issue we see is relevant and which would be rapidly deployable. There are already quite a few drafts available on protocol interworking (draft-saintandre-sip-xmpp-*).

Simo

---

From: <[email-masked]>
Date: Fri, 11 Sep 2009 15:11:20 +0200

Hi Henry,

Thanks for your feedback :) Let me answer to the excellent points you raise.

First of all, I would encourage you and everyone to carefully read the Introduction chapter of the draft (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01) to be clear on what the proposal is about. That is, we are not trying to boil the ocean and define all possible ways how SIP and XMPP infrastructures could be combined, but instead try to define a minimalistic approach whereby a client can use both SIP and XMPP in an integrated manner WITHOUT requiring ANY changes on the servers that are already deployed.

See further comments below with [Markus]:

________________________________
From: ext Henry Sinnreich [mailto:[email-masked]]
Sent: 04 September, 2009 18:42
To: Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]; [email-masked]; [email-masked]
Cc: Isomaki Markus (Nokia-CIC/Espoo); Olle E. Johansson
Subject: Re: [dispatch] New topic proposal for DISPATCH

Servers

[Markus] Our starting point is that we already have quite many SIP VoIP deployments out there, as long as quite many XMPP presence & IM deployments. So, the servers you mention already exist. If one now wants to develop a client that does VoIP, IM and presence together, it should be possible to utilize these existing infrastrcutures and not have to wait for new ones to be deployed (as for instance we have waited quite many years for SIMPLE-based Presence servers to get deployed but compared to XMPP there's very little in use). The idea is to define a couple of E2E (as in nothing that SIP proxies or XMPP servers would have to support) protocol extensions which would allow the client to nicely combine SIP VoIP and XMPP presence & IM.

There is no need for SIP and XMPP servers to know about each other or route protocol messages between each other. All the logic is put into the endpoints. No need to worry about IMS either, except that in theory the client can use IMS for its VoIP service (similar to any other SIP infra).

User Agents

[Markus] Just take any current SIP VoIP UA implementation, XMPP client implementation and glue them together and you're already pretty far. Add a couple of extensions as proposed and it's done. From there onwards you have a pretty powerful machinery to add applications by using SIP session setup and XMPP message delivery capabilities.

[Markus] All what we expect is already pretty widely supported and even available as open source: basic SIP VoIP and XMPP IM and presence is enough to start with.

NAT Traversal

 [Markus] In our proposal SIP would be used for setting up voice & video sessions. So, you would need NAT traversal for that. How that's done is outside the scope but either B2BUA or ICE based mechanisms would work as far as they work in general. For XMPP we would not need to worry about NAT traversal beyond how its done in that protocol by default. For a client there is a caveat that it has to keepalive the TCP connections with BOTH SIP and XMPP servers so it would be recommended to synchronize those (send them at the same time) for instance in a battery powered device.

[Markus] This is a problem for sure, even more so for the people writing standard specs than code :)  Hopefully the developer would just have add a couple of simple extensions to existing SIP and XMPP implementations.

[Markus] Personally I agree that REST+HTTP+Javascript is a superior toolset compared to SIP, XMPP, IMAP and so on to develop many applications. However, there are still plenty of SIP based VoIP and XMPP based IM and presence deployments out there and I don't expect the web apps to replace all of them in the near future :)

Henry

Hi,

Regards,
Simo and Markus

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 11 Sep 2009 10:41:02 -0700

Hi Markus,

Thanks for your thoughtful reply and I agree there are some scenarios where it makes sense.
More important, doing this in the endpoints is the right approach IMO and as you know, I will always defend the Internet end-to-end principle :-)

This distributed approach is also IMO a good answer to the Interdomain Scaling problem for IM
( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I have copied one of its authors here.

This raises the questions:

 1.  Why stop at SIP and XMPP, and not add other popular IM protocols, as is already done by quite a few products in the market?
 2.  Can your approach be generalized in a more generic way?

If endpoints are accommodating several IM protocols, an IETF, Dispatch recommended GENERIC approach would make many people feel more comfortable about it. Your I-D could be used as a tested example for a generic approach.

Ranting on preferring endpoint applications to more application protocols

I still believe creative application developers face the choice of either inventing new applications or dedicating their time to learning application protocols and they cannot do both. Learning and following both SIP and XMPP to write and update code is quite a challenge.
Is there a better way?
For this reason, one single application protocol for IM and voice is enough.
Proof: Almost all the applications that make people buy smart phones, use online office apps and enterprise apps run on HTTP(S) and their application developers don't have to worry about knowing how HTTP works. As a result, HTTP has been also used to even carry streaming media, web conferencing and IM. Just to avoid spending a lifetime to learn and follow application protocols. But HTTP based apps dominate the application space. This is however for another discussion elsewhere.

My strictly personal 2 cents.

Thanks again,

Henry

On 9/11/09 8:11 AM, "[email-masked]" <[email-masked]> wrote:

Hi Henry,

First of all, I would encourage you and everyone to carefully read the Introduction chapter of the draft (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 <http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> ) to be clear on what the proposal is about. That is, we are not trying to boil the ocean and define all possible ways how SIP and XMPP infrastructures could be combined, but instead try to define a minimalistic approach whereby a client can use both SIP and XMPP in an integrated manner WITHOUT requiring ANY changes on the servers that are already deployed.

Servers

User  Agents

NAT  Traversal

Henry

Hi,

Regards,
Simo and  Markus

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Sep 2009 15:55:53 -0400

I agree that there are pragmatic reasons to pursue the 
coordination/coexistence of sip and xmpp. And pushing responsibility to 
the endpoints remains desirable.

One thing that remains of concern to me in such work is that we end up 
with disjoint address spaces without any straightforward way to 
correlate them. So if I want a single "session" involving both voice via 
SIP and IM via xmpp, then I have great difficulty in discovering URIs 
for the "subordinate" session that correlate with those for the 
"primary" session. (No pejorative intended here - one or the other must 
go first.)

Somehow this problem needs to be resolved.

	Thanks,
	Paul

Henry Sinnreich wrote:
> More important, doing this in the endpoints is the right approach IMO 
> and as you know, I will always defend the Internet end-to-end principle :-)
> 
>    1. Why stop at SIP and XMPP, and not add other popular IM protocols,
>       as is already done by quite a few products in the market?
> If endpoints are accommodating several IM protocols, an IETF, Dispatch 
> recommended GENERIC approach would make many people feel more 
> comfortable about it. Your I-D could be used as a tested example for a 
> generic approach.
> 
> I still believe creative application developers face the choice of 
> either inventing new applications or dedicating their time to learning 
> application protocols and they cannot do both. Learning and following 
> both SIP and XMPP to write and update code is quite a challenge.
> Is there a better way?
> Proof: Almost all the applications that make people buy smart phones, 
> use online office apps and enterprise apps run on HTTP(S) and their 
> application developers don’t have to worry about knowing how HTTP works. 
> As a result, HTTP has been also used to even carry streaming media, web 
> conferencing and IM. Just to avoid spending a lifetime to learn and 
> follow application protocols. But HTTP based apps dominate the 
> application space. This is however for another discussion elsewhere.
> 
>     First of all, I would encourage you and everyone to carefully read
>     the Introduction chapter of the draft
>     (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01
>     <http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01>
>     ) to be clear on what the proposal is about. That is, we are not
>     trying to boil the ocean and define all possible ways how SIP and
>     XMPP infrastructures could be combined, but instead try to define a
>     minimalistic approach whereby a client can use both SIP and XMPP in
>     an integrated manner WITHOUT requiring ANY changes on the servers
>     that are already deployed.
> 
>         ------------------------------------------------------------------------
>         *From:* ext Henry Sinnreich  [mailto:[email-masked]]
>         *Sent:* 04 September, 2009  18:42
>         *To:* Veikkolainen Simo (Nokia-D/Helsinki); [email-masked];
>          [email-masked]; [email-masked]
>         *Cc:* Isomaki  Markus (Nokia-CIC/Espoo); Olle E. Johansson
>         *Subject:* Re: [dispatch]  New topic proposal for DISPATCH
> 
>          
>         I would like to second such work, but a far deeper  look under
>         the hood is necessary, so we don’t do another Elbonia  project.
>             * What may be the routing protocol(s) inside a  SIP+XMMP
>               network? Think of IMS as a stressing use  case.
> 
> 
>         [Markus] Our starting point is that we already have quite  many
>         SIP VoIP deployments out there, as long as quite many XMPP
>         presence &  IM deployments. So, the servers you mention already
>         exist. If one now  wants to develop a client that does VoIP, IM
>         and presence together, it should  be possible to utilize these
>         existing infrastrcutures and not have to wait for  new ones to
>         be deployed (as for instance we have waited quite many years for
>          SIMPLE-based Presence servers to get deployed but compared to
>         XMPP there's  very little in use). The idea is to define a
>         couple of E2E (as in  nothing that SIP proxies or XMPP servers
>         would have to support) protocol  extensions which would allow
>         the client to nicely combine SIP VoIP and XMPP  presence & IM.
> 
>          
>          
>         There is no need for SIP and XMPP servers to know about  each
>         other or route protocol messages between each other. All the
>         logic is put  into the endpoints. No need to worry about IMS
>         either, except  that in theory the client can use IMS for its
>         VoIP service  (similar to any other SIP  infra).
> 
> 
>         User  Agents
> 
>             * Which of the “services” can be placed in the  applications
>               in the endpoints or in the network application protocols,
>               such  as SIP and XMPP. This is the topic on infrastructure
>               vs. endpoint  applications.
> 
> 
>         [Markus] Just take any current SIP VoIP  UA implementation, XMPP
>         client implementation and glue them together  and you're already
>         pretty far. Add a couple of extensions as proposed and it's
>          done. From there onwards you have a pretty powerful machinery
>         to add  applications by using SIP session setup and XMPP message
>         delivery  capabilities.
> 
> 
>         [Markus] All what we expect is already pretty widely  supported
>         and even available as open source: basic SIP VoIP and XMPP IM
>         and  presence is enough to start with.   
> 
> 
>         NAT  Traversal
> 
>         [Markus] In our proposal SIP would be used for setting up  voice
>         & video sessions. So, you would need NAT traversal for that. How
>          that's done is outside the scope but either B2BUA or ICE based
>         mechanisms  would work as far as they work in general. For XMPP
>         we would not need to worry  about NAT traversal beyond how its
>         done in that protocol by default. For a  client there is a
>         caveat that it has to keepalive the TCP connections with  BOTH
>         SIP and XMPP servers so it would be recommended to synchronize
>         those  (send them at the same time) for instance in a battery
>         powered  device.
> 
> 
>         Return  on Investment (ROI): Cost and effort by developers. More
>         network  infrastructure, not even counting B2B NEs.
> 
>             * What is the additional time/money required for  developers
>               that know SIP to also learn XMPP and vice versa? This is
>               all  about return on investment.
> 
> 
>         [Markus] This is a problem for sure, even more so  for the
>         people writing standard specs than code :)  Hopefully the
>          developer would just have add a couple of simple extensions to
>         existing  SIP and XMPP implementations.
> 
> 
>         The WWW has a REST architecture was formulated in 2000,  after
>         the emergence of SIP and XMMP.  As a result of its architecture,
>          the WWW has had a transformational effect on the following
>         (this is not a  complete list). Some SIP work recommends already
>         recommends REST, such as in  RFC 4240 and in
>         http://tools.ietf.org/html/draft-griffin-bliss-rest-00
> 
>             * Many other industries, from banking to newsprint to
>                travel. And Oh, social networks, they also have
>                registrars...
> 
> 
> 
>         Now please keep in mind the WWW architecture uses basically
>          only 3 components*: The URI for addressing, HTTP for transport
>         and HTML for  data rendering, augmented by some other languages
>         (XML) and namespaces. Can we  benefit something from the WWW
>         architecture? If yes what  specifically?
> 
>         Heresy: If the web developers could use HTTP only, what  other
>         application level protocols do we really need except RTP/UDP?
>         [Markus] Personally I agree that REST+HTTP+Javascript is a
>         superior  toolset compared to SIP, XMPP, IMAP and so on to
>         develop many applications.  However, there are still plenty of
>         SIP based VoIP and XMPP based IM and  presence deployments out
>         there and I don't expect the web apps to replace all  of them in
>         the near future :)
> 
>          
>         * T.V. Raman: “Toward 2W,  Beyond Web 2.0”, Communications of
>         the ACM, February 2009
> 
>         Many or most  of these points may be moot or make no sense, but
>         maybe should be cleared up,  in case there are more naive people
>         like me that may be interested.
> 
>             We would like to propose a new DISPATCH topic on  how SIP
>             and XMPP can be used together in a complementary  fashion.
>              
>             We have been working on a solution which combines SIP  based
>             VoIP and XMPP based IM and Presence. The requirements and a
>             proposed  solution is outlined in
>             _http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01_
>              <http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01>
>              .
>              
>             The motivation for this work comes from experience which
>              shows that most standards based VoIP deployments use SIP.
>             At the same time,  the Extensible Messaging and Presence
>             Protocol (XMPP) is widely used in  instant messaging and
>             presence services. An interesting scenario arises when  a
>             SIP based voice (and video) service is combined together
>             translation, but to define  protocol extensions and best
>             practises such that SIP based VoIP and XMPP  based IM and
>             presence could be seamlessly combined and offered to the end
>              user. For rapid deployment, we assume no changes in the
>             server  infrastructure, and instead impose new requirements
>             and protocol extensions  only to the endpoints.
>              
>             We would like to get some discussion  going on the use case
>             itself as well as on the solution. Also, we would like  to
>             hear you thoughts on DISPATCH or a new "dispatched" mini-WG
>             as the home  for such work.
>              
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Avshalom Houri <[email-masked]>
Date: Mon, 14 Sep 2009 20:36:10 +0300

I think that this draft is an important start for an important work item 
that the IETF should do.

--Avshalom

From:
Henry Sinnreich <[email-masked]>
To:
"[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
Cc:
Avshalom Houri/Haifa/IBM@IBMIL
Date:
11/09/2009 08:41 PM
Subject:
Re: [dispatch] New topic proposal for DISPATCH

Hi Markus,

Thanks for your thoughtful reply and I agree there are some scenarios 
where it makes sense.
More important, doing this in the endpoints is the right approach IMO and 
as you know, I will always defend the Internet end-to-end principle :-)

This distributed approach is also IMO a good answer to the Interdomain 
Scaling problem for IM 
( I-D.draft-ietf-simple-interdomain-scaling-analysis) and I have copied 
one of its authors here.

If endpoints are accommodating several IM protocols, an IETF, Dispatch 
recommended GENERIC approach would make many people feel more comfortable 
about it. Your I-D could be used as a tested example for a generic 
approach.

I still believe creative application developers face the choice of either 
inventing new applications or dedicating their time to learning 
application protocols and they cannot do both. Learning and following both 
SIP and XMPP to write and update code is quite a challenge. 
Is there a better way? 
For this reason, one single application protocol for IM and voice is 
enough.
Proof: Almost all the applications that make people buy smart phones, use 
online office apps and enterprise apps run on HTTP(S) and their 
application developers don?t have to worry about knowing how HTTP works. 
As a result, HTTP has been also used to even carry streaming media, web 
conferencing and IM. Just to avoid spending a lifetime to learn and follow 
application protocols. But HTTP based apps dominate the application space. 
This is however for another discussion elsewhere. 

Thanks again,

Henry 

On 9/11/09 8:11 AM, "[email-masked]" <[email-masked]> 
wrote:

Hi Henry,

Thanks for your feedback :) Let me answer to the excellent points you 
raise.

First of all, I would encourage you and everyone to carefully read the 
Introduction chapter of the draft (
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 <
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> ) to be 
clear on what the proposal is about. That is, we are not trying to boil 
the ocean and define all possible ways how SIP and XMPP infrastructures 
could be combined, but instead try to define a minimalistic approach 
whereby a client can use both SIP and XMPP in an integrated manner WITHOUT 
requiring ANY changes on the servers that are already deployed.

 
To: Veikkolainen Simo (Nokia-D/Helsinki); [email-masked];  

I would like to second such work, but a far deeper  look under the hood is 
necessary, so we don?t do another Elbonia  project.
http://dilbert.com/strips/comic/2009-09-01/

Here  are some not very mature thoughts on the scope of the work. 
The most  interesting, ROI estimate and REST architecture support are at 
the  end.

Servers

Fundamentally, we need a registrar, a proxy and a  presence server: Three 
in total

What will be the duplication of servers and where  specifically? 
How does the SIP registrar communicate with the XMPP  server(s)? 
What may be the routing protocol(s) inside a  SIP+XMMP network? Think of 
IMS as a stressing use  case.

[Markus] Our starting point is that we already have quite  many SIP VoIP 
deployments out there, as long as quite many XMPP presence &  IM 
deployments. So, the servers you mention already exist. If one now  wants 
to develop a client that does VoIP, IM and presence together, it should be 
possible to utilize these existing infrastrcutures and not have to wait 
for  new ones to be deployed (as for instance we have waited quite many 
years for  SIMPLE-based Presence servers to get deployed but compared to 
XMPP there's  very little in use). The idea is to define a couple of E2E 
(as in  nothing that SIP proxies or XMPP servers would have to support) 
protocol  extensions which would allow the client to nicely combine SIP 
VoIP and XMPP  presence & IM. 

There is no need for SIP and XMPP servers to know about  each other or 
route protocol messages between each other. All the logic is put  into the 
endpoints. No need to worry about IMS either, except  that in theory the 
client can use IMS for its VoIP service  (similar to any other SIP infra). 

User  Agents

Same as with servers: How many and what protocol  RFCs are there in the 
combination? 
Which of the ?services? can be placed in the  applications in the 
endpoints or in the network application protocols, such  as SIP and XMPP. 
This is the topic on infrastructure vs. endpoint  applications.

[Markus] Just take any current SIP VoIP  UA implementation, XMPP client 
implementation and glue them together  and you're already pretty far. Add 
a couple of extensions as proposed and it's  done. From there onwards you 
have a pretty powerful machinery to add  applications by using SIP session 
setup and XMPP message delivery  capabilities. 

How many protocol stacks does this involve and more  to the point, how 
many RFCs? 
For SIP alone, see http://rfc3261.net/. What will be the total  combined 
RFC count?

[Markus] All what we expect is already pretty widely  supported and even 
available as open source: basic SIP VoIP and XMPP IM and  presence is 
enough to start with.   

NAT  Traversal

Will STUN/TURN/ICE work the same for SIP and for  XMPP?

[Markus] In our proposal SIP would be used for setting up  voice & video 
sessions. So, you would need NAT traversal for that. How  that's done is 
outside the scope but either B2BUA or ICE based mechanisms  would work as 
far as they work in general. For XMPP we would not need to worry  about 
NAT traversal beyond how its done in that protocol by default. For a 
client there is a caveat that it has to keepalive the TCP connections with 
 BOTH SIP and XMPP servers so it would be recommended to synchronize those 
 (send them at the same time) for instance in a battery powered  device.

Return  on Investment (ROI): Cost and effort by developers. More network 
infrastructure, not even counting B2B NEs.

What is the additional time/money required for  developers that know SIP 
to also learn XMPP and vice versa? This is all  about return on 
investment.

[Markus] This is a problem for sure, even more so  for the people writing 
standard specs than code :)  Hopefully the  developer would just have add 
a couple of simple extensions to existing  SIP and XMPP implementations. 

The WWW has a REST architecture was formulated in 2000,  after the 
emergence of SIP and XMMP.  As a result of its architecture,  the WWW has 
had a transformational effect on the following (this is not a  complete 
list). Some SIP work recommends already recommends REST, such as in  RFC 
4240 and in http://tools.ietf.org/html/draft-griffin-bliss-rest-00

Web applications from mail to office apps   
Internet applications previously served by dedicated  network applications 
protocols 
Many other industries, from banking to newsprint to  travel. And Oh, 
social networks, they also have  registrars...

Now please keep in mind the WWW architecture uses basically  only 3 
components*: The URI for addressing, HTTP for transport and HTML for  data 
rendering, augmented by some other languages (XML) and namespaces. Can we 
benefit something from the WWW architecture? If yes what  specifically?

Heresy: If the web developers could use HTTP only, what  other application 
level protocols do we really need except RTP/UDP?
This  includes in my mind TLS and DTLS for secure transport or even better 
IMO: HIP  for many reasons.

[Markus] Personally I agree that REST+HTTP+Javascript is a superior 
toolset compared to SIP, XMPP, IMAP and so on to develop many 
applications.  However, there are still plenty of SIP based VoIP and XMPP 
based IM and  presence deployments out there and I don't expect the web 
apps to replace all  of them in the near future :)

* T.V. Raman: ?Toward 2W,  Beyond Web 2.0?, Communications of the ACM, 
February 2009

Many or most  of these points may be moot or make no sense, but maybe 
should be cleared up,  in case there are more naive people like me that 
may be interested.

Henry

On 9/4/09 7:09 AM, "[email-masked]" <
[email-masked]>  wrote:

Hi,
 
We would like to propose a new DISPATCH topic on  how SIP and XMPP can be 
used together in a complementary  fashion.
 
We have been working on a solution which combines SIP  based VoIP and XMPP 
based IM and Presence. The requirements and a proposed  solution is 
outlined in 
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01  <
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01>  .
 
The motivation for this work comes from experience which  shows that most 
standards based VoIP deployments use SIP. At the same time,  the 
Extensible Messaging and Presence Protocol (XMPP) is widely used in 
instant messaging and presence services. An interesting scenario arises 
when  a SIP based voice (and video) service is combined together with an 
XMPP  based instant messaging and presence service. 
 
Note that the  goal in this work is not SIP-XMPP protocol translation, but 
to define  protocol extensions and best practises such that SIP based VoIP 
and XMPP  based IM and presence could be seamlessly combined and offered 
to the end  user. For rapid deployment, we assume no changes in the server 
 infrastructure, and instead impose new requirements and protocol 
extensions  only to the endpoints.
 
We would like to get some discussion  going on the use case itself as well 
as on the solution. Also, we would like  to hear you thoughts on DISPATCH 
or a new "dispatched" mini-WG as the home  for such work.

Regards,
Simo and  Markus

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Sep 2009 11:42:36 -0600

>       as is already done by quite a few products in the market?

Because the IETF is a standards organization and it't not our job to
define hackish gateways to things like MySpaceIM? If those people want
to use standardized technologies, it's quite easy for them to do so.

Peter

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

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 14 Sep 2009 12:50:33 -0700

On 9/14/09 12:42 PM, "Peter Saint-Andre" <[email-masked]> wrote:

>define hackish gateways to things like MySpaceIM?

It's in the eye of the beholder what is a hack, a successful innovation or a future standard, de facto or from a standards organization. Presence and IM started out as proprietary systems long time before standards emerged and unless I am mistaken, proprietary Presence and IM are still dominant or at least significant in the market. Does anyone have numbers on this?

Today's "hack" may be the subject of tomorrow's standards.

Henry

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 15 Sep 2009 07:42:23 -0500

Re: [dispatch] New topic proposal for DISPATCHHi, Henry,

I don't disagree with your note below. I understood Peter's concern to be that interworking with a proprietary protocol in an SDO is problematic because the protocol we're interworking with can change at any time. 

There were certainly plenty of proprietary e-mail protocols when SMTP was produced. My understanding (and I wasn't there) was that we defined interworking with X.400, and encouraged people with proprietary protocols to develop interworking with either SMTP directly, or with X.400 (which we knew how to interwork with SMTP.

That's what I understood Peter to be proposing. Sorry if I misunderstand, of course.

Spencer
  ----- Original Message ----- 
  From: Henry Sinnreich 
  To: Peter Saint-Andre 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Monday, September 14, 2009 2:50 PM
  Subject: Re: [dispatch] New topic proposal for DISPATCH

    Henry

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

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 15 Sep 2009 05:49:50 -0700

Spencer,

Our understanding seems to agree.
Sure, this is worth a longer discussion, but at some other time and place.

Henry

On 9/15/09 7:42 AM, "Spencer Dawkins" <[email-masked]> wrote:

Hi, Henry,

Spencer

----- Original Message -----

From:  Henry  Sinnreich <mailto:[email-masked]>

To: Peter Saint-Andre <mailto:[email-masked]>

Henry

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 20 Sep 2009 20:20:08 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, September 11, 2009 12:56 PM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> "primary" session. (No pejorative intended here - one or the 
> other must go first.)

So XMPP has to use E.164's (like SIP deployments do), or SIP
will have to switch to user@host.  I don't forsee either happening.  
If this is deemed necessary then we will have to map between them 
-- somehow.  Send an XMPP message asking "what is your phone
number" (in a computer-parsable manner), perhaps?

-d

> > application developers don't have to worry about knowing 
> how HTTP works. 
> >     Thanks for your feedback :) Let me answer to the 
> excellent points
> >     you raise.
> > 
> >         the hood is necessary, so we don't do another 
> Elbonia  project.
> >             * Same as with servers: How many and what 
> protocol  RFCs are
> >               there in the combination?
> >             * Which of the "services" can be placed in the  
> applications
> >             * How many protocol stacks does this involve 
> and more  to
> >               the point, how many RFCs?
> >             * For SIP alone, see http://rfc3261.net/. What 
> will be the
> >               total  combined RFC count?
> > 
> > 
> >         This  includes in my mind TLS and DTLS for secure 
> transport or
> >         even better IMO: HIP  for many reasons.
> > 
> > 
> >         * T.V. Raman: "Toward 2W,  Beyond Web 2.0", 
> Communications of
> >         the ACM, February 2009
> >

---

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

Hi Dan, 

Dan Wing wrote:
>Paul Kyzivat wrote:
>> coordination/coexistence of sip and xmpp. And pushing responsibility 
>> to the endpoints remains desirable.
>> 
>> correlate them. So if I want a single "session" involving both voice 
>> via SIP and IM via xmpp, then I have great difficulty in discovering 
>> URIs for the "subordinate" session that correlate with those for the 
>> "primary" session. (No pejorative intended here - one or the other 
>> must go first.)
>

I agree. It will be imposible to require a direct or algorithmic mapping between a SIP URI (in practice most cases a E.164 number as you point out) and a corresponding XMPP URI. However, if a user knows one of them for another user, it should be possible to discover the other. In our draft (http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01) we propose a few requirements and solution possibilities. It should be possible to discover "permanent" URIs (SIP AoR, XMPP JID) as well as dynamic ones that only have meaning in a given context: for instance, if I'm having an IM chat with you with XMPP, I should be able to tell you a SIP URI you can send INVITE to if you want to add a voice call specifically to that conversation context. It should be enough to understand the semantics of these URIs in the endpoints only, i.e. the infrastructure should not need to know anything about them beyond "routing". In SIP we could utilize GRUUs if they were available (in practice we can't rely on them however), in XMPP we already have the full JIDs (xmpp:user@domain/resource) at our disposal.

Markus

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 21 Sep 2009 06:21:21 -0700

>number" (in a computer-parsable manner), perhaps?

Now why could not the application query the address book to get both the E.164 addresses and user@host addresses?

This is not only of interest to naïve folks like me, but also illustrates how some key functions are better done in the applications in the endpoints rather than in the network application protocols.
The "old" e2e principle illustrated...

Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Sep 2009 09:25:57 -0400

inline

> number" (in a computer-parsable manner), perhaps?

Well, there is nothing to prevent XMPP from using E.164+domain name (the 
way most of sip deployments do since nobody seems to like tel:.)

BUT, as things currently stand there is no guarantee that 
sip:[email-masked] and xmpp:[email-masked] refer to the same 
persona. While it would often be a reasonable leap of faith to assume 
they do, the namespaces are typically administered independently.

Having *some* automated way of determining an association seems 
necessary to a good integration. Of course that is exactly what a 
session initiation protocol is all about. Its also something that a 
presence protocol should also be able to do.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 22 Sep 2009 08:57:52 +0200

21 sep 2009 kl. 15.21 skrev Henry Sinnreich:

> Now why could not the application query the address book to get both  
> the E.164 addresses and user@host addresses?
Most jabber servers have vcard support that could include both SIP and  
XMPP uri's.

I don't know if SIP has it, but one could certainly involve LDAP for  
finding stuff like this.

/O

---

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

AFAIK this is only a solution to the extent that I possess such info 
about the other party in the call.

IM has evolved in such a way that typically you are only allowed to IM 
people you "know", so info is available locally about the other party.

But the same is not true of telephony, where often the *only* 
information you have about the other party is the phone number. (Or AOR.)

So while looking things up in your address book could provide some 
useful fallback behavior, I don't think it is a complete solution.

	Thanks,
	Paul

---

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Wed, 23 Sep 2009 15:56:55 -0400

Simo, Markus,
 
I am very interested in this work and I like your approach.
 
I have a question regarding the open issue you have in section 5.2:
Why do you require the correlation-value to be an end-to-end identifier?
In the case where there is an SBC that creates a new dialog for the
target, would it not be enough for each endpoint to use the Call-ID of
the other dialog as the correlation-value?
 
Thanks,
 Rifaat

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, September 04, 2009 8:09 AM
To: [email-masked]; Barnes, Mary (RICH2:AR00);
[email-masked]
Cc: [email-masked]
Subject: [dispatch] New topic proposal for DISPATCH

Hi,

We have been working on a solution which combines SIP based VoIP and
XMPP based IM and Presence. The requirements and a proposed solution is
outlined in
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01
<http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> .

Note that the goal in this work is not SIP-XMPP protocol translation,
but to define protocol extensions and best practises such that SIP based
VoIP and XMPP based IM and presence could be seamlessly combined and
offered to the end user. For rapid deployment, we assume no changes in
the server infrastructure, and instead impose new requirements and
protocol extensions only to the endpoints.
 
We would like to get some discussion going on the use case itself as
well as on the solution. Also, we would like to hear you thoughts on
DISPATCH or a new "dispatched" mini-WG as the home for such work.

Regards,
Simo and Markus

---

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

Hi Rifaat,

In our proposal the correlation works so that:
1. UAs engaged in a SIP session/dialog exchange an identifier related to that session (as well as their XMPP full JIDs)
2. They insert them in the very first XMPP messages they subsequently exchange, in order to correlate that exchange to be related to the SIP session.

The correlation identifier has to be end-to-end, otherwise the other end won't be able to use it for correlation. Call-ID is often changed enroute. So, if one endpoint puts it in an XMPP messages as a reference to a SIP session, the other endpoint won't recognize it as it has a different Call-ID for the same session.

Markus

________________________________
From: ext Rifaat Shekh-Yusef [mailto:[email-masked]]
Sent: 23 September, 2009 22:57
To: Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]; Mary Barnes; [email-masked]
Cc: Isomaki Markus (Nokia-CIC/Espoo)
Subject: RE: [dispatch] New topic proposal for DISPATCH

Simo, Markus,

I have a question regarding the open issue you have in section 5.2:
Why do you require the correlation-value to be an end-to-end identifier?
In the case where there is an SBC that creates a new dialog for the target, would it not be enough for each endpoint to use the Call-ID of the other dialog as the correlation-value?

Thanks,
 Rifaat

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 04, 2009 8:09 AM
To: [email-masked]; Barnes, Mary (RICH2:AR00); [email-masked]
Cc: [email-masked]
Subject: [dispatch] New topic proposal for DISPATCH

Hi,

Regards,
Simo and Markus

---

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Thu, 24 Sep 2009 11:56:46 -0400

Simo,

If I add a B2BUA to the example that you have in section 7.2:

Bob                                                B2BUA
Alice

|                                                      |
|

| (F1) INVITE                                    | (F2) INVITE
|

|--------------------------------------------------
>|---------------------------------------------------> |

| XMPP-Contact: Bob; call-id1           | XMPP-Contact: Bob; call-id1
|

|                                                     |
|

|                                                     |
|

| (F4) 200 OK                                  | (F3) 200 OK
|

|<--------------------------------------------------
|<-------------------------------------------------- |

| XMPP-Contact: Alice; call-id2         | XMPP-Contact: Alice; call-id2
|

|                                                     |
|

Let (F1) INVITE have the correlation-id as the Call-ID of the dialog
between Bob and the B2BUA (call-id1), 

and (F3) 200 OK have the correlation-id as the Call-ID of the dialog
between the B2BUA and Alice (call-id2).

Would it not be enough for Bob to send call-id2 to Alice as the
<sip-correlation>? and for Alice to send call-id1 to Bob as the
<sip-correlation>?

Regards,

 Rifaat

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 24, 2009 2:54 AM
To: Shekh-Yusef, Rifaat (BVW:9T16); [email-masked];
[email-masked]; Barnes, Mary (RICH2:AR00);
[email-masked]
Subject: RE: [dispatch] New topic proposal for DISPATCH - SIP/XMPP

Hi Rifaat,
 
In our proposal the correlation works so that:
1. UAs engaged in a SIP session/dialog exchange an identifier related to
that session (as well as their XMPP full JIDs)
2. They insert them in the very first XMPP messages they subsequently
exchange, in order to correlate that exchange to be related to the SIP
session.
 
The correlation identifier has to be end-to-end, otherwise the other end
won't be able to use it for correlation. Call-ID is often changed
enroute. So, if one endpoint puts it in an XMPP messages as a reference
to a SIP session, the other endpoint won't recognize it as it has a
different Call-ID for the same session.
 
Markus

Mary Barnes; [email-masked]

	Simo, Markus,

	I have a question regarding the open issue you have in section
5.2:
	Why do you require the correlation-value to be an end-to-end
identifier?
	In the case where there is an SBC that creates a new dialog for
the target, would it not be enough for each endpoint to use the Call-ID
of the other dialog as the correlation-value?
	 
	Thanks,
	 Rifaat

[mailto:[email-masked]] On Behalf Of

	Hi,
	 
	We would like to propose a new DISPATCH topic on how SIP and
XMPP can be used together in a complementary fashion.
	 
	We have been working on a solution which combines SIP based VoIP
and XMPP based IM and Presence. The requirements and a proposed solution
is outlined in
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01
<http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> .
	 
	The motivation for this work comes from experience which shows
that most standards based VoIP deployments use SIP. At the same time,
the Extensible Messaging and Presence Protocol (XMPP) is widely used in
instant messaging and presence services. An interesting scenario arises
when a SIP based voice (and video) service is combined together with an
XMPP based instant messaging and presence service. 
	 
	Note that the goal in this work is not SIP-XMPP protocol
translation, but to define protocol extensions and best practises such
that SIP based VoIP and XMPP based IM and presence could be seamlessly
combined and offered to the end user. For rapid deployment, we assume no
changes in the server infrastructure, and instead impose new
requirements and protocol extensions only to the endpoints.
	 
	We would like to get some discussion going on the use case
itself as well as on the solution. Also, we would like to hear you
thoughts on DISPATCH or a new "dispatched" mini-WG as the home for such
work.

	Regards,
	Simo and Markus

---

From: <[email-masked]>
Date: Wed, 30 Sep 2009 11:09:01 +0200

Hello Rifaat,

sorry for the late reply.

If I understood your scenario correctly, you are proposing to use separete correlation id's in each direction. That would work as well, but I don't see the reason why Alice would choose call-id2 as her correlation id, if in any case call-id1 gets to her UA in F2.

Simo

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rifaat Shekh-Yusef
Sent: 24 September, 2009 18:57
To: Isomaki Markus (Nokia-CIC/Espoo); Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]; Mary Barnes; [email-masked]
Subject: Re: [dispatch] New topic proposal for DISPATCH - SIP/XMPP

Simo,

Bob                                                B2BUA                                          Alice
|                                                      |                                                     |
| (F1) INVITE                                    | (F2) INVITE                                    |
|-------------------------------------------------- >|---------------------------------------------------> |
| XMPP-Contact: Bob; call-id1           | XMPP-Contact: Bob; call-id1           |
|                                                     |                                                      |
|                                                     |                                                      |
| (F4) 200 OK                                  | (F3) 200 OK                                   |
|<-------------------------------------------------- |<-------------------------------------------------- |
| XMPP-Contact: Alice; call-id2         | XMPP-Contact: Alice; call-id2          |
|                                                     |                                                     |

Let (F1) INVITE have the correlation-id as the Call-ID of the dialog between Bob and the B2BUA (call-id1),
and (F3) 200 OK have the correlation-id as the Call-ID of the dialog between the B2BUA and Alice (call-id2).

Would it not be enough for Bob to send call-id2 to Alice as the <sip-correlation>? and for Alice to send call-id1 to Bob as the <sip-correlation>?

Regards,
 Rifaat

To: Shekh-Yusef, Rifaat (BVW:9T16); [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00); [email-masked]

Hi Rifaat,

Markus

Simo, Markus,

Thanks,
 Rifaat

Hi,

Regards,
Simo and Markus