From salvatore.loreto at ericsson.com Tue May 13 09:06:41 2008 From: salvatore.loreto at ericsson.com (Salvatore Loreto) Date: Tue, 13 May 2008 17:06:41 +0300 Subject: [SIP-XMPP] sip-xmpp-chat In-Reply-To: <48121036.8040100@stpeter.im> References: <48121036.8040100@stpeter.im> Message-ID: <4829A071.1040502@ericsson.com> Hi Peter, sorry to be late, but I am still catching up a lot of stuff. Peter Saint-Andre wrote: > I've looked at draft-saintandre-sip-xmpp-chat again (which defines the > mapping between XMPP and MSRP for one-to-one chat). There are a few > details that need fixing so I will do that soon. I see a few bigger issues: > > 1. Mapping of XHTML messages. This is supported on the MSRP side and can > be supported on the XMPP side via XEP-0071: > > http://www.xmpp.org/extensions/xep-0071.html > > I'll add some text to the spec that defines more clearly how use of > XHTML can be negotiated and used across MSRP-XMPP gateways. > great! I haven't thought about it, but in effect it is not so simple exchange xhtml in xmpp, isn't it? > 2. When mapping formal session negotiation from MSRP to XMPP, we need to > handle the case of the XMPP client not supporting formal chat session > negotiation. When this happens, the XMPP client should return a > service-unavailable error per Example 4 in XEP-0155. It's not clear to > me if we should map this to error code 403 or 501 in MSRP, but we need > handle this case because IMHO it will happen quite frequently since only > a few XMPP clients support XEP-0155 right now. > here I am not so convinced about this behavior. I remember you told us that only few XMPP clients support XEP-0155, but I don't see any reason why the interworking should fail. Is there any technical or security reason why a MSRP session can not be mapped to an informal XMPP session? I mean will the XMPP formal and informal session behave in some different way from a MSRP point of view? > 3. The mapping of XMPP informal sessions to MSRP (and vice-versa) is > still not clear to me but I will put some serious thought into it soon. > In general I think that mapping will require the gateway to keep more state. > as the previous point. Yes I agree that in those scenarios (points 2 and 3) the mapping will require the gateway to keep more state, but I don't see any problem in this. > 4. How does a SIP UA decide to use MSRP instead of pager-mode messages? > The capabilities discovery method is unclear to me, but then I'm not a > SIP expert. At some point we'll need to define a mapping of capabilities > information between SIP and XMPP, but until then we'll need to add some > text about this to draft-saintandre-sip-xmpp-chat because the gateway > may need to know if the SIP endpoint supports or prefers MSRP (just as > it may need to know if the XMPP endpoint supports formal sessions, XHTML > content, etc.). > I have already answer privately to this particular point, here I copy the answer for sake of completeness. So, the easiest way to discover if a UA support the MSRP is using SDP: > > "The SDP Offer/Answer Model [RFC3264 > ] provides provisions for > indicating a capability to another endpoint (see Section 9 > > of RFC > 3264 [RFC3264 > ]). The mechanism assumes a > high-level protocol, such > as SIP [RFC3261 ], that provides a > capability query (such as a SIP > OPTIONS request). RFC 3264 > [RFC3264 ] indicates how to build > the SDP > that is included in the response to such request. As such, RFC 3264 > > indicates that and endpoint builds an SDP body that contains an "m=" > line that contains the media type (message, for MSRP). " > > (the quote is from > http://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-07#page-22 > ) > > > Once we have these issues clarified I will start work on the groupchat > mapping (i.e., MSRP to XEP-0045 and vice-versa). > Let me know, about it. When do you plan to start it and more important (for my schedule) submit it? Any idea on when call for a BOF? Cheers Sal > Peter > > > ------------------------------------------------------------------------ > > _______________________________________________ > SIP-XMPP mailing list > SIP-XMPP at xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080513/de75c9d2/attachment.htm From salvatore.loreto at ericsson.com Tue May 13 09:09:53 2008 From: salvatore.loreto at ericsson.com (Salvatore Loreto) Date: Tue, 13 May 2008 17:09:53 +0300 Subject: [SIP-XMPP] [Fwd: sip-xmpp-chat] In-Reply-To: <481B3739.40106@stpeter.im> References: <481A3CB5.9050005@stpeter.im> <481AF8E6.7050704@ericsson.com> <481B3739.40106@stpeter.im> Message-ID: <4829A131.9060306@ericsson.com> Peter Saint-Andre wrote: > Great! If we take this approach, then the gateway will perform > essentially the same tasks on the XMPP side and the SIP side: > > 1. Determine the registered devices / aactive connections associated > with the intended recipient > > 2. Determine the capabilities of those devices/connections > > 3. Determine which device/connection is most appropriate to handle the > chat session, i.e., which one can handle a formal session and, if none > can do so, go the informal route > > 4. Perform the appropriate syntax translations for session setup, > message exchange, and session teardown > > I need to think more about #3 but the others seem pretty clear to me. > I think this are the right tasks to performs. About the point 3, as I said in my previous mail, I don't think is so critical from the MSRP User point of view distinguish or become aware if the XMPP side is performing a formal rather then and informal session. what do you think about? Cheers Sal > Peter > > On 05/02/2008 5:20 AM, Salvatore Loreto wrote: > >> Hi Peter, >> >> sorry but i was completely captured by another deadline... >> >> I'll try to answer all your different questions tomorrow. >> In the meantime I really think that the gateway has to discover if the >> UA capabilities: >> if the UA supports or not MSRP, or even if it supports MESSAGE or not . >> >> So, the easiest way to discover if a UA support the MSRP is using SDP: >> >> "The SDP Offer/Answer Model [RFC3264 >> ] provides provisions for >> indicating a capability to another endpoint (see Section 9 >> >> of RFC >> 3264 [RFC3264 >> ]). The mechanism assumes a >> high-level protocol, such >> as SIP [RFC3261 ], that provides a >> capability query (such as a SIP >> OPTIONS request). RFC 3264 >> [RFC3264 ] indicates how to build >> the SDP >> that is included in the response to such request. As such, RFC 3264 >> >> indicates that and endpoint builds an SDP body that contains an "m=" >> line that contains the media type (message, for MSRP). " >> >> (the quote is from >> http://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-07#page-22 >> ) >> >> >> >> sorry to be late... but I think next week I can work more on this. >> >> cheers >> Sal >> >> Peter Saint-Andre wrote: >> >>> Hi Sal, did you receive this message on the sip-xmpp at xmpp.org list? If >>> you have answers to some of my SIP questions, that would be quite >>> helpful. I think I see how to map MSRP to XMPP formal or informal using >>> XMPP capabilities information, but I don't see how to go from XMPP >>> informal to MSRP formal unless the gateway knows about the MSRP UA's >>> preferences or capabilities. >>> >>> -------- Original Message -------- >>> Date: Fri, 25 Apr 2008 11:09:10 -0600 >>> From: Peter Saint-Andre >>> To: sip-xmpp at xmpp.org >>> Subject: [SIP-XMPP] sip-xmpp-chat >>> >>> I've looked at draft-saintandre-sip-xmpp-chat again (which defines the >>> mapping between XMPP and MSRP for one-to-one chat). There are a few >>> details that need fixing so I will do that soon. I see a few bigger >>> issues: >>> >>> 1. Mapping of XHTML messages. This is supported on the MSRP side and can >>> be supported on the XMPP side via XEP-0071: >>> >>> http://www.xmpp.org/extensions/xep-0071.html >>> >>> I'll add some text to the spec that defines more clearly how use of >>> XHTML can be negotiated and used across MSRP-XMPP gateways. >>> >>> 2. When mapping formal session negotiation from MSRP to XMPP, we need to >>> handle the case of the XMPP client not supporting formal chat session >>> negotiation. When this happens, the XMPP client should return a >>> service-unavailable error per Example 4 in XEP-0155. It's not clear to >>> me if we should map this to error code 403 or 501 in MSRP, but we need >>> handle this case because IMHO it will happen quite frequently since only >>> a few XMPP clients support XEP-0155 right now. >>> >>> 3. The mapping of XMPP informal sessions to MSRP (and vice-versa) is >>> still not clear to me but I will put some serious thought into it soon. >>> In general I think that mapping will require the gateway to keep more >>> state. >>> >>> 4. How does a SIP UA decide to use MSRP instead of pager-mode messages? >>> The capabilities discovery method is unclear to me, but then I'm not a >>> SIP expert. At some point we'll need to define a mapping of capabilities >>> information between SIP and XMPP, but until then we'll need to add some >>> text about this to draft-saintandre-sip-xmpp-chat because the gateway >>> may need to know if the SIP endpoint supports or prefers MSRP (just as >>> it may need to know if the XMPP endpoint supports formal sessions, XHTML >>> content, etc.). >>> >>> Once we have these issues clarified I will start work on the groupchat >>> mapping (i.e., MSRP to XEP-0045 and vice-versa). >>> >>> Peter >>> >>> >>> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080513/d149c7df/attachment.htm From Markus.Isomaki at nokia.com Wed May 28 08:29:36 2008 From: Markus.Isomaki at nokia.com (Markus.Isomaki at nokia.com) Date: Wed, 28 May 2008 16:29:36 +0300 Subject: [SIP-XMPP] Combined use of SIP and XMPP In-Reply-To: <4829A131.9060306@ericsson.com> References: <481A3CB5.9050005@stpeter.im> <481AF8E6.7050704@ericsson.com><481B3739.40106@stpeter.im> <4829A131.9060306@ericsson.com> Message-ID: Hi all, I have a topic which should fit into the scope of this list. In the last couple of years there has been a trend to use SIP and XMPP in a combined way such that SIP offers voice/telephony/PSTN interconnect service (and potentially other real-time session services such as video calls), while XMPP is used for IM, presence, file transfer etc. There are some service providers, such as Gizmo, who already do this. Similarly, I have heard of a few client developers who are building clients for that kind of service setup. This is an interesting approach for many VoIP providers who already do SIP, and would like to go beyond voice. It's true that SIP also has IM/presence capabilities but the number of clients or servers doing this is very small and interoperability is very shaky. So, XMPP might be a good way for them. Similarly, many current XMPP providers might want to add telephony and PSTN connectivity. They could use Jingle for that but probably SIP would offer more in that dimension, especially if PSTN emulation is important. It is possible just to use the two protocols and build a common service. However, there are potential issues such as identities (both protocols have their own namespace), presence (how to indicate SIP VoIP/video support in the XMPP presence info), interaction of SIP VoIP/video with a combined XMPP IM session (how to make sure they end up in the same UA/endpoint, stuff like SIP GRUU may need to be taken into account) etc. My goal would be to build a "generic" client that would work with SIP and XMPP with as many service providers as possible. So, I would be interested in drafting some kind of "Best Current Practices" document (perhaps an IETF Internet-Draft) that would explain the cleanest way of doing this, both from client and service provider point of view. In addition to this there could be even need for some minor normative extensions, such as how to carry SIP GRUU in XMPP etc. I suppose the main purpose of this list is to define how SIP<->XMPP gateways work for IM, presence, voice, but would others be interested in the work that I'm describing above? Regards, Markus Isom?ki From salvatore.loreto at ericsson.com Wed May 28 09:10:38 2008 From: salvatore.loreto at ericsson.com (Salvatore Loreto) Date: Wed, 28 May 2008 17:10:38 +0300 Subject: [SIP-XMPP] Combined use of SIP and XMPP In-Reply-To: References: <481A3CB5.9050005@stpeter.im> <481AF8E6.7050704@ericsson.com><481B3739.40106@stpeter.im> <4829A131.9060306@ericsson.com> Message-ID: <483D67DE.3060901@ericsson.com> Hi Markus, I like your proposal, my opinion is that both the protocols SIP and XMPP have pros and cons so using them together is not a bad idea at all. I am interested !!! about the interwork between SIP and XMPP, some draft are already *ready*, some need to be finalized (e.g. xmpp-chat ) and some other have to be started (e.g. multi-chat, capabilities, capabilities exchanges etc. etc.). It is not so clear to me if to accomplish your proposal we need finalize them before or not. cheers Sal Markus.Isomaki at nokia.com wrote: > Hi all, > > I have a topic which should fit into the scope of this list. > > In the last couple of years there has been a trend to use SIP and XMPP in a combined way such that SIP offers voice/telephony/PSTN interconnect service (and potentially other real-time session services such as video calls), while XMPP is used for IM, presence, file transfer etc. There are some service providers, such as Gizmo, who already do this. Similarly, I have heard of a few client developers who are building clients for that kind of service setup. > > This is an interesting approach for many VoIP providers who already do SIP, and would like to go beyond voice. It's true that SIP also has IM/presence capabilities but the number of clients or servers doing this is very small and interoperability is very shaky. So, XMPP might be a good way for them. Similarly, many current XMPP providers might want to add telephony and PSTN connectivity. They could use Jingle for that but probably SIP would offer more in that dimension, especially if PSTN emulation is important. > > It is possible just to use the two protocols and build a common service. However, there are potential issues such as identities (both protocols have their own namespace), presence (how to indicate SIP VoIP/video support in the XMPP presence info), interaction of SIP VoIP/video with a combined XMPP IM session (how to make sure they end up in the same UA/endpoint, stuff like SIP GRUU may need to be taken into account) etc. > > My goal would be to build a "generic" client that would work with SIP and XMPP with as many service providers as possible. So, I would be interested in drafting some kind of "Best Current Practices" document (perhaps an IETF Internet-Draft) that would explain the cleanest way of doing this, both from client and service provider point of view. In addition to this there could be even need for some minor normative extensions, such as how to carry SIP GRUU in XMPP etc. > > I suppose the main purpose of this list is to define how SIP<->XMPP gateways work for IM, presence, voice, but would others be interested in the work that I'm describing above? > > Regards, > Markus Isom?ki > > _______________________________________________ > SIP-XMPP mailing list > SIP-XMPP at xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp >