| 00:25.53 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:28.47 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:28.47 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 04:53.05 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 04:53.05 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 04:58.56 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 04:58.56 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 05:58.14 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 05:58.14 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 06:25.35 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 07:05.31 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 07:05.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:47.02 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:47.04 | schmidts | good morning |
| 08:06.20 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 08:07.42 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 08:18.17 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:27.59 | wdoekes2 | morning schmidts |
| 08:36.22 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:53.17 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:53.17 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:08.23 | *** join/#asterisk-dev _ys (~Miranda@HS3-193-4.xG.SPb.SkyLink.RU) |
| 10:37.55 | *** join/#asterisk-dev kaii (~kh@ciphron.de) |
| 11:17.08 | *** join/#asterisk-dev frawd (~francois@19.Red-81-39-176.dynamicIP.rima-tde.net) |
| 11:25.28 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 11:27.10 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 11:47.23 | schmidts | just a short sip question, shouldnt a client have to ACK a 401 response to a REGISTER request? |
| 11:47.55 | schmidts | i mean i see an incoming register in asterisk, resonse is 100 trying and 401 Unauthorized but shouldnt the client answer the 401 with an ACK then? i am just not sure at the moment ;) |
| 11:56.08 | schmidts | ok it looks like it doesnt have to be there |
| 11:58.49 | wdoekes2 | no.. only requests that start a dialog (invite) need an ack.. the others explicitly don't |
| 12:04.50 | wdoekes2 | "[...] an ACK is only sent in response to a response to an INVITE request." ... "Non-INVITE transactions do not make use of ACK." |
| 12:08.41 | schmidts | wdoekes2 thanks! i have allready read the rfc again about this ;) i just wondered cause i have seen it last week with an ACK but this is only necessary for a Proxy Authorization |
| 12:26.06 | tzafrir | frawd, ping |
| 12:27.08 | tzafrir | Regarding the recent SIP change: I find it a bit odd to force the change on stable versions |
| 12:27.37 | tzafrir | That is: if you actually need to disable force_rport, you get a really nasty warning in the logs |
| 12:27.49 | tzafrir | How can that warning be disabled? |
| 12:28.26 | tzafrir | force_rport_warning=shootinfoot ;? |
| 12:29.09 | _ys | Hi. another place, with dual port: "Message-Account: sip:100@192.168.1.1:15072:15072" |
| 12:29.32 | _ys | why 15072 placed twice? |
| 12:53.48 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.63.33.115) |
| 13:01.11 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.63.33.115) |
| 13:15.13 | schmidts | _ys which version do you use? i have read something about a fix for this latly |
| 13:31.11 | leifmadsen | _ys: ya you'll want to try Asterisk 1.8.8.0-rc5 which had a fix for the To: header in the message infrastructure |
| 14:03.55 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-zxtukodsnvcijyqb) |
| 14:03.56 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:05.25 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-uaoiazewjxiytkoo) |
| 14:17.56 | _ys | leifmadsen: I now test trunk version: Asterisk SVN-trunk-r347903M, w/same result |
| 14:18.23 | _ys | Message-Account: in SIP NOTIFY are incorrect |
| 14:25.43 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.147.186) |
| 14:29.06 | *** join/#asterisk-dev jrrose (~Jon@207.98.203.74) |
| 14:30.46 | leifmadsen | _ys: then that is a bug, and you may need to report it. If you're able to submit a patch to correct it, even better. Should also do a search to make sure your issue hasn't already been reported. |
| 14:43.07 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:43.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:50.19 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 14:54.20 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:54.20 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:01.35 | *** join/#asterisk-dev UnixDev (unixdev@unaffiliated/unixdev) |
| 15:01.48 | UnixDev | good morning all |
| 15:02.11 | UnixDev | I think I may have found a bug in asterisk, running 'SVN-branch-1.8-r345976M' . It seems that in certain instances, a failure of a call (one with a reinvite, example fax call), will mark a peer 'Lagged' even though every 'OPTIONS' request sent to peer has been responded to in under a Qualify time … It will say the peer is now 'Lagged' with a delta of X ms where X ms is equal to the length of time since the last (verified via tcp dump, and answ |
| 15:02.12 | UnixDev | with 200 OK) 'OPTIONS' request peer actually DID answer... |
| 15:05.46 | mjordan | when you say the call 'failed', how did the call fail? |
| 15:05.53 | schmidts | UnixDev i dont think this is possible or even doesnt depend on an Invite |
| 15:06.55 | schmidts | the Lagged information only happens in the poke_peer function in chan_sip.c which only is called on an OPTION response |
| 15:08.18 | UnixDev | schmidts: the OPTIONS is 100% answered, whats interesting, is the delta of how lagged the peer is, is referring to the last (verified answered) OPTIONS request |
| 15:09.05 | UnixDev | mjordan: failed, for example, t38 fails, call is connected is one case, another is reinvite fails with 408 SIP response from Peer |
| 15:10.25 | mjordan | which is that your request timed out. Why would that not end up with a peer getting lagged by subsequent OPTIONS packets? |
| 15:10.28 | schmidts | UnixDev no the delta is reffering when this option message was sent out, not the last one, the actual one or you would have a delta of 60 seconds + RTT time |
| 15:11.02 | UnixDev | schmidts: right, but that OPTIONS request was answered |
| 15:11.08 | UnixDev | so why is it lagged? |
| 15:12.29 | UnixDev | mjordan: peer is not lagged, 408 is a real packet, and is not even from Peer, it is relayed by Peer, regardless, Peer is not Lagged, and response to all requests in timely manner, that particular destination (on reinvate) resulted in 408 somewhere upstream |
| 15:12.40 | schmidts | UnixDev i could think of a case where this could happens but this only would happens if the do_monitor function itself takes so long to process this Option packet |
| 15:13.25 | schmidts | what i mean is, the 408 comes in and block the sip processing thread so long that the option packet is stucked in the buffer and until its processed its marked as LAGGED |
| 15:13.47 | schmidts | but this would mean your server is not handling any sip packets in more than a second which is very unlikly |
| 15:14.16 | UnixDev | schmidts: how could that happen if machine is not overworked, plenty of time, 10 seconds or more, to process OPTIONS reply before 408 |
| 15:14.45 | UnixDev | schmidts: server respons sub 1 sec, to all sip requests |
| 15:16.05 | schmidts | UnixDev even when this 408 happens? |
| 15:17.07 | schmidts | for normal udp sip asterisk has only one loop for reading packets from the incoming buffer and also sent out scheduled messages, if something happens which blocks this thread then all incoming packets are stuck in the buffer. |
| 15:17.25 | UnixDev | well, the 408, may come sometime after reinvite, say 11 seconds after, but any other requests, will be responded to, example if asterisk sends another options in between |
| 15:17.27 | schmidts | this could happens could of a "deadlock" or just a block in a special case |
| 15:17.58 | schmidts | asterisk wouldnt sent out an OPTION when it would be blocked so it must be something else |
| 15:19.51 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:20.53 | schmidts | i am looking at the code, it would be possible if something would change the peer->ps value but this should only be touched from the poke_peer function and the handle_options function |
| 15:21.23 | UnixDev | schmidts: I can provide a trace, but I would not want to post this on the list, as the IPs are sensative |
| 15:22.36 | schmidts | let me take a look at the code first |
| 15:23.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 15:25.15 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:25.15 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:26.43 | schmidts | Unixdev does this happen on an inbound or outbound call? |
| 15:27.05 | UnixDev | the call is outbound from asterisk to Peer |
| 15:28.39 | UnixDev | it may happen in Inbound also, but our test (and reproducible case) is on an outbound call |
| 15:29.25 | schmidts | could you paste the cli output of the LAGGED message, cause there should be also the lastms value of this peer which would be interesting |
| 15:30.10 | UnixDev | [Dec 12 08:25:05] NOTICE[10066]: chan_sip.c:20496 handle_response_peerpoke: Peer 'DP-Ohio' is now Lagged. (7230ms / 400ms) |
| 15:31.01 | schmidts | UnixDev strange ;) |
| 15:31.10 | UnixDev | yes! it has been kicking my ass |
| 15:31.23 | schmidts | do you have a sip trace when this happens? |
| 15:31.49 | UnixDev | I may be able to dig one up from an older call, but this will not be from point of view of asterisk machine |
| 15:32.19 | UnixDev | i may have some tcpdump console output from asterisk machine console |
| 15:34.52 | schmidts | could you paste just the latest incoming sip message before this lagged message happens |
| 15:37.20 | schmidts | needs a cig brb ;) |
| 15:37.43 | UnixDev | the 408? |
| 15:40.22 | schmidts | when i have understand you right the 408 is the latest response you got from this peer before you see this lagged message, then yes the 408 |
| 15:44.30 | UnixDev | http://pastebin.com/xLqPKDDr |
| 15:44.41 | UnixDev | 2.2.2.2 is asterisk machine, 1.1.1.1 is peer |
| 15:44.59 | UnixDev | I included the last options request and reply, along with the 408 then the next message |
| 15:45.41 | UnixDev | its hard to tell whether they BYE or the 408 is when the peer was marked lagged, but it is one of them |
| 15:45.56 | UnixDev | sometimes, this also happens without 408, so it could be related to the BYE |
| 15:47.29 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.79.187) |
| 15:47.32 | schmidts | this bye is outbound to this peer so this couldnt cause this lagged state |
| 15:48.05 | UnixDev | it is not |
| 15:48.08 | UnixDev | it is from Peer |
| 15:48.19 | UnixDev | look at the second line, that is from tcp dump |
| 15:48.20 | UnixDev | <PROTECTED> |
| 15:48.31 | UnixDev | from 1.1.1.1 to 2.2.2.2 |
| 15:48.33 | schmidts | sorry yes my fault ;) |
| 15:49.26 | schmidts | what i could think of but it dont know why this could happens is here: http://www.asterisk.org/doxygen/asterisk1.8/chan__sip_8c-source.html#l20802 |
| 15:50.06 | schmidts | IMHO its strange to use p->method here and not the sipmethod var and maybe this causes that this incoming packet is handled as an incoming packet |
| 15:50.28 | schmidts | UnixDev does the call stay active after the 408 response? or is it closed after it? |
| 15:50.33 | UnixDev | closed |
| 15:50.49 | UnixDev | well, stay active in what sense? you mean stuck in asterisk? |
| 15:51.22 | schmidts | yes if the call is still active until you end it from the other side |
| 15:52.00 | UnixDev | no, it ends the call |
| 15:52.09 | schmidts | ok then it couldnt be what i thought of |
| 15:52.12 | UnixDev | the bye in this case came from the other side |
| 15:52.17 | UnixDev | it could be stuck in asterisk |
| 15:52.28 | UnixDev | we have seen calls get stuck, but haven't traced it, it could be related |
| 15:52.33 | schmidts | is there another client involved, so do you call a number and asterisk then dials out? |
| 15:52.53 | UnixDev | the reproducible case, is on an outbound fax |
| 15:53.12 | UnixDev | but we have seen it, on outbound voice calls (i.e. so asterisk handles both sides) |
| 15:53.39 | schmidts | cause there is only one place where this lastms value is changed and only one place where this function is called, so for me i can only think of an incoming packet which is handled as an in coming OPTION even if its something different |
| 15:53.41 | UnixDev | i think it could be getting stuck as you thought |
| 15:54.43 | schmidts | maybe you could try to replave the p->method with sipmethod on row 20802 in chan_sip.c and try if you can still reproduce it |
| 15:54.53 | UnixDev | ahh, yes, I see this |
| 15:55.06 | UnixDev | you think p->method usage is improper? |
| 15:55.29 | schmidts | it could be wrong initialized in this case |
| 15:56.27 | *** join/#asterisk-dev black187 (~black187@93-86-223-120.dynamic.isp.telekom.rs) |
| 15:56.27 | UnixDev | …ok, I can try this tonight after production time |
| 15:56.43 | black187 | Hello, does asterisk support 100rel or PRACK? |
| 15:57.16 | black187 | Our partner needs this for interop testing. |
| 15:57.23 | file | no. |
| 15:57.57 | UnixDev | schmidts: in the case you speak of, would just p->method be wrongly initialized, or p all together ? |
| 15:58.12 | black187 | Hmm ok, is there any plans to support it in the future? |
| 15:58.29 | schmidts | UnixDev i dont know |
| 15:58.39 | schmidts | black187 you have the code :P |
| 15:59.35 | schmidts | UnixDev i am looking at the code if this could even happens |
| 15:59.37 | black187 | Yeah, it looks nice (the code), but this is too hard for me. The problem is, that the partner cannot tell me, why they need 100rel - strange request... |
| 16:06.04 | schmidts | UnixDev this BYE in your pastebin comes from the peer and is not sent from asterisk |
| 16:08.38 | schmidts | UnixDev just try what i have said to you and tell me tomorrow if it worked ;) |
| 16:09.19 | UnixDev | schmidts: I will, thank you |
| 16:09.54 | schmidts | your welcome |
| 16:09.58 | schmidts | cya tomorrow ;) |
| 16:31.56 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.242.158.134) |
| 16:38.03 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 16:38.03 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 16:58.59 | WIMPy | I still have the problem with current trunk, that th remote console goes silent after some time. |
| 17:00.09 | WIMPy | Any arriving call will definitely silence it. It won't even produce output for things like 'sip show peers' or 'core show application dial'. |
| 17:00.26 | WIMPy | It will remain silent until the remote console is restarted. |
| 17:02.52 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 17:06.35 | mjordan | WIMPy: if you roll back to r346350 of trunk, do you still have the problem? |
| 17:08.33 | WIMPy | No |
| 17:08.43 | WIMPy | That's ok. |
| 17:12.03 | WIMPy | BTW: Is anyone here in to the wct4xxp driver? |
| 17:28.57 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-ldozxzesrdvzrqot) |
| 17:29.38 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:29.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:47.14 | mjordan | Corydon76-work: I'm having the same problem as WIMPy above (^^^^) with the channel verbose patch applied: a remote console becomes unresponsive when no verbose flag is present. In fact the behavior can manifest even without calls coming in - simply executing 'core show threads' seems to cause it to become unresponsive. In light of that, I'm going to back the patch out until it can be debugged / tested further |
| 17:48.21 | WIMPy | Well, unresponsive may not be the right word. You just go blind. |
| 17:51.44 | mjordan | fair enough |
| 17:53.43 | WIMPy | Almost. |
| 17:54.14 | WIMPy | To be precise I still get the last Verbose() of each call from within the h extension. |
| 17:55.54 | mjordan | hm. It manifests slightly differently for me |
| 17:56.12 | mjordan | either way, this is not the only interesting behavior witnessed |
| 18:07.32 | pabelanger | So, asterisk commit r347953, I am not sure we should be adding this to asterisk 10. |
| 18:08.01 | pabelanger | My logic is, we'll basically break somebodies asterisk configuration in 10.0.1 |
| 18:08.24 | pabelanger | if somebody builds there pbx using the sample configs |
| 18:08.42 | pabelanger | EG: Debian (maybe Redhat) packages |
| 18:09.39 | pabelanger | s/10.0.1/10.1.0/ |
| 18:13.17 | mjordan | pabelanger: I think we've agreed that it will not go into 10 at this time |
| 18:21.18 | Corydon76-work | mjordan: Okay |
| 18:39.23 | *** join/#asterisk-dev JerJer (~JerJer@asterisk/original-h323-guy/JerJer) |
| 18:40.01 | JerJer | is there a specific channel for Asterisk 10 development ? |
| 18:41.52 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.156) |
| 18:42.51 | JerJer | i am working with a somewhat custom RHEL envrionment and there doesnn't seem to be an sqlite3-devel specific package - however /usr/lib64.sqlite3.so.0.8.6 does exist |
| 18:43.08 | JerJer | lib64/ |
| 18:43.18 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.156) |
| 18:43.54 | kpfleming | JerJer: no, this is the channel for all Asterisk stuff |
| 18:44.36 | JerJer | adding --with-sqllite3=/usr/lib64 doesn't seem to help |
| 18:45.12 | JerJer | i see sqlite3_open when i run strings on libsqlite3.so |
| 18:46.29 | kpfleming | if you don't have the devel package installed, you don't have headers |
| 18:46.34 | kpfleming | so the code can't be compiled |
| 18:46.52 | kpfleming | the --with option would never point directly to the library directory |
| 18:47.00 | JerJer | ok - will complie sqlite directly then, i guess |
| 18:47.12 | JerJer | so much for package management :) |
| 18:47.19 | kpfleming | JerJer: what version of RHEL is your system based on? |
| 18:48.39 | JerJer | its a strange RHEL 4 on 5 situation |
| 18:48.47 | kpfleming | oh |
| 18:48.58 | kpfleming | well... yeah, you might have to build sqlite3 from source then |
| 18:49.28 | JerJer | yeah - building sqlite from source seemed to help.... so far |
| 19:06.50 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 19:10.52 | tzafrir | for rhel5 it should be avaiable from EPEL ("sqlite") |
| 19:11.14 | tzafrir | JerJer, ==^ |
| 19:36.42 | JerJer | tzafrir: I figured it out. The environment here is very custom. include files are not in the expected locations :( |
| 19:39.27 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 19:39.27 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 19:53.04 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 19:55.09 | alecdavis | who looks after svn access these days. mines expired :( |
| 19:55.33 | mjordan | alecdavis: I'll get the right people notified |
| 19:56.05 | mjordan | sorry I hadn't pinged you back yet, but you were flagged for follow up :-) |
| 19:56.14 | alecdavis | cool, thanks. |
| 19:59.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 20:39.51 | tzafrir | asks again |
| 20:40.05 | tzafrir | Regarding the sip.conf change from AST-2011-013: |
| 20:40.46 | tzafrir | Is there a way to tell asterisk: "I know my config is insecure, please don't warn me about it"? |
| 20:41.07 | tzafrir | (On a peer entry? globally in sip.conf?) |
| 20:49.18 | Corydon76-work | tzafrir: sounds like a recipe for disaster |
| 20:49.50 | tzafrir | Corydon76-work, Is there a use for that config option? |
| 20:50.04 | tzafrir | If so, that noisy warning has practically disabled it |
| 20:50.13 | tzafrir | If no: why not just disable it? |
| 20:50.32 | Corydon76-work | I think if you want to avoid warnings, you can turn them off in logger.conf |
| 20:50.58 | tzafrir | (and yeah. I know now is not a good time to question something that was discussed before on the list. Sorry) |
| 20:51.15 | tzafrir | No. I don't want to avoid warnings. |
| 20:51.43 | tzafrir | Everybody mentioned the example of the cisco phones. |
| 20:52.16 | tzafrir | Let's assume I have one such odd phone that will break with force_rport |
| 20:52.32 | Corydon76-work | It's basically a question of not wanting to see certain warnings when we've made the determination that the behavior is bad enough to warrant a warning. It's open source. If you really, really hate that warning, you can alter the source and recompile |
| 20:53.22 | tzafrir | So disable it on that specific user. Thus an attacker will not be able to enumerate most of my users |
| 20:53.33 | tzafrir | But still I get ugly warnings |
| 20:53.50 | Corydon76-work | Well, the other side of it is that if you have such odd phones, then you should consider only using them interior to a secured network |
| 20:54.19 | tzafrir | But I vaguely recall from the discussion that nobody was able to come with a good example of a device that actually needs it |
| 20:54.31 | tzafrir | Is there really a use for disabling force_rport? |
| 20:55.09 | Corydon76-work | Yes, in case somebody does have such a phone, we don't wanna deal with the bug report |
| 20:55.49 | Corydon76-work | Also, it's needed for SIP compliance testing |
| 20:56.59 | tzafrir | So in various cases I will not really care about that warning. |
| 20:57.17 | tzafrir | Or maybe: it will not apply to me. And thus I will prefer to hush it |
| 20:57.22 | Corydon76-work | Somebody should count the number of times that the SIP specification mandates bad behavior from a security standpoint and issue a joke RFC of the type "SIP is a security hole" |
| 20:58.04 | tzafrir | You have ~4.5 monthes |
| 20:58.20 | Corydon76-work | I know I've written a few of those security advisories, myself |
| 21:01.05 | tzafrir | Well, you do practically break this configuration option for them |
| 21:01.14 | tzafrir | by making it too noisy to use |
| 21:01.38 | Corydon76-work | Or maybe we inspire a few device manufacturers to fix their devices |
| 21:03.14 | tzafrir | This fix is something I would really hate introducing into Debian Stable |
| 21:05.18 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 22:01.36 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 22:31.54 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-zxtukodsnvcijyqb) |
| 22:42.33 | *** join/#asterisk-dev Tim_Toady (~fuzzy@77.49.234.191.dsl.dyn.forthnet.gr) |
| 22:50.21 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 22:50.21 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 22:54.30 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 23:07.00 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 23:09.29 | WIMPy | It would be nice if such warnings were only given once. |
| 23:24.24 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |