From stpeter at stpeter.im Tue Aug 5 15:04:12 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 05 Aug 2008 14:04:12 -0600 Subject: [SIP-XMPP] [Fwd: I-D Action:draft-saintandre-sip-xmpp-presence-01.txt] Message-ID: <4898B23C.7090203@stpeter.im> FYI, I've updated the sip-xmpp-presence I-D based on feedback I received off-list. /psa -------- Original Message -------- From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org Subject: I-D Action:draft-saintandre-sip-xmpp-presence-01.txt Date: Tue, 5 Aug 2008 13:00:01 -0700 (PDT) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence Author(s) : P. Saint-Andre, et al. Filename : draft-saintandre-sip-xmpp-presence-01.txt Pages : 21 Date : 2008-08-05 This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-presence-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080805/1dcb1e07/attachment.bin From stpeter at stpeter.im Tue Aug 5 19:28:22 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 05 Aug 2008 18:28:22 -0600 Subject: [SIP-XMPP] [Fwd: I-D Action:draft-saintandre-sip-xmpp-presence-01.txt] In-Reply-To: <4898B23C.7090203@stpeter.im> References: <4898B23C.7090203@stpeter.im> Message-ID: <4898F026.9030303@stpeter.im> It seems that the ietf.org link is broken. Until they fix it, you can find the updated I-D here: http://www.xmpp.org/internet-drafts/ /psa Peter Saint-Andre wrote: > FYI, I've updated the sip-xmpp-presence I-D based on feedback I received > off-list. > > /psa > > -------- Original Message -------- > From: Internet-Drafts at ietf.org > To: i-d-announce at ietf.org > Subject: I-D Action:draft-saintandre-sip-xmpp-presence-01.txt > Date: Tue, 5 Aug 2008 13:00:01 -0700 (PDT) > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Interworking between the Session Initiation > Protocol (SIP) and the Extensible Messaging and Presence Protocol > (XMPP): Presence > Author(s) : P. Saint-Andre, et al. > Filename : draft-saintandre-sip-xmpp-presence-01.txt > Pages : 21 > Date : 2008-08-05 > > This document defines a bi-directional protocol mapping for the > exchange of presence information between the Session Initiation > Protocol (SIP) and the Extensible Messaging and Presence Protocol > (XMPP). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-presence-01.txt > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > SIP-XMPP mailing list > SIP-XMPP at xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080805/8ab6db68/attachment.bin From xramtsov at gmail.com Tue Aug 5 19:47:18 2008 From: xramtsov at gmail.com (Evgeniy Khramtsov) Date: Wed, 06 Aug 2008 10:47:18 +1000 Subject: [SIP-XMPP] [Fwd: I-D Action:draft-saintandre-sip-xmpp-presence-01.txt] In-Reply-To: <4898B23C.7090203@stpeter.im> References: <4898B23C.7090203@stpeter.im> Message-ID: <4898F496.2040000@gmail.com> Peter Saint-Andre wrote: > FYI, I've updated the sip-xmpp-presence I-D based on feedback I > received off-list. > > /psa About section 2.3.2. Is it really useful to treat subscriptions temporary? For example, in my implementation I send "unsubscribe" only when I get a NOTIFY with Subscription-State 'terminated' and reason *rejected*. In other cases I send "unavailable". Moreover, in the case of terminated;reason=timeout I also try to resend SUBSCRIBE request. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram at jabber.ru. From oej at edvina.net Wed Aug 6 06:21:43 2008 From: oej at edvina.net (Johansson Olle E) Date: Wed, 6 Aug 2008 13:21:43 +0200 Subject: [SIP-XMPP] Character set in draft-saintandre-sip-xmpp-im-00.html Message-ID: This draft doesn't cover the case when the SIP message contains a different character set than UTF8. I think that should be mapped as well. In the other direction, it would be recommended to add a charset header, even though SIP should assume utf8. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080806/9f768b8e/attachment-0001.bin From oej at edvina.net Wed Aug 6 06:25:40 2008 From: oej at edvina.net (Johansson Olle E) Date: Wed, 6 Aug 2008 13:25:40 +0200 Subject: [SIP-XMPP] Using XMPP uri's in SIP Message-ID: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> Has anyone thought about using XMPP URI's in SIP. There's been a lot of movement in SIP standardization about handling different URI schemas lately. I would assume that it should be possible to send a SIP message like: MESSAGE xmpp:romeo at example.net/l?ddek?ping SIP/2.0 Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:juliet at example.com;tag=49583 To: xmpp:romeo at example.net Call-ID: Hr0zny9l3 at example.com CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 35 Art thou not R?meo, and a M?nt?gue? The proxy/server that receives this should be able to send it to a proper gateway or just send an error message. The other way would be interesting as well. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080806/0678278e/attachment.bin From oej at edvina.net Wed Aug 6 06:30:14 2008 From: oej at edvina.net (Johansson Olle E) Date: Wed, 6 Aug 2008 13:30:14 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-im-00.html : Multipart messages Message-ID: <4504EA73-EFEE-406B-AF51-1C4F61E54F00@edvina.net> This document doesn't mention multipart messages in any direction. In XMPP, there can be several language-specific body parts to choose from. In SIP, there could be both text/plain and text/html - just as an example. Just a note. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080806/d3ddc5e9/attachment.bin From oej at edvina.net Wed Aug 6 06:54:13 2008 From: oej at edvina.net (Johansson Olle E) Date: Wed, 6 Aug 2008 13:54:13 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 Message-ID: I learned at a SIPit a year ago that a SIP Subscribe with Expires: 0 is used to poke. According to the SIP RFC, this will lead to one NOTIFY with the current state, but no subscription. The NOTIFY has a SIP header that terminates the session. I would suggest that this is handled in the draft as well. It only mentions a SUBSCRIBE with Expires: 0 to terminate a subscription. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080806/32bb9adf/attachment.bin From AVSHALOM at il.ibm.com Wed Aug 6 07:05:51 2008 From: AVSHALOM at il.ibm.com (Avshalom Houri) Date: Wed, 6 Aug 2008 15:05:51 +0300 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> Message-ID: Not aware to any work in the SIP groups themselves on this. There was a lot of discussion on Tel URIs but not on this. What will be the meaning of the XMPP URI in SIP? Does it assume a GW that translates the protocols etc.? --Avshalom Johansson Olle E Sent by: sip-xmpp-bounces at xmpp.org 06/08/2008 14:40 To sip-xmpp at xmpp.org cc Subject [SIP-XMPP] Using XMPP uri's in SIP Has anyone thought about using XMPP URI's in SIP. There's been a lot of movement in SIP standardization about handling different URI schemas lately. I would assume that it should be possible to send a SIP message like: MESSAGE xmpp:romeo at example.net/l?ddek?ping SIP/2.0 Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:juliet at example.com;tag=49583 To: xmpp:romeo at example.net Call-ID: Hr0zny9l3 at example.com CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 35 Art thou not R?meo, and a M?nt?gue? The proxy/server that receives this should be able to send it to a proper gateway or just send an error message. The other way would be interesting as well. /O_______________________________________________ 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/20080806/8aeeeec1/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/octet-stream Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080806/8aeeeec1/attachment.obj From oej at edvina.net Wed Aug 6 09:55:39 2008 From: oej at edvina.net (Johansson Olle E) Date: Wed, 6 Aug 2008 16:55:39 +0200 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> Message-ID: <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> 6 aug 2008 kl. 14.05 skrev Avshalom Houri: > > Not aware to any work in the SIP groups themselves on this. > There was a lot of discussion on Tel URIs but not on this. I haven't seem discussion about XMPP URI's, but a lot of discussions and tests on being able to handle non-SIP uri's in proxys. Tel: is just one example. Robert Sparks has been pressing on this. > > > What will be the meaning of the XMPP URI in SIP? It's a valid URI to send messages to if there's a gateway in the network. > > Does it assume a GW that translates the protocols etc.? Yes, it has to. I feel it's awkward to mangle the address if it's not really needed. It could either be controlled by an endpoint or by an alias table saying "any messages to my SIP URI has to be forwarded to this XMPP URI" /O > > > --Avshalom > > > > Johansson Olle E > Sent by: sip-xmpp-bounces at xmpp.org > 06/08/2008 14:40 > > To > sip-xmpp at xmpp.org > cc > Subject > [SIP-XMPP] Using XMPP uri's in SIP > > > > > > Has anyone thought about using XMPP URI's in SIP. There's been a lot > of movement in SIP standardization about handling > different URI schemas lately. > > I would assume that it should be possible to send a SIP message like: > > MESSAGE xmpp:romeo at example.net/l?ddek?ping SIP/2.0 > Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse > Max-Forwards: 70 > From: sip:juliet at example.com;tag=49583 > To: xmpp:romeo at example.net > Call-ID: Hr0zny9l3 at example.com > CSeq: 1 MESSAGE > Content-Type: text/plain > Content-Length: 35 > > Art thou not R?meo, and a M?nt?gue? > > The proxy/server that receives this should be able to send it to a > proper gateway or just send an error message. > > The other way would be interesting as well. > /O_______________________________________________ > SIP-XMPP mailing list > SIP-XMPP at xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp > > _______________________________________________ > SIP-XMPP mailing list > SIP-XMPP at xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp --- * Olle E Johansson - oej at edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080806/8affb8dc/attachment-0001.bin From xramtsov at gmail.com Wed Aug 6 10:08:47 2008 From: xramtsov at gmail.com (Evgeniy Khramtsov) Date: Thu, 07 Aug 2008 01:08:47 +1000 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: References: Message-ID: <4899BE7F.1060906@gmail.com> Johansson Olle E wrote: > I learned at a SIPit a year ago that a SIP Subscribe with Expires: 0 > is used to poke. According to the SIP RFC, this will lead to one > NOTIFY with the current state, but no subscription. > The NOTIFY has a SIP header that terminates the session. I'm not actually sure what do you mean when you say "NOTIFY with the current state, but no subscription". According to RFC 3265, "the subscription is not considered terminated until the NOTIFY with a "Subscription-State" of "terminated" is sent.". However, in real life you can never get such a NOTIFY at all. For example, you can get an error to you SUBSCRIBE request, you can get a NOTIFY with Subscription-State of "active/pending" or you can never get a NOTIFY :) Thus, in my opinion, this requirement is strange at least. So, I can't agree with your suggestion about handling this requirement in the draft :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram at jabber.ru. From JHildebrand at jabber.com Wed Aug 6 10:57:14 2008 From: JHildebrand at jabber.com (Joe Hildebrand) Date: Wed, 6 Aug 2008 09:57:14 -0600 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-im-00.html : Multipart messages In-Reply-To: <4504EA73-EFEE-406B-AF51-1C4F61E54F00@edvina.net> References: <4504EA73-EFEE-406B-AF51-1C4F61E54F00@edvina.net> Message-ID: <0B9CD2D6B87A544987BD4EF2E145A94D02A91618@dencms1.corp.jabber.com> As well, there's XEP-71 for XHTML over XMPP, which should be mapped into text/html on the SIP side. http://www.xmpp.org/extensions/xep-0071.html The hard part is that the SIP HTML might not be well-formed XML. There are utilities for fixing this, but specifying it in standards language... shudder. -- Joe Hildebrand > -----Original Message----- > From: sip-xmpp-bounces at xmpp.org [mailto:sip-xmpp-bounces at xmpp.org] On > Behalf Of Johansson Olle E > Sent: Wednesday, August 06, 2008 5:30 AM > To: sip-xmpp at xmpp.org > Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-im-00.html : Multipart > messages > > This document doesn't mention multipart messages in any direction. > > In XMPP, there can be several language-specific body parts to choose > from. > In SIP, there could be both text/plain and text/html - just as an > example. > > Just a note. > > /O From AVSHALOM at il.ibm.com Wed Aug 6 11:31:04 2008 From: AVSHALOM at il.ibm.com (Avshalom Houri) Date: Wed, 6 Aug 2008 19:31:04 +0300 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> Message-ID: sip-xmpp-bounces at xmpp.org wrote on 06/08/2008 17:55:39: > Johansson Olle E > Sent by: sip-xmpp-bounces at xmpp.org > > 06/08/2008 17:57 > > To > > Avshalom Houri/Haifa/IBM at IBMIL > > cc > > sip-xmpp at xmpp.org > > Subject > > Re: [SIP-XMPP] Using XMPP uri's in SIP > > > 6 aug 2008 kl. 14.05 skrev Avshalom Houri: > > > > > Not aware to any work in the SIP groups themselves on this. > > There was a lot of discussion on Tel URIs but not on this. > I haven't seem discussion about XMPP URI's, but a lot of discussions > and tests on being able to handle non-SIP uri's in proxys. > Tel: is just one example. > Robert Sparks has been pressing on this. Yes but here we will need to define what should be the behavior of a SIP proxy that sees XMPP URI. How it finds the GW etc. > > > > > > What will be the meaning of the XMPP URI in SIP? > It's a valid URI to send messages to if there's a gateway in the > network. Meant more the meaning of operation from point of view of proxies etc. I should have clarified. > > > > > Does it assume a GW that translates the protocols etc.? > Yes, it has to. How to find the right GW from possible several GWs? For example, if some GW supports JINGLE and the other not INVITE for audio should go the GW that supports JINGLE. > > I feel it's awkward to mangle the address if it's not really needed. > > It could either be controlled by an endpoint or by an alias table saying > "any messages to my SIP URI has to be forwarded to this XMPP URI" > > /O > > > > > > --Avshalom > > > > > > > > Johansson Olle E > > Sent by: sip-xmpp-bounces at xmpp.org > > 06/08/2008 14:40 > > > > To > > sip-xmpp at xmpp.org > > cc > > Subject > > [SIP-XMPP] Using XMPP uri's in SIP > > > > > > > > > > > > Has anyone thought about using XMPP URI's in SIP. There's been a lot > > of movement in SIP standardization about handling > > different URI schemas lately. > > > > I would assume that it should be possible to send a SIP message like: > > > > MESSAGE xmpp:romeo at example.net/l?ddek?ping SIP/2.0 > > Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse > > Max-Forwards: 70 > > From: sip:juliet at example.com;tag=49583 > > To: xmpp:romeo at example.net > > Call-ID: Hr0zny9l3 at example.com > > CSeq: 1 MESSAGE > > Content-Type: text/plain > > Content-Length: 35 > > > > Art thou not R?meo, and a M?nt?gue? > > > > The proxy/server that receives this should be able to send it to a > > proper gateway or just send an error message. > > > > The other way would be interesting as well. > > /O_______________________________________________ > > SIP-XMPP mailing list > > SIP-XMPP at xmpp.org > > http://mail.jabber.org/mailman/listinfo/sip-xmpp > > > > _______________________________________________ > > SIP-XMPP mailing list > > SIP-XMPP at xmpp.org > > http://mail.jabber.org/mailman/listinfo/sip-xmpp > > --- > * Olle E Johansson - oej at edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > > [attachment "smime.p7s" deleted by Avshalom Houri/Haifa/IBM] > _______________________________________________ > 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/20080806/d465acba/attachment.htm From sanjsinh at cisco.com Wed Aug 6 12:38:16 2008 From: sanjsinh at cisco.com (Sanjay Sinha (sanjsinh)) Date: Wed, 6 Aug 2008 13:38:16 -0400 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <4899BE7F.1060906@gmail.com> Message-ID: It is possible for a Subscriber to send SUBSCRIBE with Expires: 0 to get the current snapshot of subscribed state in initial and the only Notify. As Johansson mentioned, this does not establish subscription, but is a fetch operation. Sanjay >-----Original Message----- >From: sip-xmpp-bounces at xmpp.org >[mailto:sip-xmpp-bounces at xmpp.org] On Behalf Of Evgeniy Khramtsov >Sent: Wednesday, August 06, 2008 11:09 AM >To: sip-xmpp at xmpp.org >Subject: Re: [SIP-XMPP] >draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 > >Johansson Olle E wrote: > >> I learned at a SIPit a year ago that a SIP Subscribe with Expires: 0 >> is used to poke. According to the SIP RFC, this will lead to one >> NOTIFY with the current state, but no subscription. >> The NOTIFY has a SIP header that terminates the session. > >I'm not actually sure what do you mean when you say "NOTIFY >with the current state, but no subscription". According to RFC >3265, "the subscription is not considered terminated until the >NOTIFY with a "Subscription-State" of "terminated" is sent.". >However, in real life you can never get such a NOTIFY at all. >For example, you can get an error to you SUBSCRIBE request, >you can get a NOTIFY with Subscription-State of >"active/pending" or you can never get a NOTIFY :) Thus, in my >opinion, this requirement is strange at least. So, I can't >agree with your suggestion about handling this requirement in >the draft :) > >-- >Regards, >Evgeniy Khramtsov, ProcessOne. >xmpp:xram at jabber.ru. > >_______________________________________________ >SIP-XMPP mailing list >SIP-XMPP at xmpp.org >http://mail.jabber.org/mailman/listinfo/sip-xmpp > From oej at edvina.net Thu Aug 7 05:43:46 2008 From: oej at edvina.net (Johansson Olle E) Date: Thu, 7 Aug 2008 12:43:46 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <4899BE7F.1060906@gmail.com> References: <4899BE7F.1060906@gmail.com> Message-ID: <00E8A64D-CCD2-477E-BD2C-7885B6E7A394@edvina.net> 6 aug 2008 kl. 17.08 skrev Evgeniy Khramtsov: > Johansson Olle E wrote: > >> I learned at a SIPit a year ago that a SIP Subscribe with Expires: 0 >> is used to poke. According to the SIP RFC, this will lead to one >> NOTIFY with the current state, but no subscription. >> The NOTIFY has a SIP header that terminates the session. > > I'm not actually sure what do you mean when you say "NOTIFY with the > current state, but no subscription". According to RFC 3265, "the > subscription is not considered terminated until the NOTIFY with a > "Subscription-State" of "terminated" is sent.". However, in real life > you can never get such a NOTIFY at all. Asterisk does support this as many devices required it. So it works in real life. > For example, you can get an > error to you SUBSCRIBE request, you can get a NOTIFY with > Subscription-State of "active/pending" or you can never get a > NOTIFY :) > Thus, in my opinion, this requirement is strange at least. So, I can't > agree with your suggestion about handling this requirement in the > draft :) I don't follow you. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080807/5f8465a9/attachment.bin From oej at edvina.net Thu Aug 7 05:45:35 2008 From: oej at edvina.net (Johansson Olle E) Date: Thu, 7 Aug 2008 12:45:35 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-im-00.html : Multipart messages In-Reply-To: <0B9CD2D6B87A544987BD4EF2E145A94D02A91618@dencms1.corp.jabber.com> References: <4504EA73-EFEE-406B-AF51-1C4F61E54F00@edvina.net> <0B9CD2D6B87A544987BD4EF2E145A94D02A91618@dencms1.corp.jabber.com> Message-ID: <63CEBAC4-0594-455B-9FEB-EA2C44B388ED@edvina.net> 6 aug 2008 kl. 17.57 skrev Joe Hildebrand: > As well, there's XEP-71 for XHTML over XMPP, which should be mapped > into > text/html on the SIP side. > http://www.xmpp.org/extensions/xep-0071.html > > The hard part is that the SIP HTML might not be well-formed XML. > There > are utilities for fixing this, but specifying it in standards > language... shudder. I think the draft says something about that... Under section 3: "A SIMPLE-to-XMPP gateway SHOULD process SIP messages that contain message bodies of type "text/html"; if so, a gateway MUST transform the "text/html" content into XHTML content that conforms to the XHTML 1.0 Integration Set specified in [XEP?0071]." A MUST directive that is not very easy to handle... I need to find a library to help me here. /O > > > -- > Joe Hildebrand > >> -----Original Message----- >> From: sip-xmpp-bounces at xmpp.org [mailto:sip-xmpp-bounces at xmpp.org] On >> Behalf Of Johansson Olle E >> Sent: Wednesday, August 06, 2008 5:30 AM >> To: sip-xmpp at xmpp.org >> Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-im-00.html : Multipart >> messages >> >> This document doesn't mention multipart messages in any direction. >> >> In XMPP, there can be several language-specific body parts to choose >> from. >> In SIP, there could be both text/plain and text/html - just as an >> example. >> >> Just a note. >> >> /O > _______________________________________________ > SIP-XMPP mailing list > SIP-XMPP at xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp --- * Olle E Johansson - oej at edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080807/ffd8c2fc/attachment.bin From oej at edvina.net Thu Aug 7 05:47:29 2008 From: oej at edvina.net (Johansson Olle E) Date: Thu, 7 Aug 2008 12:47:29 +0200 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> Message-ID: 6 aug 2008 kl. 18.31 skrev Avshalom Houri: > > > > > sip-xmpp-bounces at xmpp.org wrote on 06/08/2008 17:55:39: > > > Johansson Olle E > > Sent by: sip-xmpp-bounces at xmpp.org > > > > 06/08/2008 17:57 > > > > To > > > > Avshalom Houri/Haifa/IBM at IBMIL > > > > cc > > > > sip-xmpp at xmpp.org > > > > Subject > > > > Re: [SIP-XMPP] Using XMPP uri's in SIP > > > > > > 6 aug 2008 kl. 14.05 skrev Avshalom Houri: > > > > > > > > Not aware to any work in the SIP groups themselves on this. > > > There was a lot of discussion on Tel URIs but not on this. > > I haven't seem discussion about XMPP URI's, but a lot of discussions > > and tests on being able to handle non-SIP uri's in proxys. > > Tel: is just one example. > > Robert Sparks has been pressing on this. > > Yes but here we will need to define what should be the > behavior of a SIP proxy that sees XMPP URI. How it finds the > GW etc. > Yes. That has to be site-specific, like tel: > > > > > > > > > What will be the meaning of the XMPP URI in SIP? > > It's a valid URI to send messages to if there's a gateway in the > > network. > Meant more the meaning of operation from point of view of proxies > etc. I should have clarified. > > > > > > > > Does it assume a GW that translates the protocols etc.? > > Yes, it has to. > How to find the right GW from possible several GWs? > For example, if some GW supports JINGLE and the other not INVITE for > audio > should go the GW that supports JINGLE. I think that routing like this must also be something to configure in the gw. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080807/a147dff5/attachment.bin From salvatore.loreto at ericsson.com Thu Aug 7 08:49:32 2008 From: salvatore.loreto at ericsson.com (Salvatore Loreto) Date: Thu, 07 Aug 2008 16:49:32 +0300 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> Message-ID: <489AFD6C.5050700@ericsson.com> Hi, I haven't seen any discussion about it in IETF, and I am afraid that not only the sip related wgs but also the xcon working group is not taking in consideration the possibility to use an xmpp uri. On the other end is it possible insert a SIP URI in an XMPP message? the possibility to insert and to use a XMPP URI in a SIP Message, or in SIP request in general, it is not straightforward at all, because in order to use an XMPP URI you have modify the sip parser in both the UAC/UAS and the proxy, you have to provide a semantic meaning for the usage not only in the MESSAGE request but also for all the different SIP requests, not to talk about the headers etc. etc. however I do not understand the advantages to insert directly an XMPP uri in the MESSAGE request versus the translation of a SIP URI in an XMPP URI in the GW. Can you clarify this point? /Sal Johansson Olle E wrote: > > 6 aug 2008 kl. 18.31 skrev Avshalom Houri: > >> >> >> >> >> sip-xmpp-bounces at xmpp.org wrote on 06/08/2008 17:55:39: >> >> > Johansson Olle E >> > Sent by: sip-xmpp-bounces at xmpp.org >> > >> > 06/08/2008 17:57 >> > >> > To >> > >> > Avshalom Houri/Haifa/IBM at IBMIL >> > >> > cc >> > >> > sip-xmpp at xmpp.org >> > >> > Subject >> > >> > Re: [SIP-XMPP] Using XMPP uri's in SIP >> > >> > >> > 6 aug 2008 kl. 14.05 skrev Avshalom Houri: >> > >> > > >> > > Not aware to any work in the SIP groups themselves on this. >> > > There was a lot of discussion on Tel URIs but not on this. >> > I haven't seem discussion about XMPP URI's, but a lot of discussions >> > and tests on being able to handle non-SIP uri's in proxys. >> > Tel: is just one example. >> > Robert Sparks has been pressing on this. >> >> Yes but here we will need to define what should be the >> behavior of a SIP proxy that sees XMPP URI. How it finds the >> GW etc. >> > Yes. That has to be site-specific, like tel: > > >> > > >> > > >> > > What will be the meaning of the XMPP URI in SIP? >> > It's a valid URI to send messages to if there's a gateway in the >> > network. >> Meant more the meaning of operation from point of view of proxies >> etc. I should have clarified. >> > >> > > >> > > Does it assume a GW that translates the protocols etc.? >> > Yes, it has to. >> How to find the right GW from possible several GWs? >> For example, if some GW supports JINGLE and the other not INVITE for >> audio >> should go the GW that supports JINGLE. > I think that routing like this must also be something to configure in > the gw. > > /O > ------------------------------------------------------------------------ > > _______________________________________________ > SIP-XMPP mailing list > SIP-XMPP at xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp > From salvatore.loreto at ericsson.com Thu Aug 7 09:23:12 2008 From: salvatore.loreto at ericsson.com (Salvatore Loreto) Date: Thu, 07 Aug 2008 17:23:12 +0300 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: References: Message-ID: <489B0550.8040308@ericsson.com> I agree with Johansson, in SIP it is possible to fetch only one time the subscribed state, so it should worth to insert to sake of completeness some text to mention in the draft also the behavior for a SIP Subscribe with Expires: 0 used *to poke*. Sal Johansson Olle E wrote: > I learned at a SIPit a year ago that a SIP Subscribe with Expires: 0 > is used to poke. According to the SIP RFC, this will lead to one > NOTIFY with the current state, but no subscription. > The NOTIFY has a SIP header that terminates the session. > > I would suggest that this is handled in the draft as well. It only > mentions a SUBSCRIBE with Expires: 0 to terminate a subscription. > > /O > ------------------------------------------------------------------------ > > _______________________________________________ > SIP-XMPP mailing list > SIP-XMPP at xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp > From oej at edvina.net Thu Aug 7 09:52:45 2008 From: oej at edvina.net (Johansson Olle E) Date: Thu, 7 Aug 2008 16:52:45 +0200 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <489AFD6C.5050700@ericsson.com> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> <489AFD6C.5050700@ericsson.com> Message-ID: <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> Well, it was just an idea for a future feature. If the end point is an XMPP uri, I don't see the point in using a SIP uri from start. It's much of the same discussion as with Tel: URI's. In fact, SIP is designed to handle other URIs than SIP or SIPS. RFC3261 says (Section 7): "Request-URI : The Request-URI is a SIP or SIPS URI as described in Section 19.1 or a general URI (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. TheRequest- URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in ?<>?. SIP elements MAY support Request-URIs with schemes other than ?sip? and ?sips?, for example the ?tel? URI scheme of RFC 2806 [8]. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme." As you say, Salvatore, there are not that many products that support it. /O 7 aug 2008 kl. 15.49 skrev Salvatore Loreto: > Hi, > > I haven't seen any discussion about it in IETF, and I am afraid that > not only the sip related wgs > but also the xcon working group is not taking in consideration the > possibility to use an xmpp uri. > On the other end is it possible insert a SIP URI in an XMPP message? > > the possibility to insert and to use a XMPP URI in a SIP Message, > or in SIP request in general, > it is not straightforward at all, > because in order to use an XMPP URI you have modify the sip parser > in both the UAC/UAS and the proxy, > you have to provide a semantic meaning for the usage not only in the > MESSAGE request but also for all > the different SIP requests, not to talk about the headers etc. etc. > however I do not understand the advantages to insert directly an > XMPP uri in the MESSAGE request > versus the translation of a SIP URI in an XMPP URI in the GW. Can > you clarify this point? > > /Sal > > > Johansson Olle E wrote: >> >> 6 aug 2008 kl. 18.31 skrev Avshalom Houri: >> >>> >>> >>> >>> >>> sip-xmpp-bounces at xmpp.org wrote on 06/08/2008 17:55:39: >>> >>> > Johansson Olle E >>> > Sent by: sip-xmpp-bounces at xmpp.org >>> > >>> > 06/08/2008 17:57 >>> > >>> > To >>> > >>> > Avshalom Houri/Haifa/IBM at IBMIL >>> > >>> > cc >>> > >>> > sip-xmpp at xmpp.org >>> > >>> > Subject >>> > >>> > Re: [SIP-XMPP] Using XMPP uri's in SIP >>> > >>> > >>> > 6 aug 2008 kl. 14.05 skrev Avshalom Houri: >>> > >>> > > >>> > > Not aware to any work in the SIP groups themselves on this. >>> > > There was a lot of discussion on Tel URIs but not on this. >>> > I haven't seem discussion about XMPP URI's, but a lot of >>> discussions >>> > and tests on being able to handle non-SIP uri's in proxys. >>> > Tel: is just one example. >>> > Robert Sparks has been pressing on this. >>> >>> Yes but here we will need to define what should be the >>> behavior of a SIP proxy that sees XMPP URI. How it finds the >>> GW etc. >>> >> Yes. That has to be site-specific, like tel: >> >> >>> > > >>> > > >>> > > What will be the meaning of the XMPP URI in SIP? >>> > It's a valid URI to send messages to if there's a gateway in the >>> > network. >>> Meant more the meaning of operation from point of view of proxies >>> etc. I should have clarified. >>> > >>> > > >>> > > Does it assume a GW that translates the protocols etc.? >>> > Yes, it has to. >>> How to find the right GW from possible several GWs? >>> For example, if some GW supports JINGLE and the other not INVITE >>> for audio >>> should go the GW that supports JINGLE. >> I think that routing like this must also be something to configure >> in the gw. >> >> /O >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> SIP-XMPP mailing list >> SIP-XMPP at xmpp.org >> http://mail.jabber.org/mailman/listinfo/sip-xmpp >> --- * Olle E Johansson - oej at edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080807/2c871442/attachment.bin From stpeter at stpeter.im Thu Aug 7 16:35:59 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 07 Aug 2008 15:35:59 -0600 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> <489AFD6C.5050700@ericsson.com> <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> Message-ID: <489B6ABF.1010801@stpeter.im> Johansson Olle E wrote: > Well, it was just an idea for a future feature. If the end point is an > XMPP uri, I don't see the point in using a > SIP uri from start. It's much of the same discussion as with Tel: URI's. > In fact, SIP is designed to handle > other URIs than SIP or SIPS. > > RFC3261 says (Section 7): > > "Request-URI : The Request-URI is a SIP or SIPS URI as described in > Section 19.1 or a general URI > (RFC 2396 [5]). It indicates the user or service to which this request > is being addressed. TheRequest- > URI MUST NOT contain unescaped spaces or control characters and MUST NOT > be enclosed in ?<>?. > SIP elements MAY support Request-URIs with schemes other than ?sip? and > ?sips?, for example the > ?tel? URI scheme of RFC 2806 [8]. SIP elements MAY translate non-SIP > URIs using any mechanism > at their disposal, resulting in SIP URI, SIPS URI, or some other scheme." > > As you say, Salvatore, there are not that many products that support it. RFC 3921 mentions im: and pres: but not sip:/sips: schemes. See here: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-06.html#rules-remote /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080807/1500e207/attachment.bin From oej at edvina.net Fri Aug 8 01:23:23 2008 From: oej at edvina.net (Johansson Olle E) Date: Fri, 8 Aug 2008 08:23:23 +0200 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <489B6ABF.1010801@stpeter.im> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> <489AFD6C.5050700@ericsson.com> <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> <489B6ABF.1010801@stpeter.im> Message-ID: <818F8E7D-938D-4A24-A21C-439880BA9B8E@edvina.net> 7 aug 2008 kl. 23.35 skrev Peter Saint-Andre: > Johansson Olle E wrote: >> Well, it was just an idea for a future feature. If the end point is >> an XMPP uri, I don't see the point in using a >> SIP uri from start. It's much of the same discussion as with Tel: >> URI's. In fact, SIP is designed to handle >> other URIs than SIP or SIPS. >> RFC3261 says (Section 7): >> "Request-URI : The Request-URI is a SIP or SIPS URI as described in >> Section 19.1 or a general URI >> (RFC 2396 [5]). It indicates the user or service to which this >> request is being addressed. TheRequest- >> URI MUST NOT contain unescaped spaces or control characters and >> MUST NOT be enclosed in ?<>?. >> SIP elements MAY support Request-URIs with schemes other than ?sip? >> and ?sips?, for example the >> ?tel? URI scheme of RFC 2806 [8]. SIP elements MAY translate non- >> SIP URIs using any mechanism >> at their disposal, resulting in SIP URI, SIPS URI, or some other >> scheme." >> As you say, Salvatore, there are not that many products that >> support it. > > RFC 3921 mentions im: and pres: but not sip:/sips: schemes. See here: > > http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-06.html#rules-remote > Right, and SRV records can point to SIP. But there's n way to indicate in the to stanza that the recipient is a SIP uri - right. If I understand it right, the to stanzas are always jid's. Could these be extended to indicate a URI scheme? I have both a SIP and an XMPP uri that reads the same. If I start a call from a SIP client through a gateway like OpenSER/Asterisk to a Jingle endpoint I might want to indicate a SIP address as a "caller ID". Then I start a chat from Adium and want the "caller ID" to be an XMPP address. The XMPP server needs an indication on how to route. I would at some point prefer non-mangled addresses. The SIP/XMPP gateway could of course invent a way to indicate my address in SIP space, like sips-edvina.net%oej at xmpp.edvina.net - but, well, it's not very persistent. Any address that involves a server hostname is bad - that's the reason why we have mx and srv records. Let me see if I have a point here :-) - On the SIP side, there's an ability to carry XMPP uri's, even though no-one has implemented it and that may be because it's not really mentioned or suggested anywhere. - On the XMPP side, I haven't found a way to use a SIP uri in to/from stanzas. As Peter pointed out, the discovery mechanisms in a XMPP server might lead to a SIP server, but then we might have namespace collissions, as I pointed out above. Remember that this applies to both multimedia sessions, presence and IM. A phone call's caller ID should be something you can add as an persistant entry in a phone book and re-use for a long time. If that address includes a host name of a gateway, then it's usually short lived. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/af263f9f/attachment.bin From oej at edvina.net Fri Aug 8 07:09:22 2008 From: oej at edvina.net (Johansson Olle E) Date: Fri, 8 Aug 2008 14:09:22 +0200 Subject: [SIP-XMPP] XEP 0131 Message-ID: <7E52087F-B9D0-4BBE-B7FD-725C1107AD94@edvina.net> XEP 0131 (Stanza headers and Internet Metadata) defines a lot of headers that are referenced to RFC 3261 - SIP. Is there any underlying document that explains the selection and the usage? As an example, the "Call-ID" header is a bit odd, since it's only valid in the SIP call path and in my opinion should not be re-used in the XMPP path as a header, an ID for that call leg. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/ba1b6ff1/attachment.bin From dean.willis at softarmor.com Fri Aug 8 10:06:45 2008 From: dean.willis at softarmor.com (Dean Willis) Date: Fri, 8 Aug 2008 10:06:45 -0500 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <818F8E7D-938D-4A24-A21C-439880BA9B8E@edvina.net> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> <489AFD6C.5050700@ericsson.com> <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> <489B6ABF.1010801@stpeter.im> <818F8E7D-938D-4A24-A21C-439880BA9B8E@edvina.net> Message-ID: <7A9DD7E8-E00A-4062-B049-CAB7E5426FDD@softarmor.com> On Aug 8, 2008, at 1:23 AM, Johansson Olle E wrote: > > > Let me see if I have a point here :-) > > - On the SIP side, there's an ability to carry XMPP uri's, even > though no-one has implemented it and > that may be because it's not really mentioned or suggested anywhere. > > - On the XMPP side, I haven't found a way to use a SIP uri in to/ > from stanzas. As Peter pointed out, > the discovery mechanisms in a XMPP server might lead to a SIP > server, but then we might have > namespace collissions, as I pointed out above. As far as I know, most of the contact addresses in working SIP implementations are "sip:" URIs of some sort or another. Even the "tel:" URI is not widely implemented. That's because there's an expectation that these are routable addresses (as understood by the SIP stack), and RFC 3263 gives us a routing logic for finding them. In practice, people encode phone numbers as the user-part of SIP URIs. To use XMPP URI's, we'd need something like RFC 3623 that shows to how route them to a SIP node that knows how to translate them to XMPP and is "authoritative" for the target. As for caller-ID, perhaps what we have here is a need for an identity declaration that exists above the protocol level. RFC 4474 gives us an identity mechanism, but it is currently quite tied to SIP. Maybe a SAML assertion could provide the caller-ID information at a higher level? -- Dean From stpeter at stpeter.im Fri Aug 8 10:35:21 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 08 Aug 2008 09:35:21 -0600 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <7A9DD7E8-E00A-4062-B049-CAB7E5426FDD@softarmor.com> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> <489AFD6C.5050700@ericsson.com> <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> <489B6ABF.1010801@stpeter.im> <818F8E7D-938D-4A24-A21C-439880BA9B8E@edvina.net> <7A9DD7E8-E00A-4062-B049-CAB7E5426FDD@softarmor.com> Message-ID: <489C67B9.3040704@stpeter.im> Dean Willis wrote: > > On Aug 8, 2008, at 1:23 AM, Johansson Olle E wrote: > >> >> >> Let me see if I have a point here :-) >> >> - On the SIP side, there's an ability to carry XMPP uri's, even though >> no-one has implemented it and >> that may be because it's not really mentioned or suggested anywhere. >> >> - On the XMPP side, I haven't found a way to use a SIP uri in to/from >> stanzas. As Peter pointed out, >> the discovery mechanisms in a XMPP server might lead to a SIP server, >> but then we might have >> namespace collissions, as I pointed out above. > > > > As far as I know, most of the contact addresses in working SIP > implementations are "sip:" URIs of some sort or another. Even the "tel:" > URI is not widely implemented. That's because there's an expectation > that these are routable addresses (as understood by the SIP stack), and > RFC 3263 gives us a routing logic for finding them. In practice, people > encode phone numbers as the user-part of SIP URIs. > > To use XMPP URI's, we'd need something like RFC 3623 that shows to how > route them to a SIP node that knows how to translate them to XMPP and is > "authoritative" for the target. > > As for caller-ID, perhaps what we have here is a need for an identity > declaration that exists above the protocol level. RFC 4474 gives us an > identity mechanism, but it is currently quite tied to SIP. Maybe a SAML > assertion could provide the caller-ID information at a higher level? Sure, we could jump through all those hoops, but the question is why? I don't see the great benefit of all that effort. Even Olle said this would be something for the future. Let's work on more practical problems first, I say. :) Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/8efe2138/attachment.bin From oej at edvina.net Fri Aug 8 11:10:21 2008 From: oej at edvina.net (Johansson Olle E) Date: Fri, 8 Aug 2008 18:10:21 +0200 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <489C67B9.3040704@stpeter.im> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> <489AFD6C.5050700@ericsson.com> <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> <489B6ABF.1010801@stpeter.im> <818F8E7D-938D-4A24-A21C-439880BA9B8E@edvina.net> <7A9DD7E8-E00A-4062-B049-CAB7E5426FDD@softarmor.com> <489C67B9.3040704@stpeter.im> Message-ID: 8 aug 2008 kl. 17.35 skrev Peter Saint-Andre: > Dean Willis wrote: >> On Aug 8, 2008, at 1:23 AM, Johansson Olle E wrote: >>> >>> >>> Let me see if I have a point here :-) >>> >>> - On the SIP side, there's an ability to carry XMPP uri's, even >>> though no-one has implemented it and >>> that may be because it's not really mentioned or suggested anywhere. >>> >>> - On the XMPP side, I haven't found a way to use a SIP uri in to/ >>> from stanzas. As Peter pointed out, >>> the discovery mechanisms in a XMPP server might lead to a SIP >>> server, but then we might have >>> namespace collissions, as I pointed out above. >> As far as I know, most of the contact addresses in working SIP >> implementations are "sip:" URIs of some sort or another. Even the >> "tel:" URI is not widely implemented. That's because there's an >> expectation that these are routable addresses (as understood by the >> SIP stack), and RFC 3263 gives us a routing logic for finding them. >> In practice, people encode phone numbers as the user-part of SIP >> URIs. Which in practise leads to issues... >> >> To use XMPP URI's, we'd need something like RFC 3623 that shows to >> how route them to a SIP node that knows how to translate them to >> XMPP and is "authoritative" for the target. >> As for caller-ID, perhaps what we have here is a need for an >> identity declaration that exists above the protocol level. RFC 4474 >> gives us an identity mechanism, but it is currently quite tied to >> SIP. Maybe a SAML assertion could provide the caller-ID information >> at a higher level? > > Sure, we could jump through all those hoops, but the question is > why? I don't see the great benefit of all that effort. Even Olle > said this would be something for the future. Let's work on more > practical problems first, I say. :) Well, we have at least two implementations of gateways in Open Source - Asterisk and OpenSER/Kamarilio. If we lock these to something we foresee is not working, then we will get a large installed base to upgrade and teach new ways. If there's a possibility to solve this without mangling URI's the way we do it in transports, I would like to see what needs to be done to make it happen. I'll play a bit more with these applications in order to prepare the Paris SIP-XMPP workshop and then we'll dig through it in more detail there. /O (Check http://www.asipto.com for more information about the workshop). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/77bc9c01/attachment.bin From stpeter at stpeter.im Fri Aug 8 12:57:52 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 08 Aug 2008 11:57:52 -0600 Subject: [SIP-XMPP] Character set in draft-saintandre-sip-xmpp-im-00.html In-Reply-To: References: Message-ID: <489C8920.7010804@stpeter.im> Johansson Olle E wrote: > > This draft doesn't cover the case when the SIP message contains a > different character set than UTF8. > I think that should be mapped as well. Good point, I'll add some text about that. > In the other direction, it would be recommended to add a charset header, > even though SIP should assume utf8. In SIP is UTF-8 "should" or SHOULD or MUST? /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/6835279c/attachment.bin From stpeter at stpeter.im Fri Aug 8 13:13:44 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 08 Aug 2008 12:13:44 -0600 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <489B0550.8040308@ericsson.com> References: <489B0550.8040308@ericsson.com> Message-ID: <489C8CD8.2070702@stpeter.im> Salvatore Loreto wrote: > I agree with Johansson, We call him Olle. :) > in SIP it is possible to fetch only one time the subscribed state, > so it should worth to insert to sake of completeness some text to > mention in the draft also the behavior for > a SIP Subscribe with Expires: 0 used *to poke*. What does the poke return? The subscription state, or the presence state? Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/1de001f1/attachment.bin From stpeter at stpeter.im Fri Aug 8 13:19:42 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 08 Aug 2008 12:19:42 -0600 Subject: [SIP-XMPP] [Fwd: I-D Action:draft-saintandre-sip-xmpp-presence-01.txt] In-Reply-To: <4898F496.2040000@gmail.com> References: <4898B23C.7090203@stpeter.im> <4898F496.2040000@gmail.com> Message-ID: <489C8E3E.3080301@stpeter.im> Evgeniy Khramtsov wrote: > Peter Saint-Andre wrote: > >> FYI, I've updated the sip-xmpp-presence I-D based on feedback I >> received off-list. >> >> /psa > > > About section 2.3.2. Is it really useful to treat subscriptions > temporary? I don't really think so but I'm an XMPP guy. :) Shall we recommend to treat subscriptions as long-lived? > For example, in my implementation I send "unsubscribe" only > when I get a NOTIFY with Subscription-State 'terminated' and reason > *rejected*. In other cases I send "unavailable". Moreover, in the case > of terminated;reason=timeout I also try to resend SUBSCRIBE request. That seems like a reasonable approach. Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/a864f4dc/attachment-0001.bin From stpeter at stpeter.im Fri Aug 8 13:24:22 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 08 Aug 2008 12:24:22 -0600 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-im-00.html : Multipart messages In-Reply-To: <63CEBAC4-0594-455B-9FEB-EA2C44B388ED@edvina.net> References: <4504EA73-EFEE-406B-AF51-1C4F61E54F00@edvina.net> <0B9CD2D6B87A544987BD4EF2E145A94D02A91618@dencms1.corp.jabber.com> <63CEBAC4-0594-455B-9FEB-EA2C44B388ED@edvina.net> Message-ID: <489C8F56.3000504@stpeter.im> Johansson Olle E wrote: > > 6 aug 2008 kl. 17.57 skrev Joe Hildebrand: > >> As well, there's XEP-71 for XHTML over XMPP, which should be mapped into >> text/html on the SIP side. >> http://www.xmpp.org/extensions/xep-0071.html >> >> The hard part is that the SIP HTML might not be well-formed XML. There >> are utilities for fixing this, but specifying it in standards >> language... shudder. > I think the draft says something about that... > > Under section 3: > > "A SIMPLE-to-XMPP gateway SHOULD process SIP messages that contain > message bodies of type "text/html"; if so, a gateway MUST transform the > "text/html" content into XHTML content that conforms to the XHTML 1.0 > Integration Set specified in [XEP???0071]." > > A MUST directive that is not very easy to handle... I need to find a > library to help me here. That's a conditional MUST -- if you transform the SIP HTML, transform it into XMPP XHTML-IM (not some other integration set or plain HTML/XHTML itself). /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/ff771bee/attachment.bin From oej at edvina.net Fri Aug 8 15:19:59 2008 From: oej at edvina.net (Johansson Olle E) Date: Fri, 8 Aug 2008 22:19:59 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <489C8CD8.2070702@stpeter.im> References: <489B0550.8040308@ericsson.com> <489C8CD8.2070702@stpeter.im> Message-ID: <7D6F3DAA-7DC3-4425-8C80-C04B299D43D5@edvina.net> 8 aug 2008 kl. 20.13 skrev Peter Saint-Andre: > Salvatore Loreto wrote: >> I agree with Johansson, > > We call him Olle. :) > >> in SIP it is possible to fetch only one time the subscribed state, >> so it should worth to insert to sake of completeness some text to >> mention in the draft also the behavior for >> a SIP Subscribe with Expires: 0 used *to poke*. > > What does the poke return? The subscription state, or the presence > state? One NOTIFY of the specified event type. In a header, there's a subscription state which indicates that the subscription is terminated. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/3ce009dc/attachment.bin From oej at edvina.net Fri Aug 8 15:23:13 2008 From: oej at edvina.net (Johansson Olle E) Date: Fri, 8 Aug 2008 22:23:13 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-im-00.html : Multipart messages In-Reply-To: <489C8F56.3000504@stpeter.im> References: <4504EA73-EFEE-406B-AF51-1C4F61E54F00@edvina.net> <0B9CD2D6B87A544987BD4EF2E145A94D02A91618@dencms1.corp.jabber.com> <63CEBAC4-0594-455B-9FEB-EA2C44B388ED@edvina.net> <489C8F56.3000504@stpeter.im> Message-ID: <6E5935D0-E8D6-4241-9B95-863F43446975@edvina.net> 8 aug 2008 kl. 20.24 skrev Peter Saint-Andre: > Johansson Olle E wrote: >> 6 aug 2008 kl. 17.57 skrev Joe Hildebrand: >>> As well, there's XEP-71 for XHTML over XMPP, which should be >>> mapped into >>> text/html on the SIP side. >>> http://www.xmpp.org/extensions/xep-0071.html >>> >>> The hard part is that the SIP HTML might not be well-formed XML. >>> There >>> are utilities for fixing this, but specifying it in standards >>> language... shudder. >> I think the draft says something about that... >> Under section 3: >> "A SIMPLE-to-XMPP gateway SHOULD process SIP messages that contain >> message bodies of type "text/html"; if so, a gateway MUST transform >> the "text/html" content into XHTML content that conforms to the >> XHTML 1.0 Integration Set specified in [XEP???0071]." >> A MUST directive that is not very easy to handle... I need to find >> a library to help me here. > > That's a conditional MUST -- if you transform the SIP HTML, > transform it into XMPP XHTML-IM (not some other integration set or > plain HTML/XHTML itself). So this should be parsed as "either deny the message as unforwardable or you have to convert it to XHTML". Meaning that I can't convert the HTML to text and forward it. Ok. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/bf53c689/attachment.bin From stpeter at stpeter.im Fri Aug 8 15:23:54 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 08 Aug 2008 14:23:54 -0600 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <7D6F3DAA-7DC3-4425-8C80-C04B299D43D5@edvina.net> References: <489B0550.8040308@ericsson.com> <489C8CD8.2070702@stpeter.im> <7D6F3DAA-7DC3-4425-8C80-C04B299D43D5@edvina.net> Message-ID: <489CAB5A.5000204@stpeter.im> Johansson Olle E wrote: > > 8 aug 2008 kl. 20.13 skrev Peter Saint-Andre: > >> Salvatore Loreto wrote: >>> I agree with Johansson, >> >> We call him Olle. :) >> >>> in SIP it is possible to fetch only one time the subscribed state, >>> so it should worth to insert to sake of completeness some text to >>> mention in the draft also the behavior for >>> a SIP Subscribe with Expires: 0 used *to poke*. >> >> What does the poke return? The subscription state, or the presence state? > > One NOTIFY of the specified event type. > > In a header, there's a subscription state which indicates that the > subscription is terminated. It's not clear to me how that translates into XMPP -- at least, we don't have a way to poke for the subscription state (though we do have a way to poke for the presence state). /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/ee4bb932/attachment-0001.bin From stpeter at stpeter.im Fri Aug 8 15:25:05 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 08 Aug 2008 14:25:05 -0600 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-im-00.html : Multipart messages In-Reply-To: <6E5935D0-E8D6-4241-9B95-863F43446975@edvina.net> References: <4504EA73-EFEE-406B-AF51-1C4F61E54F00@edvina.net> <0B9CD2D6B87A544987BD4EF2E145A94D02A91618@dencms1.corp.jabber.com> <63CEBAC4-0594-455B-9FEB-EA2C44B388ED@edvina.net> <489C8F56.3000504@stpeter.im> <6E5935D0-E8D6-4241-9B95-863F43446975@edvina.net> Message-ID: <489CABA1.7070005@stpeter.im> Johansson Olle E wrote: > > 8 aug 2008 kl. 20.24 skrev Peter Saint-Andre: > >> Johansson Olle E wrote: >>> 6 aug 2008 kl. 17.57 skrev Joe Hildebrand: >>>> As well, there's XEP-71 for XHTML over XMPP, which should be mapped >>>> into >>>> text/html on the SIP side. >>>> http://www.xmpp.org/extensions/xep-0071.html >>>> >>>> The hard part is that the SIP HTML might not be well-formed XML. There >>>> are utilities for fixing this, but specifying it in standards >>>> language... shudder. >>> I think the draft says something about that... >>> Under section 3: >>> "A SIMPLE-to-XMPP gateway SHOULD process SIP messages that contain >>> message bodies of type "text/html"; if so, a gateway MUST transform >>> the "text/html" content into XHTML content that conforms to the XHTML >>> 1.0 Integration Set specified in [XEP???0071]." >>> A MUST directive that is not very easy to handle... I need to find a >>> library to help me here. >> >> That's a conditional MUST -- if you transform the SIP HTML, transform >> it into XMPP XHTML-IM (not some other integration set or plain >> HTML/XHTML itself). > > So this should be parsed as "either deny the message as unforwardable or > you have to convert it to XHTML". > Meaning that I can't convert the HTML to text and forward it. Yes you can. But if you pass along the HTML, you must convert it to XHTML-IM. Clearly the text needs to be clearer. :) /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/1dafd8c0/attachment.bin From oej at edvina.net Fri Aug 8 15:30:25 2008 From: oej at edvina.net (Johansson Olle E) Date: Fri, 8 Aug 2008 22:30:25 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <7D6F3DAA-7DC3-4425-8C80-C04B299D43D5@edvina.net> References: <489B0550.8040308@ericsson.com> <489C8CD8.2070702@stpeter.im> <7D6F3DAA-7DC3-4425-8C80-C04B299D43D5@edvina.net> Message-ID: <399EBB9F-0182-4E6E-8B07-4CEBBA6E21F3@edvina.net> 8 aug 2008 kl. 22.19 skrev Johansson Olle E: > > 8 aug 2008 kl. 20.13 skrev Peter Saint-Andre: > >> Salvatore Loreto wrote: >>> I agree with Johansson, >> >> We call him Olle. :) >> >>> in SIP it is possible to fetch only one time the subscribed state, >>> so it should worth to insert to sake of completeness some text to >>> mention in the draft also the behavior for >>> a SIP Subscribe with Expires: 0 used *to poke*. >> >> What does the poke return? The subscription state, or the presence >> state? > > One NOTIFY of the specified event type. > > In a header, there's a subscription state which indicates that the > subscription is terminated. To explain a bit further. In Asterisk, we support many types of SIP subscriptions. The two main ones is SIMPLE presence, which we kind of "misuse" as telephone presence - phone states. The other one is Dialog-Info, which is call states, which we also misuse and send phone states. Phone states in our case is "not registered", "free", "ringing", "hold", "on-the-phone". For a probe you get one NOTIFY with the current state. Some pbx's use this to check if you're busy before placing a call to you in a call center solution. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/0a79373e/attachment.bin From sanjsinh at cisco.com Fri Aug 8 15:40:33 2008 From: sanjsinh at cisco.com (Sanjay Sinha (sanjsinh)) Date: Fri, 8 Aug 2008 16:40:33 -0400 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <489CAB5A.5000204@stpeter.im> Message-ID: It is not a way to poke for Subscription-State, value of which will be always returned as terminated in this case, but it is to get a snapshot of the current state of the resource for which this Subscribe request is sent. So for example, if this is presence subscription, then it will return current presence state of the resource(s) identified in user part of request-uri of the message. Sanjay >-----Original Message----- >From: sip-xmpp-bounces at xmpp.org >[mailto:sip-xmpp-bounces at xmpp.org] On Behalf Of Peter Saint-Andre >Sent: Friday, August 08, 2008 4:24 PM >To: Johansson Olle E >Cc: sip-xmpp at xmpp.org >Subject: Re: [SIP-XMPP] >draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 > >Johansson Olle E wrote: >> >> 8 aug 2008 kl. 20.13 skrev Peter Saint-Andre: >> >>> Salvatore Loreto wrote: >>>> I agree with Johansson, >>> >>> We call him Olle. :) >>> >>>> in SIP it is possible to fetch only one time the subscribed state, >>>> so it should worth to insert to sake of completeness some text to >>>> mention in the draft also the behavior for a SIP Subscribe with >>>> Expires: 0 used *to poke*. >>> >>> What does the poke return? The subscription state, or the >presence state? >> >> One NOTIFY of the specified event type. >> >> In a header, there's a subscription state which indicates that the >> subscription is terminated. > >It's not clear to me how that translates into XMPP -- at >least, we don't have a way to poke for the subscription state >(though we do have a way to poke for the presence state). > >/psa > > From oej at edvina.net Fri Aug 8 16:26:04 2008 From: oej at edvina.net (Johansson Olle E) Date: Fri, 8 Aug 2008 23:26:04 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <489CAB5A.5000204@stpeter.im> References: <489B0550.8040308@ericsson.com> <489C8CD8.2070702@stpeter.im> <7D6F3DAA-7DC3-4425-8C80-C04B299D43D5@edvina.net> <489CAB5A.5000204@stpeter.im> Message-ID: <428B1706-8506-4BC0-BE70-11B7E09FA9C5@edvina.net> 8 aug 2008 kl. 22.23 skrev Peter Saint-Andre: > Johansson Olle E wrote: >> 8 aug 2008 kl. 20.13 skrev Peter Saint-Andre: >>> Salvatore Loreto wrote: >>>> I agree with Johansson, >>> >>> We call him Olle. :) >>> >>>> in SIP it is possible to fetch only one time the subscribed state, >>>> so it should worth to insert to sake of completeness some text to >>>> mention in the draft also the behavior for >>>> a SIP Subscribe with Expires: 0 used *to poke*. >>> >>> What does the poke return? The subscription state, or the presence >>> state? >> One NOTIFY of the specified event type. >> In a header, there's a subscription state which indicates that the >> subscription is terminated. > > It's not clear to me how that translates into XMPP -- at least, we > don't have a way to poke for the subscription state (though we do > have a way to poke for the presence state). > Well, it's not a poke for the subscription state, so forget that. It's a shortlived subscription that probes the presence state. Not "Keep me posted about your presence", but "what's your current presence, RIGHT NOW?" /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/794c5aff/attachment-0001.bin From stpeter at stpeter.im Fri Aug 8 16:27:45 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 08 Aug 2008 15:27:45 -0600 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <428B1706-8506-4BC0-BE70-11B7E09FA9C5@edvina.net> References: <489B0550.8040308@ericsson.com> <489C8CD8.2070702@stpeter.im> <7D6F3DAA-7DC3-4425-8C80-C04B299D43D5@edvina.net> <489CAB5A.5000204@stpeter.im> <428B1706-8506-4BC0-BE70-11B7E09FA9C5@edvina.net> Message-ID: <489CBA51.2070003@stpeter.im> Johansson Olle E wrote: > > 8 aug 2008 kl. 22.23 skrev Peter Saint-Andre: > >> Johansson Olle E wrote: >>> 8 aug 2008 kl. 20.13 skrev Peter Saint-Andre: >>>> Salvatore Loreto wrote: >>>>> I agree with Johansson, >>>> >>>> We call him Olle. :) >>>> >>>>> in SIP it is possible to fetch only one time the subscribed state, >>>>> so it should worth to insert to sake of completeness some text to >>>>> mention in the draft also the behavior for >>>>> a SIP Subscribe with Expires: 0 used *to poke*. >>>> >>>> What does the poke return? The subscription state, or the presence >>>> state? >>> One NOTIFY of the specified event type. >>> In a header, there's a subscription state which indicates that the >>> subscription is terminated. >> >> It's not clear to me how that translates into XMPP -- at least, we >> don't have a way to poke for the subscription state (though we do have >> a way to poke for the presence state). >> > Well, it's not a poke for the subscription state, so forget that. It's a > shortlived subscription that probes the presence state. > > Not "Keep me posted about your presence", but "what's your current > presence, RIGHT NOW?" OK great, so that translates into :) /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080808/8c2463ba/attachment.bin From jhildebrand at jabber.com Fri Aug 8 19:24:15 2008 From: jhildebrand at jabber.com (Joe Hildebrand) Date: Fri, 08 Aug 2008 18:24:15 -0600 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <489CBA51.2070003@stpeter.im> Message-ID: On 8/8/08 3:27 PM, "Peter Saint-Andre" wrote: > Johansson Olle E wrote: >> Well, it's not a poke for the subscription state, so forget that. It's a >> shortlived subscription that probes the presence state. >> >> Not "Keep me posted about your presence", but "what's your current >> presence, RIGHT NOW?" > > OK great, so that translates into :) Mostly. The probe may return 0+ presence stanzas on the XMPP side, and there's no good way to tell when you're "done". -- Joe Hildebrand From xramtsov at gmail.com Sat Aug 9 00:09:15 2008 From: xramtsov at gmail.com (Evgeniy Khramtsov) Date: Sat, 09 Aug 2008 15:09:15 +1000 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: References: Message-ID: <489D267B.1030207@gmail.com> Sanjay Sinha (sanjsinh) wrote: >It is not a way to poke for Subscription-State, value of which will be >always returned as terminated in this case, but it is to get a snapshot >of the current state of the resource for which this Subscribe request is >sent. So for example, if this is presence subscription, then it will >return current presence state of the resource(s) identified in user part >of request-uri of the message. > Why not just to send a SUBSCRIBE with Expires > 0 ? I think it is natural: if you want to get my NOTIFYs, you MUST subscribe to my notifications (presences in our case). -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram at jabber.ru. From oej at edvina.net Sat Aug 9 11:04:59 2008 From: oej at edvina.net (Johansson Olle E) Date: Sat, 9 Aug 2008 18:04:59 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <489D267B.1030207@gmail.com> References: <489D267B.1030207@gmail.com> Message-ID: 9 aug 2008 kl. 07.09 skrev Evgeniy Khramtsov: > Sanjay Sinha (sanjsinh) wrote: > >> It is not a way to poke for Subscription-State, value of which will >> be >> always returned as terminated in this case, but it is to get a >> snapshot >> of the current state of the resource for which this Subscribe >> request is >> sent. So for example, if this is presence subscription, then it will >> return current presence state of the resource(s) identified in user >> part >> of request-uri of the message. >> > Why not just to send a SUBSCRIBE with Expires > 0 ? I think it is > natural: if you want to get my NOTIFYs, you MUST subscribe to my > notifications (presences in our case). We're not discussing changing SIP standards - this already exists and are implemented. We need to make sure it works in a gateway situation. /O ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080809/b7e9a3b9/attachment.bin From oej at edvina.net Sat Aug 9 11:16:27 2008 From: oej at edvina.net (Johansson Olle E) Date: Sat, 9 Aug 2008 18:16:27 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: References: Message-ID: <91615AE2-C81E-46E7-AEE8-73B97D9E5845@edvina.net> 9 aug 2008 kl. 02.24 skrev Joe Hildebrand: > On 8/8/08 3:27 PM, "Peter Saint-Andre" wrote: > >> Johansson Olle E wrote: >>> Well, it's not a poke for the subscription state, so forget that. >>> It's a >>> shortlived subscription that probes the presence state. >>> >>> Not "Keep me posted about your presence", but "what's your current >>> presence, RIGHT NOW?" >> >> OK great, so that translates into :) > > Mostly. The probe may return 0+ presence stanzas on the XMPP side, > and > there's no good way to tell when you're "done". Trying to check SIP timers here. RFC 3265 says in 3.1.4: "This SUBSCRIBE request will be confirmed with a final response. 200- class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately." "Immediately" is an interesting definition. This follows: "Confirmation of Subscription Creation The subscriber can expect to receive a NOTIFY message from each node which has processed a successful subscription or subscription refresh. Until the first NOTIFY message arrives, the subscriber should consider the state of the subscribed resource to be in a neutral state." "Due to the potential for both out-of-order messages and forking, the subscriber MUST be prepared to receive NOTIFY messages before the SUBSCRIBE transaction has completed." And later: "Confirmation of Subscription Creation/Refreshing Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body. See section 3.2.2. for further details on NOTIFY message generation. Note that a NOTIFY message is always sent immediately after any 200- class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized." So there's really no option to wait for a stanza... I guess the only option to handle Expires:0 if we can't get or already know the state is to send a "neutral" reply without a body. This "neutral state" depends on the event package, that is the type of subscription. A solution here would be * If a SIP subscription meant for probing arrives, with Expires set to 0, the gateway needs to check if it there's an existing authorization for this subscription. If not, answer 202 Accepted. * If the SIP uri is authorized in the XMPP domain, and the gateway knows the state of the subscription target, a NOTIFY with the state is sent immediatelly after sending 200 OK. Otherwise, if the state is unknown, the gateway sends a 200 OK and a NOTIFY that terminates the subscription, but with no body part. Or can we rely on ? /O /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080809/74a57c81/attachment-0001.bin From xramtsov at gmail.com Sat Aug 9 23:28:54 2008 From: xramtsov at gmail.com (Evgeniy Khramtsov) Date: Sun, 10 Aug 2008 14:28:54 +1000 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <91615AE2-C81E-46E7-AEE8-73B97D9E5845@edvina.net> References: <91615AE2-C81E-46E7-AEE8-73B97D9E5845@edvina.net> Message-ID: <489E6E86.4020409@gmail.com> Johansson Olle E wrote: > Or can we rely on ? I don't think so. Firstly, we cannot immediatelly send NOTIFY with presence document since we don't know current presence state (in the case we don't cache them). In the second, as Joe Hildebrand mentioned above, the probe may return zero or multiple presence stanzas and that's a problem because we don't know which presence stanza we need to convert to PIDF (if any). -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram at jabber.ru. From sanjsinh at cisco.com Sun Aug 10 20:24:34 2008 From: sanjsinh at cisco.com (Sanjay Sinha (sanjsinh)) Date: Sun, 10 Aug 2008 21:24:34 -0400 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <489D267B.1030207@gmail.com> Message-ID: Pl. see inline .. >-----Original Message----- >From: sip-xmpp-bounces at xmpp.org >[mailto:sip-xmpp-bounces at xmpp.org] On Behalf Of Evgeniy Khramtsov >Sent: Saturday, August 09, 2008 1:09 AM >To: sip-xmpp at xmpp.org >Subject: Re: [SIP-XMPP] >draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 > >Sanjay Sinha (sanjsinh) wrote: > >>It is not a way to poke for Subscription-State, value of >which will be >>always returned as terminated in this case, but it is to get >a snapshot >>of the current state of the resource for which this Subscribe request >>is sent. So for example, if this is presence subscription, >then it will >>return current presence state of the resource(s) identified in user >>part of request-uri of the message. >> >Why not just to send a SUBSCRIBE with Expires > 0 ? I think it is >natural: if you want to get my NOTIFYs, you MUST subscribe to >my notifications (presences in our case). The use case for it be that the subscriber is just interested in knowing what the state of the resource is at that time and it does not want to maintain long lived subscription, go through the overhead of establishing a subscription, refreshing it, unsubscribing etc. If it sent a Subscribe with Expires > 0, then after getting the initial Notify, and it was only interested in one state, then it will have to send an Unsubscribe after getting the Notify. Sending initial Subscribe with Expires: 0, reduces extra messging associated with UnSubscribe/200 OK and then final Notify/200 OK Sanjay > >-- >Regards, >Evgeniy Khramtsov, ProcessOne. >xmpp:xram at jabber.ru. > > > From salvatore.loreto at ericsson.com Sun Aug 10 04:05:11 2008 From: salvatore.loreto at ericsson.com (Salvatore Loreto) Date: Sun, 10 Aug 2008 12:05:11 +0300 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> <489AFD6C.5050700@ericsson.com> <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> <489B6ABF.1010801@stpeter.im> <818F8E7D-938D-4A24-A21C-439880BA9B8E@edvina.net> <7A9DD7E8-E00A-4062-B049-CAB7E5426FDD@softarmor.com> <489C67B9.3040704@stpeter.im> Message-ID: <489EAF47.4000608@ericsson.com> Hi Olle, learn from the field experience is always an important lesson and essential to understand. I agree with Peter, that even if this is an interesting problem, at present there is not a great benefit in solving it. If a terminal is only SIP, it is improbably that it will receive or become aware of xmpp uri to contact a friend. Using an identity declaration that exists above protocol levels seems an interesting proposal that should be investigate. However it should be great understand how the current mechanism described in the draft (that let the gw translate the address) is not enough as all the other possible issues that will be discovered during the Paris SIP-XMPP workshop. Do you know if the workshop will produce a some document listing all the issues? Sal Johansson Olle E wrote: > > 8 aug 2008 kl. 17.35 skrev Peter Saint-Andre: > >> Dean Willis wrote: >>> On Aug 8, 2008, at 1:23 AM, Johansson Olle E wrote: >>>> >>>> >>>> Let me see if I have a point here :-) >>>> >>>> - On the SIP side, there's an ability to carry XMPP uri's, even >>>> though no-one has implemented it and >>>> that may be because it's not really mentioned or suggested anywhere. >>>> >>>> - On the XMPP side, I haven't found a way to use a SIP uri in >>>> to/from stanzas. As Peter pointed out, >>>> the discovery mechanisms in a XMPP server might lead to a SIP >>>> server, but then we might have >>>> namespace collissions, as I pointed out above. >>> As far as I know, most of the contact addresses in working SIP >>> implementations are "sip:" URIs of some sort or another. Even the >>> "tel:" URI is not widely implemented. That's because there's an >>> expectation that these are routable addresses (as understood by the >>> SIP stack), and RFC 3263 gives us a routing logic for finding them. >>> In practice, people encode phone numbers as the user-part of SIP URIs. > Which in practise leads to issues... >>> >>> To use XMPP URI's, we'd need something like RFC 3623 that shows to >>> how route them to a SIP node that knows how to translate them to >>> XMPP and is "authoritative" for the target. >>> As for caller-ID, perhaps what we have here is a need for an >>> identity declaration that exists above the protocol level. RFC 4474 >>> gives us an identity mechanism, but it is currently quite tied to >>> SIP. Maybe a SAML assertion could provide the caller-ID information >>> at a higher level? >> >> Sure, we could jump through all those hoops, but the question is why? >> I don't see the great benefit of all that effort. Even Olle said this >> would be something for the future. Let's work on more practical >> problems first, I say. :) > > Well, we have at least two implementations of gateways in Open Source > - Asterisk and OpenSER/Kamarilio. If we lock these to something we > foresee is not working, then we will get a large installed base to > upgrade and teach new ways. If there's a possibility to solve this > without mangling URI's the way we do it in transports, I would like to > see what needs to be done to make it happen. > > I'll play a bit more with these applications in order to prepare the > Paris SIP-XMPP workshop and then we'll dig through it in more detail > there. > > > /O > > (Check http://www.asipto.com for more information about the workshop). > ------------------------------------------------------------------------ > > > From oej at edvina.net Mon Aug 11 04:58:23 2008 From: oej at edvina.net (Johansson Olle E) Date: Mon, 11 Aug 2008 11:58:23 +0200 Subject: [SIP-XMPP] Using XMPP uri's in SIP In-Reply-To: <489EAF47.4000608@ericsson.com> References: <4273A1E1-FD76-439F-9D64-21168D702F05@edvina.net> <5FC8E011-73BB-4E25-9EF9-A5DCE21B178E@edvina.net> <489AFD6C.5050700@ericsson.com> <8754429B-6270-410E-A386-9FE7A44ED637@edvina.net> <489B6ABF.1010801@stpeter.im> <818F8E7D-938D-4A24-A21C-439880BA9B8E@edvina.net> <7A9DD7E8-E00A-4062-B049-CAB7E5426FDD@softarmor.com> <489C67B9.3040704@stpeter.im> <489EAF47.4000608@ericsson.com> Message-ID: <4E6B29B8-8316-45AD-805A-77A8D5B354A4@edvina.net> 10 aug 2008 kl. 11.05 skrev Salvatore Loreto: > Hi Olle, > > learn from the field experience is always an important lesson and > essential to understand. > I agree with Peter, that even if this is an interesting problem, at > present there is not a great benefit in solving it. > If a terminal is only SIP, it is improbably that it will receive > or become aware of xmpp uri to contact a friend. > Using an identity declaration that exists above protocol levels > seems an interesting proposal that should be investigate. Well, I understand that changing clients will take a long time, but within the infrastructure it's easier. And even if it takes a long time - if we think it's the right way, we should propose it and work for a change. The benefits has to be very high in order for anyone to want to do that, though. We'll see. > > > However it should be great understand how the current mechanism > described in the draft (that let the gw translate > the address) is not enough as all the other possible issues that > will be discovered during the Paris SIP-XMPP workshop. > Do you know if the workshop will produce a some document listing all > the issues? Wll, that depends on everyone that participates. Hopefully we'll get enough people with experience of either or both protocols so that we can revice all these documents and come up with a task list - or proposals on how to fix it. Cheers, /Olle -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080811/ced991ea/attachment.bin From oej at edvina.net Mon Aug 11 05:01:36 2008 From: oej at edvina.net (Johansson Olle E) Date: Mon, 11 Aug 2008 12:01:36 +0200 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <489EB1CF.1030303@ericsson.com> References: <91615AE2-C81E-46E7-AEE8-73B97D9E5845@edvina.net> <489EB1CF.1030303@ericsson.com> Message-ID: <44332BB3-ADB1-4C22-B317-4D68C03AC624@edvina.net> 10 aug 2008 kl. 11.15 skrev Salvatore Loreto: > Hi Olle, > > I think your last proposal if correct at least from a SIP point of > view, > if it is not immediate gather all the presence information with the > xmpp translation , > the sip side of the GW should answer to a SUBSCRIBE with expires:0 > with a 202 Accepted (pending status) and then with all the > information are gathered > send a NOTIFY with the presence status. > Well, now you're mixing two different cases. The 202 accepted is "pending authorization", it's not "you're on hold.". If you want to tell someone to come back later you should propably send an error code, then a suggested retry time in a header in the error. That's also a solution - to force the client to retry (if it wants to). We have to send something immedieately - and my proposal was to send a NOTIFY without a notification to terminate the subscription and basically say "sorry lad, we can't help you today." - or send a proper NOTIFY if we have the current presence available. /O > /Sal > > Johansson Olle E wrote: >> >> 9 aug 2008 kl. 02.24 skrev Joe Hildebrand: >> >>> On 8/8/08 3:27 PM, "Peter Saint-Andre" wrote: >>> >>>> Johansson Olle E wrote: >>>>> Well, it's not a poke for the subscription state, so forget >>>>> that. It's a >>>>> shortlived subscription that probes the presence state. >>>>> >>>>> Not "Keep me posted about your presence", but "what's your current >>>>> presence, RIGHT NOW?" >>>> >>>> OK great, so that translates into :) >>> >>> Mostly. The probe may return 0+ presence stanzas on the XMPP >>> side, and >>> there's no good way to tell when you're "done". >> >> Trying to check SIP timers here. RFC 3265 says in 3.1.4: >> >> "This SUBSCRIBE request will be confirmed with a final response. >> 200-class responses indicate that the >> subscription has been accepted, and that a NOTIFY will be sent >> immediately." >> >> "Immediately" is an interesting definition. >> >> This follows: >> >> "Confirmation of Subscription Creation The subscriber can expect to >> receive a NOTIFY message from >> each node which has processed a successful subscription or >> subscription refresh. Until the first NOTIFY >> message arrives, the subscriber should consider the state of the >> subscribed resource to be in a neutral state." >> >> "Due to the potential for both out-of-order messages and forking, >> the subscriber MUST be prepared to receive >> NOTIFY messages before the SUBSCRIBE transaction has completed." >> >> And later: >> >> "Confirmation of Subscription Creation/Refreshing Upon successfully >> accepting or refreshing a subscription, >> notifiers MUST send a NOTIFY message immediately to communicate the >> current resource state >> to the subscriber. This NOTIFY message is sent on the same dialog >> as created by the SUBSCRIBE response. >> If the resource has no meaningful state at the time that the >> SUBSCRIBE message is processed, this >> NOTIFY message MAY contain an empty or neutral body. See section >> 3.2.2. for further details on NOTIFY >> message generation. >> Note that a NOTIFY message is always sent immediately after any 200- >> class response to a SUBSCRIBE >> request, regardless of whether the subscription has already been >> authorized." >> >> So there's really no option to wait for a stanza... I guess the >> only option to handle Expires:0 if we can't >> get or already know the state is to send a "neutral" reply without >> a body. This "neutral state" depends on >> the event package, that is the type of subscription. >> >> A solution here would be >> >> * If a SIP subscription meant for probing arrives, with Expires set >> to 0, the gateway needs to check if it >> there's an existing authorization for this subscription. If not, >> answer 202 Accepted. >> * If the SIP uri is authorized in the XMPP domain, and the gateway >> knows the state of the subscription target, >> a NOTIFY with the state is sent immediatelly after sending 200 >> OK. Otherwise, if the state is unknown, >> the gateway sends a 200 OK and a NOTIFY that terminates the >> subscription, but with no body part. >> >> Or can we rely on ? >> >> /O >> >> >> >> >> /O >> ------------------------------------------------------------------------ >> >> >> > --- * Olle E Johansson - oej at edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080811/d4cd8a63/attachment.bin From ka-el at laposte.net Wed Aug 13 16:05:43 2008 From: ka-el at laposte.net (kael) Date: Wed, 13 Aug 2008 23:05:43 +0200 Subject: [SIP-XMPP] Message Summary, Message Waiting Indication and Pubsub/PEP Message-ID: <48A34CA7.7080900@laposte.net> Hello, I'm wondering if there is any plan to map SIP message summary events and MWI [1] into XMPP. This mapping may be an opportunity to standardize several types of notifications into XMPP. Message summary events and MWI could be mapped into PEP messages to take advantage of node auto-discovery. So there would be voicemail and fax PEP notifications for SIP-XMPP interworking. Derived from this mapping and from draft-ietf-sieve-notify-xmpp [2], there could be then mail PEP notifications. Draft-ietf-sieve-notify-xmpp already defines mail notifications into XMPP but it might be better if it used PEP, IMHO, specially to ease message filtering at the UI level. Also, two drafts are being written to define mail notifications over SIP, one using message summary and MWI [3], the other using SIP messages [4]. And there also exists a private XMPP extension for GMail notification [5] and another one used by the MobileMe iPhone notification service [6]. Hence it could be relevant to create new XMPP message types for mail, voicemail and fax notifications. These messages would be used for SIP-XMPP interworking, but also by XMPP mail notifications gateways for example. And finally, perhaps that the Phone Integration proto-XEP [7], used for the Openfire-Asterisk integration, could be standardized under this umbrella too. [1] [2] [3] [4] [5] [6] [7] -- kael From salvatore.loreto at ericsson.com Thu Aug 14 02:45:59 2008 From: salvatore.loreto at ericsson.com (Salvatore Loreto) Date: Thu, 14 Aug 2008 10:45:59 +0300 Subject: [SIP-XMPP] draft-saintandre-sip-xmpp-presence-01.html : Subscribe with expires:0 In-Reply-To: <44332BB3-ADB1-4C22-B317-4D68C03AC624@edvina.net> References: <91615AE2-C81E-46E7-AEE8-73B97D9E5845@edvina.net> <489EB1CF.1030303@ericsson.com> <44332BB3-ADB1-4C22-B317-4D68C03AC624@edvina.net> Message-ID: <48A3E2B7.6000809@ericsson.com> Johansson Olle E wrote: > > 10 aug 2008 kl. 11.15 skrev Salvatore Loreto: > >> Hi Olle, >> >> I think your last proposal if correct at least from a SIP point of view, >> if it is not immediate gather all the presence information with the >> xmpp translation , >> the sip side of the GW should answer to a SUBSCRIBE with expires:0 >> with a 202 Accepted (pending status) and then with all the >> information are gathered >> send a NOTIFY with the presence status. >> > Well, now you're mixing two different cases. The 202 accepted is > "pending authorization", > it's not "you're on hold.". I think you can generalize and say with 202 that your subscription is pending for some unspecified reason so the effect is similar to an on hold state > If you want to tell someone to come back later you should propably > send an error code, then a suggested retry time in a header in the error. I don't think is an error, you should answer with a new xxx code saying that the subscription was successful but the server doesn't have any information at the moment then insert and header that force/suggest the client to retry after... However I think that answering with a pending code will force in some way the gateway to gather the information it does not have, and will be in someway more efficient in number of message exchanged > That's also > a solution - to force the client to retry (if it wants to). > > We have to send something immedieately - and my proposal was to send a > NOTIFY > without a notification to terminate the subscription and basically say > "sorry lad, > we can't help you today." - or send a proper NOTIFY if we have the > current > presence available. IMHO a xxx code answer should be more correct that and efficient then an empty NOTIFY your proposal of terminating the subscription with an empty NOTIFY means the exchange of 8 message (Subscribe->, 200 OK<-, Notify <-, 200 OK->,Subscribe->, 200 OK<-, Notify <-, 200 OK->) sending a 2xx answer will take only 6 message (Subscribe->, xxx XX<-, Subscribe->, 200 OK<-, Notify <-, 200 OK->) moreover if the time to gather the information is enough short, the pending answer will be more efficient (Subscribe->, 202 XXX<-, 200 XXX<-, Notify <-, 200 OK->) /Sal > > /O > >> /Sal >> >> Johansson Olle E wrote: >>> >>> 9 aug 2008 kl. 02.24 skrev Joe Hildebrand: >>> >>>> On 8/8/08 3:27 PM, "Peter Saint-Andre" wrote: >>>> >>>>> Johansson Olle E wrote: >>>>>> Well, it's not a poke for the subscription state, so forget that. >>>>>> It's a >>>>>> shortlived subscription that probes the presence state. >>>>>> >>>>>> Not "Keep me posted about your presence", but "what's your current >>>>>> presence, RIGHT NOW?" >>>>> >>>>> OK great, so that translates into :) >>>> >>>> Mostly. The probe may return 0+ presence stanzas on the XMPP side, >>>> and >>>> there's no good way to tell when you're "done". >>> >>> Trying to check SIP timers here. RFC 3265 says in 3.1.4: >>> >>> "This SUBSCRIBE request will be confirmed with a final response. >>> 200-class responses indicate that the >>> subscription has been accepted, and that a NOTIFY will be sent >>> immediately." >>> >>> "Immediately" is an interesting definition. >>> >>> This follows: >>> >>> "Confirmation of Subscription Creation The subscriber can expect to >>> receive a NOTIFY message from >>> each node which has processed a successful subscription or >>> subscription refresh. Until the first NOTIFY >>> message arrives, the subscriber should consider the state of the >>> subscribed resource to be in a neutral state." >>> >>> "Due to the potential for both out-of-order messages and forking, >>> the subscriber MUST be prepared to receive >>> NOTIFY messages before the SUBSCRIBE transaction has completed." >>> >>> And later: >>> >>> "Confirmation of Subscription Creation/Refreshing Upon successfully >>> accepting or refreshing a subscription, >>> notifiers MUST send a NOTIFY message immediately to communicate the >>> current resource state >>> to the subscriber. This NOTIFY message is sent on the same dialog as >>> created by the SUBSCRIBE response. >>> If the resource has no meaningful state at the time that the >>> SUBSCRIBE message is processed, this >>> NOTIFY message MAY contain an empty or neutral body. See section >>> 3.2.2. for further details on NOTIFY >>> message generation. >>> Note that a NOTIFY message is always sent immediately after any >>> 200-class response to a SUBSCRIBE >>> request, regardless of whether the subscription has already been >>> authorized." >>> >>> So there's really no option to wait for a stanza... I guess the only >>> option to handle Expires:0 if we can't >>> get or already know the state is to send a "neutral" reply without a >>> body. This "neutral state" depends on >>> the event package, that is the type of subscription. >>> >>> A solution here would be >>> >>> * If a SIP subscription meant for probing arrives, with Expires set >>> to 0, the gateway needs to check if it >>> there's an existing authorization for this subscription. If not, >>> answer 202 Accepted. >>> * If the SIP uri is authorized in the XMPP domain, and the gateway >>> knows the state of the subscription target, >>> a NOTIFY with the state is sent immediatelly after sending 200 OK. >>> Otherwise, if the state is unknown, >>> the gateway sends a 200 OK and a NOTIFY that terminates the >>> subscription, but with no body part. >>> >>> Or can we rely on ? >>> >>> /O >>> >>> >>> >>> >>> /O >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >> > > --- > * Olle E Johansson - oej at edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > From stpeter at stpeter.im Wed Aug 13 23:07:49 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 13 Aug 2008 22:07:49 -0600 Subject: [SIP-XMPP] Message Summary, Message Waiting Indication and Pubsub/PEP In-Reply-To: <48A34CA7.7080900@laposte.net> References: <48A34CA7.7080900@laposte.net> Message-ID: <48A3AF95.5040700@stpeter.im> kael wrote: > Hello, > > I'm wondering if there is any plan to map SIP message summary events and > MWI [1] into XMPP. Not yet, as least that I know of. > This mapping may be an opportunity to standardize several types of > notifications into XMPP. > > Message summary events and MWI could be mapped into PEP messages to take > advantage of node auto-discovery. So there would be voicemail and fax > PEP notifications for SIP-XMPP interworking. > > Derived from this mapping and from draft-ietf-sieve-notify-xmpp [2], > there could be then mail PEP notifications. > > Draft-ietf-sieve-notify-xmpp already defines mail notifications into > XMPP but it might be better if it used PEP, IMHO, specially to ease > message filtering at the UI level. IIRC we didn't want a dependency on PEP at the time. > Also, two drafts are being written to define mail notifications over > SIP, one using message summary and MWI [3], the other using SIP messages > [4]. > > And there also exists a private XMPP extension for GMail notification > [5] and another one used by the MobileMe iPhone notification service [6]. > > Hence it could be relevant to create new XMPP message types for mail, > voicemail and fax notifications. These messages would be used for > SIP-XMPP interworking, but also by XMPP mail notifications gateways for > example. When you say "new XMPP message types" do you mean new values of the element's 'type' attribute? > And finally, perhaps that the Phone Integration proto-XEP [7], used for > the Openfire-Asterisk integration, could be standardized under this > umbrella too. Gosh, those are a lot of work items. :) I'm already overloaded... But I agree that some of these use cases are interesting. Joe Hildebrand and I have been talking about new-mail notifications over XMPP for ages now, but haven't gotten around to writing up a spec about it. Maybe now that so many people have blazed a path here it would be good for us to pave it. :) /psa /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080813/f99bfc37/attachment.bin From ka-el at laposte.net Thu Aug 14 13:08:51 2008 From: ka-el at laposte.net (kael) Date: Thu, 14 Aug 2008 20:08:51 +0200 Subject: [SIP-XMPP] Message Summary, Message Waiting Indication and Pubsub/PEP In-Reply-To: <48A3AF95.5040700@stpeter.im> References: <48A34CA7.7080900@laposte.net> <48A3AF95.5040700@stpeter.im> Message-ID: <48A474B3.8080402@laposte.net> Peter Saint-Andre wrote: > kael wrote: >> >> Draft-ietf-sieve-notify-xmpp already defines mail notifications into >> XMPP but it might be better if it used PEP, IMHO, specially to ease >> message filtering at the UI level. > > IIRC we didn't want a dependency on PEP at the time. From oej at edvina.net Fri Aug 15 01:04:21 2008 From: oej at edvina.net (Johansson Olle E) Date: Fri, 15 Aug 2008 08:04:21 +0200 Subject: [SIP-XMPP] Message Summary, Message Waiting Indication and Pubsub/PEP In-Reply-To: <48A474B3.8080402@laposte.net> References: <48A34CA7.7080900@laposte.net> <48A3AF95.5040700@stpeter.im> <48A474B3.8080402@laposte.net> Message-ID: <870D078B-DEC5-4BD9-BF44-960396182BF2@edvina.net> >> > > The SIP-XMPP mapping looks like a good start considering it would use > message summary and MWI which look interesting to use as they convey > the > content of notification and a count of messages. In the SIP case, it also has the SIP contact to use for retrieving those messages, I.E., calling your voicemail service. In the case of Asterisk, we could propably send these directly over XMPP with a XMPP uri that points to a jingle endpoint for your voicemail. /O -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2207 bytes Desc: not available Url : http://mail.jabber.org/pipermail/sip-xmpp/attachments/20080815/9bdaf521/attachment.bin From xramtsov at gmail.com Thu Aug 21 03:37:15 2008 From: xramtsov at gmail.com (Evgeniy Khramtsov) Date: Thu, 21 Aug 2008 18:37:15 +1000 Subject: [SIP-XMPP] [Fwd: I-D Action:draft-saintandre-sip-xmpp-presence-01.txt] In-Reply-To: <489C8E3E.3080301@stpeter.im> References: <4898B23C.7090203@stpeter.im> <4898F496.2040000@gmail.com> <489C8E3E.3080301@stpeter.im> Message-ID: <48AD293B.8040808@gmail.com> Peter Saint-Andre wrote: > Evgeniy Khramtsov wrote: > >> About section 2.3.2. Is it really useful to treat subscriptions >> temporary? > > > I don't really think so but I'm an XMPP guy. :) Shall we recommend to > treat subscriptions as long-lived? FYI, MS Office Communicator sends SUBSCRIBE with Expires:0 once per minute. Who really wants to get 'unsubscribe' presences every minute? :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram at jabber.ru. From miconda at gmail.com Thu Aug 21 08:47:29 2008 From: miconda at gmail.com (Daniel-Constantin Mierla) Date: Thu, 21 Aug 2008 16:47:29 +0300 Subject: [SIP-XMPP] SIP/SIMPLE-XMPP Developer Workshop 2008 In-Reply-To: <487CA586.2010305@gmail.com> References: <487CA586.2010305@gmail.com> Message-ID: <48AD71F1.5020704@gmail.com> Hello, sending a reminder for those that joined later the mailing list. Just one week and a half to the event. http://www.asipto.com/index.php/simple-xmpp-developer-workshop-2008/ Cheers, Daniel On 07/15/08 16:26, Daniel-Constantin Mierla wrote: > Hello, > > for those interested in SIP/SIMPLE - XMPP > interoperability, there is going to be a workshop in Paris for > developers in the first week of September. > > Detailed description of the event follows. > > Best regards, > Daniel > > > SIMPLE-XMPP Developer Workshop 2008 > > SIP/SIMPLE and XMPP share a lot of concepts but they are different in > many aspects. Being nowadays the leading open protocols for voice, > video, instant messaging and presence, the interconnection between them > creates an unified communication environment for users in both sides. > The workshop aims to bring together people with large expertise in both > protocols, interested in development, testing and deployment of > SIP/SIMPLE-XMPP solutions. With a permanent focus on innovation, the > participants cover open source projects to private enterprises. You can > join the event for free. > > Date: September 2-5, 2008 > Place: INRIA, Paris, France > > Main organizers: > - Philippe Sultan, INRIA - contributor to the XMPP/Jingle support in > Asterisk, member of XMPP Standards Foundation > - Olle E. Johansson, Edvina - main SIP developer of Asterisk > - Daniel-Constantin Mierla, Asipto - co-founder Openser, developer of > XMPP/Jabber gateway > > Goal: > - kick up simple-xmpp interoperability > > Agenda guidelines: > - identify common issues of simple-xmpp interoperability > - define best-practice solutions and workarounds of delicate issues > - coding sessions in existing applications such as Asterisk, Openser, > Jabberd, Freeswitch, eJabberd, libraries, client applications, etc. > - testing sessions > - reports about past experiences and results of the workshop > > Target participants: > - developers of simple-xmpp products > - people interested in testing simple-xmpp products > - people interested in building simple-xmpp communication environments > > Cost: > - free registration (everybody pays for its traveling and accommodation) > > Registration: > - via e-mail at simple-xmpp at asipto.com > - please write the motivation to participate and add bullets into agenda > if you like to approach new subjects. The organizers reserve the right > to select a group of people that will contribute most as this is mainly > a workshop to approach issues, test interoperability and design new > solutions. > - updates about the event are posted at: > http://www.asipto.com/index.php/simple-xmpp-developer-workshop-2008/ > > Size: > - up to 20 people > > As of Jul 15, 2008, participating companies are: > - INRIA - http://www.inria.fr - SIP-XMPP interoperability in Asterisk > (http://www.asterisk.org) > - Edvina - http://www.edvina.net - SIP-XMPP interoperability in Asterisk > (http://www.asterisk.org) > - AG Projects - http://www.ag-projects.com - MSRP-XMPP Interoperability > (http://www.msrprelay.org) > - Asipto - http://www.asipto.com - SIP-XMPP interoperability in Openser > (http://www.openser.org) > > General discussions about sip-xmpp can be conducted via mailing list: > sip-xmpp [at] xmpp.org > http://mail.jabber.org/mailman/listinfo/sip-xmpp > > -- Daniel-Constantin Mierla http://www.asipto.com