Combining the use of SIP and XMPP in an endpoint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

In the spirit of making the best use of open standards for rich Internet multimedia communication, we have put together the following draft: 
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-00

   This memo defines guidelines and protocol extensions for combining
   Session Initiation Protocol (SIP) based real-time media sessions with
   Extensible Messaging and Presence Protocol (XMPP) based instant
   messaging and presence services in a seamless manner.  This is
   accomplished by integration and protocol extension support in the
   endpoints, without requiring any changes in the SIP or XMPP server
   infrastructure.  It is even possible that SIP and XMPP services are
   offered by different service providers.

The solution is based on defining some new elements in SIP (headers) and XMPP (message stanza extensions) to pass around the contact and correlation information related to the other protocol. 

We would like to get feedback on two levels:
1) Does such combined use make sense? Or should we keep the two protocols separated and merely specify how they can interwork through a gateway?
2) Do we have a correct technical approach? In the first draft the correlation part is perhaps even too rigorous, we would like get feedback if people think we could simplify.

Please send comments to the SIPPING (sipping@xxxxxxxx) list only.

Regards,
	Markus 
 

>-----Original Message-----
>From: rai-bounces@xxxxxxxx [mailto:rai-bounces@xxxxxxxx] On 
>Behalf Of Isomaki Markus (Nokia-CIC/Espoo)
>Sent: 16 February, 2009 01:55
>To: adam@xxxxxxxxxxx
>Cc: rai@xxxxxxxx
>Subject: Re: [RAI] RAI reorganization - role of SIP
>
>Hi Adam, others,
>
>Adam Roach wrote:
>>
>>If you follow the thread back, this branch of it started from a 
>>challenge to Eric's assertion that SIP is used for more than POTS 
>>replacement. I'm boggled that we've come so far that such an 
>assertion 
>>even needs to be given a voice, much less a defense. (Marcus' 
>voice is 
>>not isolated; several key people have expressed equivalent 
>sentiments.)
>>
>
>Just to clarify where I stand:
>
>I agree that communication over Internet should go far beyond 
>what POTS has enabled, and of course this has happened already 
>in many ways. I don't think anyone challenges that. Our goal 
>should be to develop the best possible open standards that can 
>deliver various kinds of real-time/messaging/multimedia apps.
>
>The issue that is more controversial is the role of SIP and 
>RAI area protocols in general in all of that. SIP is clearly 
>taking the POTS/PBX replacement market and has quite good 
>fundamentals for telephony and video. However, for other apps 
>there are competing/complementary approaches, such as XMPP and 
>web/AJAX-based mechanisms. For instance if I was today to 
>create an open standard real-time communication app I could 
>pick SIP for voice/video, XMPP for presence/IM and a web-based 
>solution for some of the conferencing/collaboration features.
>
>The question is where to focus the precious resources in RAI 
>to create most *new* value. In addition to developing its own 
>protocols it would be good for RAI to think how its protocols 
>interact with these "external" protocols and what would be the 
>best way to use them together to create the best possible 
>solution for Internet users.
>
>Markus
>_______________________________________________
>RAI mailing list
>RAI@xxxxxxxx
>https://www.ietf.org/mailman/listinfo/rai
>
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux