IETF
rmcat@jabber.ietf.org
Wednesday, April 6, 2016< ^ >
Magnus Westerlund has set the subject to: Coupled congestion for RTP Media
Room Configuration
Room Occupants

GMT+0
[12:47:16] Meetecho joins the room
[12:55:25] csp joins the room
[12:56:12] Jahn Leslie joins the room
[12:57:15] Anna Brunstrom joins the room
[12:57:35] Mirja Kühlewind joins the room
[12:58:04] Varun Singh joins the room
[12:58:32] Wolfgang Beck joins the room
[12:59:02] ken carlberg joins the room
[13:00:51] Ingemar Johansson joins the room
[13:01:09] Sergio Mena joins the room
[13:02:43] Randell Jesup joins the room
[13:03:59] Jonathan Lennox joins the room
[13:04:59] Kristian A. Hiorth joins the room
[13:05:23] Sergio Mena_4819 joins the room
[13:05:44] <Randell Jesup> did the room mute the mics?  was hearing audio, not anymore
[13:06:02] <Ingemar Johansson> Audio Ok for me
[13:06:08] <Kristian A. Hiorth> audio works here
[13:06:18] <Varun Singh> works for me, as well
[13:06:37] <Varun Singh> slides are lagging?
[13:06:48] <Randell Jesup> reload fixed it
[13:07:07] <Ingemar Johansson> slide 4 now, should be correct
[13:07:27] <Varun Singh> i was seeing administrivia. reloading fixed it. thanks.
[13:08:35] <Varun Singh> IF NEEDED
[13:08:46] <Randell Jesup> I hang my head in shame that I haven't done more reviews.  I may try to review things as needed over the next interval, but will not promise it.
[13:09:40] <Ingemar Johansson> Well.. I will definitely not throw the first stone :-)
[13:10:23] <Randell Jesup> :-)
[13:10:38] <Meetecho> can the chairs see Varun in queue? (just as FYI, we're monitoring from here)
[13:10:53] Jahn Leslie leaves the room
[13:11:09] Jahn Leslie joins the room
[13:11:37] <Ingemar Johansson> ACK
[13:11:59] Randell Jesup leaves the room
[13:12:13] Varun Singh leaves the room
[13:12:15] Randell Jesup joins the room
[13:12:39] Varun Singh joins the room
[13:12:43] Stefan Holmer joins the room
[13:13:02] <Randell Jesup> Hmmm.  My comment didn't get into the room, and then I got kicked out.
[13:13:09] <Varun Singh> I got booted off the system, resigned the blue sheets. And I am back now
[13:14:04] <Meetecho> Varun Singh: you're live
[13:14:29] <Randell Jesup> I *would* like to coordinate with people from each of the teams to provide integration layers/apis/patches that would let us trial these algorithms in real browsers
[13:14:54] Jahn Leslie leaves the room
[13:15:19] Jahn Leslie joins the room
[13:16:15] <Sergio Mena_4819> How long are the sequences?
[13:16:17] Safa Almalki joins the room
[13:16:46] <Sergio Mena_4819> Could they span 2 min?
[13:16:55] <Mirja Kühlewind> Randell: great! please announce this on the mailing list
[13:17:12] <Ingemar Johansson> Randell : As regards to SCReAM, have a look at section 6.2 in the SCReAM draft.
[13:17:13] Brian Trammell joins the room
[13:19:58] Ralf Globisch joins the room
[13:23:26] <Randell Jesup> Ingemar: Yes, I recall that - I'd be interested in integrating the draft into Firefox (at least such that it can be easy to build a version with that added).  Best case would be a import script and pref to flip it on if imported
[13:23:44] <Varun Singh> I thought we picked Cubic?
[13:24:07] <Varun Singh> default.
[13:24:10] <Ingemar Johansson> Cubic should be OK, most widely deployed
[13:26:49] Frederic Maze joins the room
[13:27:32] <Varun Singh> media pause and resume should suffice for now
[13:27:59] <Varun Singh> we could always pick some video sequences that have screen content
[13:28:59] <Stefan Holmer> the difference is that when you pause you can choose to pause the CC as well, so that you can resume at the same rate as you paused
[13:29:24] <Stefan Holmer> when having a slide show you will still be sending something, but at a very low rate in between slide changes
[13:30:13] <Varun Singh> Stefan, can agree to that. mouse pointer, etc
[13:31:07] <Varun Singh> agree to the sequence
[13:31:08] <Stefan Holmer> i agree with randell
[13:31:34] <Ingemar Johansson> I can see the need for various test cases, at the same time I see a risk that we drown in test cases
[13:32:05] Randell Jesup_2 joins the room
[13:32:40] <Randell Jesup_2> Darn, hit backspace outside the text box. :-/
[13:32:45] Randell Jesup leaves the room
[13:33:47] <Randell Jesup_2> Ingemar: I agree, I think just one test case with a screencast - it's mostly just a "make sure we know what we're buying" filter
[13:34:03] <Ingemar Johansson> OK
[13:34:12] Jahn Leslie leaves the room
[13:34:27] Jahn Leslie joins the room
[13:34:45] <Stefan Holmer> agree, it doesn't have to be too extensive
[13:35:15] <Randell Jesup_2> And it's radically different from other sequences, as we discussed - especially as a it's often VERY high resolution and either low-framerate or low/no-changes between frames
[13:35:21] <Varun Singh> I believe doing a few tests. because competing to TCP might not show meaningful, while competing with non-screencasting RMCAT flows can be interesting
[13:35:35] Ralf Globisch leaves the room
[13:36:32] Ralf Globisch joins the room
[13:36:45] Randell Jesup joins the room
[13:37:08] <Randell Jesup> got kicked out again :-(
[13:37:25] Randell Jesup_2 leaves the room
[13:37:31] <Mirja Kühlewind> out of meetecho (or the queue)?
[13:37:37] <Randell Jesup> Out of meetecho
[13:37:40] hta joins the room
[13:37:57] <Meetecho> Randell Jesup: sorry about that, sounds like a problematic network path between you and Argentina :(
[13:38:00] Frederic Maze leaves the room
[13:38:26] Spencer Dawkins joins the room
[13:38:45] Safa Almalki leaves the room
[13:38:52] <Randell Jesup> when it's on, everything is perfect.  I get periodic random "error:" or "Network error, you may need to log in again" errors
[13:39:21] <Wolfgang Beck> Meetecho has been very stable for me so far (from Germany)
[13:39:50] <Randell Jesup> and the conference sounds fine and looks fine while it's in the process of kicking me out
[13:40:06] <Varun Singh> it does show up, especially when the audio is playingback
[13:40:22] <Ingemar Johansson> I cannot judge NADA behavior at this stage as I don't have anything to compare with for the moment, hopefully later
[13:40:53] <Varun Singh> I had to reload the page twice. it has been stable since my presentation
[13:40:58] <Ingemar Johansson> How high bitrate would one TCP in upstream achieve ?
[13:41:04] <Sergio Mena_4819> Meetecho also stable for me (Switzerland)
[13:41:24] ken carlberg leaves the room
[13:41:40] ken carlberg joins the room
[13:41:55] <Sergio Mena_4819> BTW, using pidgin in the background not to miss chat in case meetecho kicks me out
[13:42:04] frodek joins the room
[13:42:16] <Ingemar Johansson> Correct
[13:43:35] <Randell Jesup> As for screensharing, I was truying to say that an algorithm might get burned on that if it decays the estimate during a sequence of way-below-estimate traffic - when a slide change or major screen change occurs, a lowered estimate could make the new slide come in at high quantization and take time to recover - bad experience
[13:44:41] <Stefan Holmer> high quantization, or severely delayed
[13:45:02] <Randell Jesup> yup
[13:45:23] <Ingemar Johansson> OK, assume that it is still RTP media, one could consider to transmit such media over the data channel ?
[13:45:28] <Varun Singh> What is the question on the floor? I lost a bit of audio because of page reload
[13:45:35] <Randell Jesup> Remember "Internet" == "Wifi" for a lot of users....
[13:46:05] <Mirja Kühlewind> the question was if the wireless test case need to be 'mandatory'
[13:46:19] <Mirja Kühlewind> will have this discussion on the mailing list
[13:46:30] <Randell Jesup> ingemar: only if you don't encode it, or encode it with as JS-emscriptem codec
[13:46:30] Varun Singh leaves the room
[13:46:42] <Ingemar Johansson> I believe that it would be good to catch a 90% delay figure as this would indicate better what the e2e latency is
[13:46:52] <Randell Jesup> i.e. encoded traffic isn't available to JS
[13:47:08] <Ingemar Johansson> Randell: OK, understand
[13:47:28] Varun Singh joins the room
[13:47:47] <Kristian A. Hiorth> couldn't many slides be encoded as static images somehow?
[13:47:59] John Leslie joins the room
[13:48:35] <Mirja Kühlewind> randell: can you summarize your feedback (and this discussion) about slideshows on the mailing list to mke sure that this does not get lost?
[13:48:52] Markku Kojo joins the room
[13:49:02] Jahn Leslie leaves the room
[13:49:04] <Varun Singh> Are the results for the wireless case using NADA? for the cases the results are looking worse, could use 8 CBR flows and long TCP flows -- to see if the behaviour makes sense,
[13:49:50] <Mirja Kühlewind> yes it's nada
[13:50:07] <Ingemar Johansson> Why UDP BG flows ?, wouldnt it make more sense to model TCP flows instead
[13:50:11] <Randell Jesup> Kristian: in a slideshow-application, sure - but in a screencast of a slideshow, the slides may not be static images, and also thre may be other non-static data - and there are non-slideshow variations to consider, which have similar issues
[13:50:11] <Varun Singh> slide: 11 is there loss on the NADA and UDP flows
[13:50:28] <Varun Singh> i.e., loss rate for UDP flow, to observe impact
[13:50:32] Piers O'Hanlon joins the room
[13:50:50] <ken carlberg> sorry if I missed this in the discussion, but was there any description of the type of flows in terms of the percentage or ratio of long-lived and short-lived flows?
[13:51:04] <Varun Singh> @ingemmar: Yes, we have short TCP flow models in eval-criteria
[13:51:48] <Varun Singh> @ken, It seems the background started at some point and remained -- so long flows
[13:51:57] <Varun Singh> but I am guessing too.
[13:52:08] <Ingemar Johansson> UDP bg flows in this example
[13:52:39] <Varun Singh> did @xiaoqing say what the BG flow was modelled as?
[13:53:19] <Randell Jesup> mirja: absolutely.   Is there a log of the chat traffic?  I'll cut-and-paste in any case
[13:53:46] <Piers O'Hanlon> http://www.ietf.org/jabber/logs/rmcat/2016-04-06.html
[13:53:46] <Mirja Kühlewind> please check with the meetecho team
[13:53:51] <Mirja Kühlewind> ah
[13:53:58] csp leaves the room
[13:54:41] <Randell Jesup> Hmmm.  Can't select and save from the meetecho jabber interface.  So I'll need someone who's in jabber directly to save a copy and email it to me
[13:54:47] <Meetecho> Randell Jesup: https://www.ietf.org/jabber/logs/rmcat/2016-04-06.html
[13:55:01] <Meetecho> all jabber rooms are recorded, here you can see a live snapshot
[13:55:03] <Randell Jesup> meetecho: perfect
[13:55:07] Safa Almalki joins the room
[13:55:16] <Randell Jesup> figured it would be
[13:55:17] vojislav v joins the room
[13:57:30] <Varun Singh> are the x264 params consistent to the discussion during the codec comparison from honolulu?
[13:57:51] <Varun Singh> made in rtcweb
[13:57:55] <Mirja Kühlewind> you can also go to the queue
[13:58:04] <Sergio Mena_4819> @varun: not sure. can you point to discussion?
[13:58:39] <Brian Trammell> re slide sharing content: why not just play back/re-encode all the meetecho sessions of the wg?
[13:58:42] <Varun Singh> @sergio, you should ask Mo --- as he led the work from Cisco at the time. Also netvc chair
[13:59:11] <Sergio Mena_4819> Are those sequences at least 1080p, and min 2 min long?
[13:59:32] <Sergio Mena_4819> Good, will check with him
[13:59:43] <Sergio Mena_4819> Thanks for info
[13:59:43] <Varun Singh> i think there are some with 1080p but cannot say if they are 2mins long.
[14:00:06] <Sergio Mena_4819> that's the think... not easy to handle: > 30 GB in raw format
[14:00:29] <Sergio Mena_4819> *thing
[14:00:35] Alejandro Popovsky joins the room
[14:00:57] <Kristian A. Hiorth> Brian: that would be representative of recorded conference presentation, I would think that a typical "talking head" type sequence would be more dynamic
[14:01:24] <Kristian A. Hiorth> due to framing/zoom on face
[14:02:30] <Sergio Mena_4819> resolution is fixed
[14:02:36] <Sergio Mena_4819> we change target bitrate
[14:03:41] <Varun Singh> then what is the burst?
[14:03:47] <Ingemar Johansson> I recall that I saw this when experimenting with openh264, happened when the target bitrate changed abruptly and with a large step
[14:03:47] <Randell Jesup> The *quantization* changed, not the resolution
[14:03:56] <Sergio Mena_4819> exactly
[14:05:04] <Ingemar Johansson> It is not that obvious when the rate changes more gradually
[14:05:43] <Sergio Mena_4819> it the group think it's interesting
[14:05:50] <Sergio Mena_4819> we could tackle it
[14:05:51] Safa Almalki leaves the room
[14:06:10] Alejandro Popovsky leaves the room
[14:06:19] Safa Almalki joins the room
[14:06:20] Alejandro Popovsky joins the room
[14:06:36] <Randell Jesup> Also, it isn't clear what the codec is doing on a "forced" target change; it might be forcing a iframe - or changing the internal resolution and telling the decoder to scale back up -- vp8 can do this!
[14:07:24] Alejandro Popovsky leaves the room
[14:08:41] <Randell Jesup> I generally prefer to not change framerate; I'd rather reduce the quality or the resolution -- for video/interactive content at least
[14:09:01] <Varun Singh> I am missing what the end goal is here...
[14:09:44] <Sergio Mena_4819> The end goal is coming up with a "benchmark" for what most codecs do, without having to use a full-fleged codec in the rcmat test cases
[14:10:04] <Sergio Mena_4819> For talking-head like content (for the moment)
[14:10:07] Alejandro Popovsky joins the room
[14:10:28] <Varun Singh> http://techblog.netflix.com/2015/12/per-title-encode-optimization.html
[14:10:31] <Stefan Holmer> vp9 doesn't even send a key frame when you switch resolution
[14:11:03] <Varun Singh> netflix changed the codec behaviour based on the type of movie it was. So again, we should just pick a simple way forward
[14:11:23] <Stefan Holmer> if possible I'd prefer to only change the quantizer
[14:11:55] <Randell Jesup> Agreed (with stefan and varun)
[14:12:07] <Sergio Mena_4819> I agree it should be simple in the end
[14:12:09] <Stefan Holmer> if we can't go lower than a bitrate X, then maybe we can scale it manually based on what we got at a higher bitrate
[14:13:00] <Sergio Mena_4819> We're doing precisely that in syncodecs
[14:13:06] <Sergio Mena_4819> (to stefan)
[14:13:19] <Sergio Mena_4819> And how we're doing it is described in the draft
[14:13:26] <Varun Singh> I guess the question, I have is, if this is a behaviour we would see in production, then we would need to handle it in the congestion controller.
[14:13:41] <Sergio Mena_4819> This is more to see if we need to add something to the model for transient behavior
[14:14:20] <Varun Singh> We did a study of data on Youtube, will post a link to it.
[14:14:51] <Sergio Mena_4819> @varun Yes, I went throght the paper some months back
[14:15:17] <Sergio Mena_4819> We wanted to adjust some parameters based on the results of your survey... still in TODO list (blush)
[14:15:41] <Varun Singh> Impact of Duration on Active Video testing Authors: Saba Ahsan (Aalto University
[14:15:50] <Varun Singh> http://arxiv.org/pdf/1408.5777v1.pdf
[14:16:10] <Varun Singh> for frame size distribution, etc
[14:16:29] <Mirja Kühlewind> varun: please also send the link on the mailing list
[14:16:31] Spencer Dawkins leaves the room
[14:17:30] <Varun Singh> @sergio, will intro you to the researcher who is working on this. she can work with you directly and help as needed
[14:17:43] <Varun Singh> she also wrote the ns2 traffic generator for this
[14:17:46] <Sergio Mena_4819> @varun Thanks
[14:17:55] Jahn Leslie joins the room
[14:19:22] John Leslie leaves the room
[14:20:06] <Varun Singh> https://github.com/sabyahsan/ns2-videosrc
[14:20:57] wu teng joins the room
[14:22:09] <Sergio Mena_4819> Can we agree on which codec would be most representative to the group?
[14:22:57] <Randell Jesup> I can try to grab a trace from VP8, VP9, and OpenH264 in Firefox by hard-wiring the codec controls and dump the encoded frame sizes
[14:23:28] <Sergio Mena_4819> @randell That would be useful for us
[14:23:38] <Jonathan Lennox> Those are the ones actually being used in Firefox and Chrome, and they're all open source, so yeah, best option.
[14:24:24] <Randell Jesup> Once I build the patch to do the hard-coding/dump, I just need to make calls in different codecs, which is easy
[14:25:13] <Sergio Mena_4819> @randell We'd appreciate if you could share the results with us
[14:25:24] <Sergio Mena_4819> (results: resulting traces)
[14:25:36] <Sergio Mena_4819> (traces: sequence of frame sizes)
[14:25:38] <Randell Jesup> sure, once I have them I'll share them on the list with traces
[14:25:48] <Sergio Mena_4819> good!
[14:26:22] hta leaves the room
[14:26:28] <Randell Jesup> Not a complex patch to build
[14:27:25] <Piers O'Hanlon> Does Cisco have any traces from their open264 codec?
[14:31:29] Julius Flohr joins the room
[14:32:01] Markku Kojo leaves the room
[14:32:36] hta joins the room
[14:36:17] Safa Almalki leaves the room
[14:37:27] wu teng leaves the room
[14:38:37] safa a joins the room
[14:38:56] <Ingemar Johansson> Why the jitter in the NS3 trace and not in the NS2 ditto ?
[14:40:58] <Ingemar Johansson> So the NADA algo is somehow affected by the jitter that may occur depending on whether NADA packets are ahead or behind the UDP packets ?
[14:41:24] <Ingemar Johansson> Is it due to the low 10ms threshold then
[14:41:31] <Mirja Kühlewind> please go to the mic queue if you want to discuss this
[14:43:02] Kristian A. Hiorth leaves the room
[14:43:19] <Piers O'Hanlon> How dependent is NADA on synchronised clocks on the communicating hosts?
[14:44:50] <Ingemar Johansson> Exactly
[14:44:52] Stefan Holmer leaves the room
[14:45:42] Stefan Holmer joins the room
[14:45:42] <Ingemar Johansson> Is my audio too low, too high or am I only stuttering ?
[14:45:57] vojislav v leaves the room
[14:46:04] <Piers O'Hanlon> There was some breakup but I could hear you
[14:46:08] <Ingemar Johansson> OK
[14:46:22] <Ingemar Johansson> But you understand my accent :-)
[14:46:28] <Mirja Kühlewind> it the break up but also because the speakers are stupidly place in the room
[14:46:29] <Piers O'Hanlon> ;)
[14:46:37] <Mirja Kühlewind> and it's just hard to hear in the front
[14:47:13] Julius Flohr leaves the room
[14:49:04] <Ingemar Johansson> I am out of cycles
[15:01:13] <Varun Singh> thanks ingemar for doing the mapping
[15:02:31] <Ingemar Johansson> You´re welcome, hope that I got the details right
[15:03:12] <Varun Singh> almost, but I was more interested in the frequency and the corresponding packet rate
[15:03:42] <Varun Singh> because the current RLE can be good if there are many packets. This can be easily improved if we are talking about fewer packets.
[15:03:59] <Varun Singh> we did this for Flexible FEC and packets discarded
[15:05:56] <Varun Singh> ditto for packet size
[15:05:57] hta leaves the room
[15:06:05] <Ingemar Johansson> Stefan : Have you decided to move to sender based ?
[15:07:06] <Stefan Holmer> yes
[15:07:43] <Stefan Holmer> more or less decided, we're doing some final experiments right now
[15:08:31] hta joins the room
[15:08:38] safa a leaves the room
[15:08:42] <Jonathan Lennox> What are the definition of "low" and "high" for SCReAM?
[15:09:39] <Varun Singh> yes, i agree with Mo on RTT
[15:10:18] <Ingemar Johansson> Given by experimentation, at low bitrates it is sufficient with 100-200ms. At high rates a shorted feedback interval is needed to keep the ack-clocking in a healthy state
[15:10:59] <Jonathan Lennox> What bitrates are you calling "low" and "high"?
[15:11:28] <Ingemar Johansson> Low birates are ~20-100kbps
[15:11:45] <Jonathan Lennox> Ok, thanks
[15:11:48] <Ingemar Johansson> High bitrates are in the order of 1Mbps and up
[15:11:51] Wolfgang Beck leaves the room
[15:12:06] <Jonathan Lennox> In between do you want intermediate values?
[15:12:09] <Ingemar Johansson> RTT is not a key factor here (for SCReAM)
[15:12:24] <Stefan Holmer> not for gcc either
[15:12:35] <Stefan Holmer> it is important for the CC, but not for feedback rate
[15:12:56] <Ingemar Johansson> Yes, roughly, one can say that feedback rate is proportional to received media rate.
[15:13:29] safa a joins the room
[15:14:09] <Ingemar Johansson> A strawman is seen on page 14
[15:14:42] <Ingemar Johansson> Not to be seen as the exact rule, rather ball park values
[15:15:54] <Varun Singh> I see it as a combination of RTT, media rate, and how quickly the sender can react.
[15:16:51] <Ralf Globisch> I agree with Varun
[15:19:47] <Stefan Holmer> +1 to loss repair vs. rate adaptation
[15:20:24] <Ingemar Johansson> There is no conflict between the two, it is more a matter of RTCP BW
[15:21:02] <Ingemar Johansson> Early or immediate RTCP mode can be used for loss feedback (for Video reTx)
[15:22:30] Tobia Castaldi joins the room
[15:23:42] Alejandro Popovsky leaves the room
[15:24:21] Tobia Castaldi leaves the room
[15:24:23] <Varun Singh> I think picking a feedback interval is the main thing.
[15:25:15] <Ingemar Johansson> I believe that the generic feedback (by Stefan et. al) is a good starting point
[15:26:47] <Ingemar Johansson> The interval can be negotiated
[15:27:06] <Varun Singh> the interval can be negotiated... but what about mismatch
[15:27:34] <Ingemar Johansson> Mismatch is not an issue if we make it sender based
[15:27:58] <Mirja Kühlewind> meetecho: could you point the camera at the mic
[15:28:05] <Ingemar Johansson> or perhaps I miss something ...?
[15:28:16] <Meetecho> ack
[15:28:17] <Varun Singh> I was thinking of expectation of information or loss of information due to aggregation
[15:28:54] <Stefan Holmer> yes, algorithms must ensure they can handle some lost feedback
[15:29:05] Meetecho leaves the room
[15:29:35] <Randell Jesup> in the queue....
[15:29:44] <Varun Singh> yes if the feedback interval becomes longer, then the information either in the feedback packet becomes large or you perform some kind of aggregation
[15:30:36] <Sergio Mena_4819> Does the group agree to move to sender-based at this point? (just asking)
[15:31:08] <Mirja Kühlewind> (sorry wasn't able to follow the discussion in jabber closly, please post things that should not be missed to the mailling list later)
[15:31:54] <Sergio Mena_4819> thx
[15:33:26] <Stefan Holmer> sgtm
[15:33:46] <Randell Jesup> +1 continue/extend work
[15:34:06] <Stefan Holmer> we're definitely open to identifying packets in other ways if we find that better
[15:34:10] <Varun Singh> although transport wide sequence numbers and SSRC has an issue
[15:34:29] <Varun Singh> I am not sure that is the right step forward
[15:34:29] <Ingemar Johansson> The high FB rate may possibly be an issue with highly assymetric links. On the other hand, did some calculations earlier and believe that I ended up with a RTCP BW of 10-20kbps when the media rate was 1.5Mbps
[15:34:52] frodek leaves the room
[15:34:52] <Ingemar Johansson> Hasta la Vista
[15:34:56] <Stefan Holmer> yes, it's not too bad i hope
[15:34:58] <Varun Singh> I am in favor of finding another way forward
[15:35:00] <Stefan Holmer> bye bye
[15:35:08] <Sergio Mena_4819> bye
[15:35:09] <Varun Singh> good bye
[15:35:10] <Ingemar Johansson> Bye
[15:35:15] Stefan Holmer leaves the room
[15:35:16] Sergio Mena_4819 leaves the room
[15:35:35] Mirja Kühlewind leaves the room
[15:35:36] Jahn Leslie leaves the room
[15:35:36] ken carlberg leaves the room
[15:35:36] Anna Brunstrom leaves the room
[15:35:36] Ralf Globisch leaves the room
[15:35:36] Piers O'Hanlon leaves the room
[15:35:37] Varun Singh leaves the room
[15:36:18] Ingemar Johansson leaves the room
[15:36:23] Randell Jesup leaves the room
[15:36:25] Brian Trammell leaves the room
[15:36:33] safa a leaves the room
[15:37:23] hta leaves the room
[15:42:43] Sergio Mena leaves the room
[15:43:13] Jonathan Lennox leaves the room
[15:43:20] Sergio Mena joins the room
[15:44:22] Sergio Mena leaves the room
[15:44:41] Sergio Mena joins the room
[15:49:01] Sergio Mena leaves the room
[16:08:49] Jonathan Lennox joins the room
[16:10:47] frodek joins the room
[16:12:20] frodek leaves the room
[16:19:21] Jonathan Lennox leaves the room
[17:11:06] hta joins the room
[17:33:28] hta leaves the room
[18:25:33] hta joins the room
[19:07:21] hta leaves the room
[19:14:19] hta joins the room
[20:06:53] hta leaves the room
[20:23:02] hta joins the room
[20:39:38] hta leaves the room
[20:41:06] hta joins the room
[21:36:46] hta leaves the room
[21:44:26] hta joins the room
[21:50:11] hta leaves the room
[21:57:31] hta joins the room
[23:11:04] hta leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!