From darco at deepdarc.com Thu Aug 13 20:17:39 2009 From: darco at deepdarc.com (Robert Quattlebaum) Date: Thu, 13 Aug 2009 18:17:39 -0700 Subject: [Jingle] Terminating a session In-Reply-To: <200907290032.45180.detlev.casanova@gmail.com> References: <200907290032.45180.detlev.casanova@gmail.com> Message-ID: <69EC3C4C-9D19-473E-8F62-92AB60D9B9D1@deepdarc.com> On Jul 28, 2009, at 3:32 PM, Detlev Casanova wrote: > If my session has 2 contents, one for > audio and one for video but the webcam isn't plugged in. Does it > mean that I > have to terminate the session even though the audio content will > work ? No, that is not a fatal condition. The client without the webcam can do either of the following: Send a content-info to change the senders attribute to not include the local client. This would allow your local client to still be able to view the video from the webcam of your peer, and lets your peer know not to expect any video from your local client. Send a content-remove message for the media='video' content. If a content-remove message is sent and the peer sends back an error with a type of something other than 'wait',(Or ends up retrying to send content-remove too many times unsuccessfully) then you would send a session-terminate with a reason of . __________________ Robert Quattlebaum Jabber: darco at deepdarc.com eMail: darco at deepdarc.com www: http://www.deepdarc.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From darco at deepdarc.com Thu Aug 13 20:31:08 2009 From: darco at deepdarc.com (Robert Quattlebaum) Date: Thu, 13 Aug 2009 18:31:08 -0700 Subject: [Jingle] Destination address information in session-initiate In-Reply-To: <4A69D38A.6050100@codian.com> References: <4A69D38A.6050100@codian.com> Message-ID: <7B745B80-6225-43D7-B79B-1DC68F24109F@deepdarc.com> On Jul 24, 2009, at 8:30 AM, Paul Witty wrote: > A gateway may only be registered as a single XMPP client, but permit > calling to any number of SIP endpoints on the other side; an MCU can > host multiple conferences etc. This is not true. In fact, this would be the worst way to implement a SIP gateway, or any other type of XMPP gateway. This problem is best solved by making the gateway a server component, or even a standalone server (that accepts S2S connections, not C2S connections) itself. See "XEP-0100: Gateway Interaction" for more information. For example, lets say that you wanted to call , using the SIP bridge sipbridge.example.net. The client, who knows about sipbridge.example.net already, would then translate the SIP address blah at example.com into blah \40example.com at sipbridge.example.net. You would initiate a jingle session with that address. Conferences could likely be handled in a similar fashion. __________________ Robert Quattlebaum Jabber: darco at deepdarc.com eMail: darco at deepdarc.com www: http://www.deepdarc.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From darco at deepdarc.com Thu Aug 13 20:33:39 2009 From: darco at deepdarc.com (Robert Quattlebaum) Date: Thu, 13 Aug 2009 18:33:39 -0700 Subject: [Jingle] Terminating a session In-Reply-To: <69EC3C4C-9D19-473E-8F62-92AB60D9B9D1@deepdarc.com> References: <200907290032.45180.detlev.casanova@gmail.com> <69EC3C4C-9D19-473E-8F62-92AB60D9B9D1@deepdarc.com> Message-ID: On Aug 13, 2009, at 6:17 PM, Robert Quattlebaum wrote: > On Jul 28, 2009, at 3:32 PM, Detlev Casanova wrote: > >> If my session has 2 contents, one for >> audio and one for video but the webcam isn't plugged in. Does it >> mean that I >> have to terminate the session even though the audio content will >> work ? > > No, that is not a fatal condition. The client without the webcam can > do either of the following: > > Send a content-info to change the senders attribute to not include > the local client. This would allow your local client to still be > able to view the video from the webcam of your peer, and lets your > peer know not to expect any video from your local client. > Send a content-remove message for the media='video' content. > > If a content-remove message is sent and the peer sends back an error > with a type of something other than 'wait',(Or ends up retrying to > send content-remove too many times unsuccessfully) then you would > send a session-terminate with a reason of . Oops, I meant content-modify, not content-info. __________________ Robert Quattlebaum Jabber: darco at deepdarc.com eMail: darco at deepdarc.com www: http://www.deepdarc.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From darco at deepdarc.com Thu Aug 13 20:57:28 2009 From: darco at deepdarc.com (Robert Quattlebaum) Date: Thu, 13 Aug 2009 18:57:28 -0700 Subject: [Jingle] Abusing Sessions (AKA: "There's files in my video chat!") Message-ID: This may have been already addressed, but I'm feeling too lazy to dig thru the mailing lists tonight. Is it the intention of the spec for there to only be one jingle session at a time between two entities? For example, if you are video chatting with someone and they want to send you a file, would that be a new session? Or would it be new content? If the answer really is the later, then this could seriously complicate implementations?and is entirely unnecessary. I would recommend that individual sessions be limited to having the same flavor of content: sessions started with file transfer (XEP-0234) content should never contain Jingle RTP (XEP-0167) content, and vice versa. __________________ Robert Quattlebaum Jabber: darco at deepdarc.com eMail: darco at deepdarc.com www: http://www.deepdarc.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulrw at codian.com Fri Aug 14 05:48:19 2009 From: paulrw at codian.com (Paul Witty) Date: Fri, 14 Aug 2009 11:48:19 +0100 Subject: [Jingle] Destination address information in session-initiate In-Reply-To: <7B745B80-6225-43D7-B79B-1DC68F24109F@deepdarc.com> References: <4A69D38A.6050100@codian.com> <7B745B80-6225-43D7-B79B-1DC68F24109F@deepdarc.com> Message-ID: <4A8540F3.5020407@codian.com> Robert Quattlebaum wrote: > > On Jul 24, 2009, at 8:30 AM, Paul Witty wrote: > >> A gateway may only be registered as a single XMPP client, but permit >> calling to any number of SIP endpoints on the other side; an MCU can >> host multiple conferences etc. > > This is not true. In fact, this would be the worst way to implement a > SIP gateway, or any other type of XMPP gateway. > > This problem is best solved by making the gateway a server component, > or even a standalone server (that accepts S2S connections, not C2S > connections) itself. See "XEP-0100: Gateway Interaction > " for more information. > > For example, lets say that you wanted to call , > using the SIP bridge sipbridge.example.net > . The client, who knows about > sipbridge.example.net already, would > then translate the SIP address blah at example.com > into blah\40example.com at sipbridge.example.net. > You would initiate a jingle session with that address. Conferences > could likely be handled in a similar fashion. > Yes, been playing around a bit with doing this, making the gateway act as a component. All seems pretty convenient for calling from the Jingle client, assuming it allows calling to arbitrary JIDs in the gateway case, and for the MCU/recording server case with multiple items discoverable using service discovery it all should work (though I've not tried implementing such). There's obviously the limitation that only people who can change server configuration are capable of setting up a component connection; but such is the price you pay for convenience, and a S2S version wouldn't have the issue. So yeah, ignore my initial suggestion :D -- Paul From stpeter at stpeter.im Mon Aug 24 11:00:18 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Mon, 24 Aug 2009 10:00:18 -0600 Subject: [Jingle] Jingle-RTMP transport? Message-ID: <4A92B912.8020003@stpeter.im> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Several years ago, there was interest in defining a Jingle transport for Adobe's RTMP technology: http://xmpp.org/extensions/inbox/jingle-rtmp.html The XMPP Council did not accept that document as an official XEP because RTMP was not an open technology. Recently, Adobe "open-sourced" RTMP: http://www.adobe.com/devnet/rtmp/ It is not yet clear to me if the RTMP "licensing" is open enough for pursuing a Jingle RTMP transport, or indeed if anyone is still interested in defining such a transport. Feedback is welcome. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqSuRIACgkQNL8k5A2w/vzetwCcDkYjI1JJAAc3HFBJ3eRs5Zus n58AnjZNziSbiqrIMsFp86VpftWg5b5e =FxED -----END PGP SIGNATURE----- From stpeter at stpeter.im Tue Aug 25 11:33:27 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 25 Aug 2009 10:33:27 -0600 Subject: [Jingle] FYI: XMPP forum at Packetizer Message-ID: <4A941257.6060908@stpeter.im> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The admins of the Packetizer website have informed me that there is now a web forum about XMPP (mostly Jingle) at their new forums area: http://forums.packetizer.com/viewforum.php?f=6 Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqUElcACgkQNL8k5A2w/vx8bwCgrgIOH1z8sbTNBwOWqfwjCofX DpAAoLx2rM+i7fcDvAtX4FRudXm0mCoo =YTs9 -----END PGP SIGNATURE----- From darco at deepdarc.com Tue Aug 25 18:48:25 2009 From: darco at deepdarc.com (Robert Quattlebaum) Date: Tue, 25 Aug 2009 16:48:25 -0700 Subject: [Jingle] Abusing Sessions (AKA: "There's files in my video chat!") In-Reply-To: References: Message-ID: <25836633-943F-492A-959F-570C468B84BF@deepdarc.com> Anyone have any feedback on this issue? On Aug 13, 2009, at 6:57 PM, Robert Quattlebaum wrote: > This may have been already addressed, but I'm feeling too lazy to > dig thru the mailing lists tonight. > > Is it the intention of the spec for there to only be one jingle > session at a time between two entities? > > For example, if you are video chatting with someone and they want to > send you a file, would that be a new session? Or would it be new > content? If the answer really is the later, then this could > seriously complicate implementations?and is entirely unnecessary. > > I would recommend that individual sessions be limited to having the > same flavor of content: sessions started with file transfer > (XEP-0234) content should never contain Jingle RTP (XEP-0167) > content, and vice versa. __________________ Robert Quattlebaum Jabber: darco at deepdarc.com eMail: darco at deepdarc.com www: http://www.deepdarc.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From diana-liste at null.ro Wed Aug 26 10:11:28 2009 From: diana-liste at null.ro (Diana Cionoiu) Date: Wed, 26 Aug 2009 18:11:28 +0300 Subject: [Jingle] Jingle-RTMP transport? In-Reply-To: <4A92B912.8020003@stpeter.im> References: <4A92B912.8020003@stpeter.im> Message-ID: <4A9550A0.3000707@null.ro> Hello Peter, This doesn't seems to be an open standard at all. "Defensive Suspension If You assert, threaten to assert, or participate in the assertion of a lawsuit, proceeding, claim or similar action directed either (i) against any other person or entity, including Adobe, claiming that a Compliant Implementation infringes a patent, or (ii) against Adobe, claiming that any Adobe product infringes a patent, then Adobe may at its discretion terminate all license grants and any other rights provided under this Agreement to You." So i believe that it's not a good idea to push it into something open like jingle yet. Diana Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Several years ago, there was interest in defining a Jingle transport for > Adobe's RTMP technology: > > http://xmpp.org/extensions/inbox/jingle-rtmp.html > > The XMPP Council did not accept that document as an official XEP because > RTMP was not an open technology. > > Recently, Adobe "open-sourced" RTMP: > > http://www.adobe.com/devnet/rtmp/ > > It is not yet clear to me if the RTMP "licensing" is open enough for > pursuing a Jingle RTMP transport, or indeed if anyone is still > interested in defining such a transport. Feedback is welcome. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqSuRIACgkQNL8k5A2w/vzetwCcDkYjI1JJAAc3HFBJ3eRs5Zus > n58AnjZNziSbiqrIMsFp86VpftWg5b5e > =FxED > -----END PGP SIGNATURE----- > From dmeyer at tzi.de Thu Aug 27 05:26:57 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Thu, 27 Aug 2009 12:26:57 +0200 Subject: [Jingle] Jingle-RTMP transport? In-Reply-To: <4A9550A0.3000707@null.ro> (Diana Cionoiu's message of "Wed\, 26 Aug 2009 18\:11\:28 +0300") References: <4A92B912.8020003@stpeter.im> <4A9550A0.3000707@null.ro> Message-ID: <87bpm1eemm.fsf@phex.sachmittel.de> Diana Cionoiu wrote: > So i believe that it's not a good idea to push it into something open > like jingle yet. The next question is: do we need it? IIRC RTMP can only be used with the Flash video container. How many people write Jingle apps that exchange Flash video data? You cannot use it to replace RTP. Dirk -- If you can read this, you've just wasted your time on reading the sentence 'If you read this, you've just wasted your time on reading the sentence' - Twice! From sdk at disktree.net Thu Aug 27 07:32:04 2009 From: sdk at disktree.net (tong) Date: Thu, 27 Aug 2009 14:32:04 +0200 Subject: [Jingle] Jingle-RTMP transport? In-Reply-To: <87bpm1eemm.fsf@phex.sachmittel.de> References: <4A92B912.8020003@stpeter.im> <4A9550A0.3000707@null.ro> <87bpm1eemm.fsf@phex.sachmittel.de> Message-ID: <1251376324.4506.5.camel@desktop> On Thu, 2009-08-27 at 12:26 +0200, Dirk Meyer wrote: > Diana Cionoiu wrote: > > So i believe that it's not a good idea to push it into something open > > like jingle yet. > > The next question is: do we need it? IIRC RTMP can only be used with the > Flash video container. How many people write Jingle apps that exchange > Flash video data? You cannot use it to replace RTP. > > > Dirk > ... Flash player 9+ supports: MPEG-4 container format such as MP4, M4A, MOV, MP4V, 3GP, 3G2 if they contain H.264 video and/or HE-AAC encoded audio. I think jingle RTMP is pretty powerful. It could turn every jabber client in the wild into something jingle compatible by sending a link to a browser based 'relay' if the client doesn't support jingle out of the box (flash player penetration is about 98%). Or it could be used as a fallback for failing RTP sessions. /tong ? -- [) | 5 |< ? |2 3 3 From juberti at google.com Mon Aug 31 22:17:48 2009 From: juberti at google.com (Justin Uberti) Date: Mon, 31 Aug 2009 20:17:48 -0700 Subject: [Jingle] Abusing Sessions (AKA: "There's files in my video chat!") In-Reply-To: <25836633-943F-492A-959F-570C468B84BF@deepdarc.com> References: <25836633-943F-492A-959F-570C468B84BF@deepdarc.com> Message-ID: Different logical sessions should result in different Jingle sessions. That is, sending someone a file should typically be a different session from a voice call. That doesn't mean there won't be applications where you may want to combine seemingly unrelated types, but in the typical IM client case, the example you describe should result in a new session. On Tue, Aug 25, 2009 at 4:48 PM, Robert Quattlebaum wrote: > Anyone have any feedback on this issue? > > On Aug 13, 2009, at 6:57 PM, Robert Quattlebaum wrote: > > This may have been already addressed, but I'm feeling too lazy to dig thru > the mailing lists tonight. > > Is it the intention of the spec for there to only be one jingle session at > a time between two entities? > > For example, if you are video chatting with someone and they want to send > you a file, would that be a new session? Or would it be new content? If the > answer really is the later, then this could seriously complicate > implementations?and is entirely unnecessary. > > I would recommend that individual sessions be limited to having the same > flavor of content: sessions started with file transfer (XEP-0234) content > should never contain Jingle RTP (XEP-0167) content, and vice versa. > > > __________________ > *Robert Quattlebaum* > Jabber: darco at deepdarc.com > eMail: darco at deepdarc.com > www: http://www.deepdarc.com/ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: