| 00:18.47 | *** join/#asterisk-dev acidfu (~inetrio.c@69-196-135-48.dsl.teksavvy.com) |
| 00:49.23 | *** join/#asterisk-dev luckman212 (~irc@2001:470:8abb:0:8c4c:ca87:2fc8:2a46) |
| 01:15.52 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:15.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:44.17 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 01:44.17 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 02:18.49 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:18.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:34.13 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 03:34.13 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 03:34.13 | *** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:34.15 | *** mode/#asterisk-dev [+oo file leifmadsen] by zelazny.freenode.net |
| 03:34.49 | *** join/#asterisk-dev yosafbridge (~yosafbrid@li125-242.members.linode.com) |
| 03:36.51 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 05:30.40 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 05:35.35 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 05:35.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:25.55 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:25.57 | schmidts | good morning |
| 06:28.02 | *** join/#asterisk-dev bulkorok (~bulkorok@217.110.197.225) |
| 06:39.26 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 06:39.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:11.23 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:b4ff:fbfa:fd7c:cbff) |
| 07:49.24 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:49.24 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:54.15 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 07:54.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:18.30 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 10:18.31 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 10:21.54 | *** join/#asterisk-dev black187 (~black187@77.234.149.118) |
| 10:23.51 | black187 | Hi guys, I'm testing the websocket support for asterisk 11 beta1, and having trouble making asterisk answer it with SIPML5 app - I can see it sending TCP connections to Asterisk via 5062 port - and I get no response. As a checked the Asterisk configuration, the only thing for a sip user to modify is transport=ws - is that all, or do I have to change anything else? |
| 10:27.29 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 10:46.35 | *** join/#asterisk-dev bulkorok (~bulkorok@217.110.197.225) |
| 11:34.24 | *** join/#asterisk-dev jmls (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 11:35.06 | jmls | can I just confirm something: is the size of the accountcode field in cdr is small (like < 20 chars) ? |
| 11:35.40 | kpfleming | jmls: do mean in the ast_cdr structure, or somewhere else? |
| 11:37.35 | jmls | I set a 24-char field using set(CDR(accountcode)=some24charvalue) |
| 11:38.24 | jmls | ie set it to 502807e9b9e737036d000018 |
| 11:38.36 | jmls | but got 502807e9b9e737036d0 in the manager cdr event |
| 11:40.06 | seanbright | #define AST_MAX_ACCOUNT_CODE 20 |
| 11:40.11 | seanbright | so 19 characters |
| 11:40.57 | jmls | yeah, so why do I get " accountcode: '502807e9b9e737036d000018'" in the cel NewAccount event ? |
| 11:40.59 | jmls | :* |
| 11:41.41 | jmls | "two men say they're Jesus, one of them must be wrong" |
| 11:42.36 | seanbright | because account codes in CEL don't have the same limitation |
| 11:43.06 | *** join/#asterisk-dev micols (~t@rlogin.dk) |
| 11:43.41 | jmls | that's my point - there's an inconsistency here. I used set(CDR(accountcode)), get a 19 char in cdr, but full size in cel |
| 11:44.52 | kpfleming | sure. but there's no reason CEL should be constrained to the size that CDR supports. |
| 11:45.12 | jmls | sorry, not cel. |
| 11:45.16 | jmls | my mistake |
| 11:45.34 | jmls | stops |
| 11:45.39 | jmls | yes, in cel. |
| 11:45.53 | seanbright | it's too early for this shit |
| 11:45.57 | seanbright | :D |
| 11:46.06 | kpfleming | jmls is a few hours ahead of us |
| 11:46.26 | seanbright | if this is your statement: "the behavior of CDRs and CEL events are inconsistent" |
| 11:46.27 | jmls | you shouldn't report a different account code in cdr and cel. the account code is _quite_ important when it comes to billing ;) |
| 11:46.30 | seanbright | then that is a true statement |
| 11:46.50 | seanbright | jmls: agreed, you shouldn't |
| 11:46.50 | kpfleming | and if you are going to use CDRs, then you should limit your account codes to what will fit there |
| 11:46.59 | kpfleming | but if you are going to use only CEL, then have at it |
| 11:47.04 | jmls | that's what I've just figured. :( |
| 11:47.43 | jmls | goes and changes the code to #define AST_MAX_ACCOUNT_CODE 32 |
| 11:47.58 | kpfleming | what, you have the source? blasphemy. |
| 11:47.59 | seanbright | when you build a system sufficiently advanced, CDRs are all but useless |
| 11:48.13 | kpfleming | seanbright: and the bar for 'advanced' is pretty low |
| 11:48.17 | seanbright | yes |
| 11:48.34 | seanbright | most of the applications i have seen/worked with look something like this: |
| 11:48.56 | seanbright | exten => _NXXNXXXXXX,1,AGI(record-call-start) |
| 11:49.03 | seanbright | exten => h,1,AGI(record-call-end) |
| 11:49.18 | kpfleming | yeah |
| 11:49.47 | seanbright | and then in the middle you associate the stuff you want to associate and ignore everything else |
| 11:49.58 | file | ignores seanbright |
| 11:50.18 | jmls | mm. userfield may do instead. |
| 11:50.42 | seanbright | the limit is certainly higher |
| 11:52.06 | jmls | it does indeed. problem solved ;) |
| 12:04.34 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 12:14.13 | acidfoo | moorning |
| 12:17.01 | acidfoo | When I transfer a call A->B->C (A->C) using ast_channel_masquerade(), does the update_peer callback is supposed to get called ? Because A->B was in directmedia, and I need to update the RTP information on A after it is being transfered... so I'm wondering what is suppose to indicate A that is has been transfered |
| 12:21.57 | schmidts | acidfoo signaling like sip still runs over asterisk so there isnt a problem if A and B are setup with directmedia |
| 12:22.40 | schmidts | A gets a reinvite for the new destination of the call to C, typically this is asterisk in the first step and if A->C can also do directmedia this would be done in a new reinvite after A->asterisk->C is setup correctly |
| 12:24.42 | acidfoo | for the re-invite to be sent, I guess there is some callback called that says "hey, you've just been transfered, or hey, we've just got bridged to an another channel" so it can fire the re-invite ? |
| 12:25.27 | acidfoo | what I need to do is to tell A stop sending RTP at this ip/port, and now send RTP at this new RTP/port |
| 12:25.52 | acidfoo | but for that I need to know that I've got bridged to another channel (transfered) so I can trigger this |
| 12:30.18 | schmidts | acidfoo this happens in chan_masquerade IMHO |
| 12:31.54 | acidfoo | i'll digg deeper into that function to better understand that it does... because now I so none of my callback getting called ;/ |
| 12:32.46 | acidfoo | well I only see .get_rtp_info and indicate with a AST_CONTROL_SRCCHANGE: |
| 12:44.42 | acidfoo | I don't see much stuff in ast_channel_masquerade() that point me about what i'm looking for ;/ |
| 12:58.03 | *** join/#asterisk-dev luckman212_ (~irc@2001:470:8abb:0:8c4c:ca87:2fc8:2a46) |
| 13:00.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:00.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:02.46 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-rogyfkgyollpduat) |
| 13:02.46 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:14.26 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:21.26 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-urixuacqbfrebhjr) |
| 13:21.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:30.28 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-khedwppuntejofcx) |
| 13:33.45 | leifmadsen | ok I'm doing something stupid. I've followed the Subversion Usage page, and I'm getting this still on an svn up: svn: E175002: OPTIONS of 'https://origsvn.digium.com/svn/asterisk/trunk': SSL handshake failed: SSL alert received: CA is unknown (https://origsvn.digium.com) |
| 13:34.12 | mjordan | leifmadsen: it may not be you |
| 13:34.17 | leifmadsen | oh really |
| 13:34.20 | leifmadsen | huh |
| 13:34.34 | leifmadsen | I just assumed because I haven't had this setup for a while |
| 13:36.51 | mjordan | leifmadsen: you may want to ping Qwell and see if your client cert is still valid |
| 13:36.59 | leifmadsen | mjordan: good call |
| 13:37.01 | leifmadsen | Qwell: ping! :) |
| 13:37.13 | leifmadsen | mjordan: I had it backed up on a drive, but not sure if it's my old one or new one |
| 13:44.39 | *** join/#asterisk-dev oej_ (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 13:44.41 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 13:52.03 | acidfoo | mjordan, Hello |
| 13:52.58 | acidfoo | mjordan, do you happen to know why update_peer is not called for 'A' when I do a transfer (ast_channel_masquerade()) A->B->C ... A->C |
| 13:53.27 | acidfoo | because I want to tell 'A' to stop transmitting RTP to 'B' ip/port and start transmitting to 'C' ip/port |
| 13:54.13 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:54.13 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:55.49 | mjordan | acidfoo: update_peer is only going to be called when the appropriate control frame is relayed to the channel |
| 13:56.30 | mjordan | acidfoo: the masquerade code itself won't do that, because a masquerade doesn't care about things like 'rtp' layer. For all it knows, the channels involved don't have an RTP layer |
| 13:56.52 | mjordan | acidfoo: if you need that to happen in your channel driver, there is a channel callback that occurs when a masquerade is done on a channel |
| 13:57.09 | acidfoo | do you know the callback name ? :) |
| 13:57.12 | mjordan | acidfoo: you could queue up the RTP source update control frame when a masquerade happens |
| 13:57.28 | mjordan | looks |
| 13:57.55 | mjordan | fixup |
| 13:58.10 | mjordan | take a look at sip_fixup. |
| 13:58.24 | mjordan | it does some things in relation to this as well |
| 13:59.17 | acidfoo | ah yes |
| 13:59.30 | acidfoo | chan_sip call sip_set_rtp_peer() to readjust the peer |
| 13:59.30 | acidfoo | good |
| 13:59.32 | acidfoo | thank you ! |
| 13:59.35 | mjordan | np |
| 14:10.21 | WIMPy | Are there any guidelines on when to use ast_log, ast_debug, ast_verbose or ast_verb? |
| 14:14.20 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:20.26 | mjordan | WIMPy: ast_debug / ast_log are rather straight forward. If its a debug message (something only a developer would care about), ast_debug. If its a NOTICE, WARNING, or ERROR - ast_log |
| 14:22.15 | mjordan | WIMPy: in general, ast_verb is preferred to ast_verbose. ast_verb wraps __ast_verbose, and handles the levels in a consistent fashion |
| 14:23.43 | WIMPy | That makes sense so far, but when would ast_log and when ast_verb be the right choice? |
| 14:24.26 | WIMPy | ast_log spans all levels starting from debug. |
| 14:29.17 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:32.46 | mjordan | ast_log is when you have something that needs to be relayed, regardless of whether or not the user has set a verbose/debug level |
| 14:34.45 | mjordan | you are right - you can use ast_log and specify AST_LOG_DEBUG or AST_LOG_VERBOSE, and - at least in the case of ast_debug - by pass some of the option level checking |
| 14:35.21 | mjordan | but that would be (kind of) a misuse of ast_log. If you need debug, use ast_debug; verbose, use ast_verbose; everything else, ast_log. |
| 14:35.38 | mjordan | s/ast_verbose/ast_verb |
| 14:36.55 | WIMPy | Would it be right to say to use ast_verb for things of temporary interest and ast_log for stuff of permanent interest? |
| 14:37.39 | oej | ast_verb for things that the admin wants to see in the console during a call |
| 14:38.03 | oej | ast_log is the core function we replaced with macros to make the code more readable, so it should propably not be used at all. |
| 14:38.16 | oej | It's the RAW api. |
| 14:39.04 | leifmadsen | might not be a bad idea to add doxygen docs (if not already existing) for that |
| 14:39.30 | jrose_atDigium | Um... ast_log is used whenever you want to make a log message not falling into either the verbose or debug categories. |
| 14:40.57 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:40.57 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:41.02 | jrose_atDigium | I don't think it's ever been replaced with anything. ast_verb is just preferred when you would otherwise use ast_log(LOG_VERBOSE, ...) or ast_verbose(X, ...) |
| 14:41.39 | jrose_atDigium | actually, I don't think verbose has that first argument, so ignore that. |
| 14:42.05 | WIMPy | no |
| 14:44.29 | oej | Right, jrose, we replaced the usage of ast_log where we had if (somevalue) {ast_log} with a one-line-macro |
| 14:44.44 | oej | we never replaced. You're right. |
| 14:44.45 | jrose_atDigium | oh, yeah, that makes sense |
| 14:44.57 | jrose_atDigium | I wasn't actually around when that happened. |
| 14:45.56 | oej | Old people like me still remember a few random things. |
| 14:46.35 | jrose_atDigium | For a bit I thought you were saying ast_log itself was replaced, but yeah, I get what you meant now. |
| 14:48.04 | oej | we did replace a lot of code using ast_log, but converted to macros |
| 14:48.29 | oej | You can still use ast_log and there are a few cases where the macros did not work. |
| 14:50.54 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 14:52.03 | tzafrir_laptop | I asked by mail and got no response: what's the license of http://www.asterisk.org/files/new_prompts_july_2012.zip ? |
| 14:52.19 | oej | Oh no, not again |
| 14:52.35 | tzafrir_laptop | Last time I looked that archive included no copyright and license information. |
| 14:53.36 | jsmith | sighs |
| 14:54.12 | tzafrir_laptop | I did like the prompts |
| 14:56.40 | oej | I think both jsmith and I recognize this discussion. |
| 14:56.54 | oej | mjordan: THis is your issue. Please make sure that we get an answer. |
| 14:56.59 | oej | :-) |
| 14:57.13 | jsmith | Indeed... I remember the discussion well -- and that's time I'll never get back |
| 14:57.41 | newtonr | oej: i'm finding someone who knows the license status of those prompts :) or at least attempting too |
| 14:58.19 | oej | As a stubborn old man I still have documents in the wiki that I think should be moved back to the source. Moving everything to the wiki was a mistake and I keep having issues with it. |
| 14:58.35 | oej | Does the PDF still include a lot of unrelated stuff, like protocols from astridevcon meetings? |
| 14:58.52 | leifmadsen | no |
| 14:58.59 | leifmadsen | I fixed that a long time ago I'm pretty sure |
| 14:59.03 | oej | At least that's an improvement. |
| 14:59.14 | oej | Thanks for that leifmadsen :-) |
| 14:59.16 | leifmadsen | centralized documentation ftw in my opinion |
| 14:59.22 | leifmadsen | oej: don't thank me until you verify it |
| 14:59.40 | oej | Put that thank you on hold then. |
| 14:59.48 | leifmadsen | done and done |
| 14:59.59 | oej | centralized can be in the svn too, you know. Where it follows the source it documents. |
| 15:00.05 | mjordan | oej: tzafrir_laptop: I'll look into it |
| 15:02.18 | oej | mjordan: There is code in the SIP channel that has been marked experimental in 1.6.0, 1.6.1, 1.6.2, 1.8, 10 and soon 11. So you are wrong about Websockets being the only experimental code. |
| 15:02.40 | mjordan | oej: I should clarify: experimental code we *added* in 11. |
| 15:02.56 | mjordan | oej: I can't do anything about the past. |
| 15:03.09 | leifmadsen | mjordan: thought you had a time machine? |
| 15:03.14 | oej | We keep releasing experimental code without fixing it. |
| 15:03.18 | mjordan | leifmadsen: it broke :-( |
| 15:03.21 | oej | AS I said, either fix it or remove it. |
| 15:03.22 | leifmadsen | mjordan: eff |
| 15:03.40 | oej | It's not about the past, that's wrong. It's about the code you're about to release now. |
| 15:03.44 | leifmadsen | we should probably do that, yes. |
| 15:04.12 | mjordan | oej: are you referring to directrtpsetup? |
| 15:05.21 | oej | as well as the TCP/TLS implementation. |
| 15:05.38 | mjordan | oej: so, tcp/tls we fix bugs in |
| 15:06.26 | mjordan | oej: as far as directrtpsetup is concerned, some folks do use it, and we've been in talks with them about how to make it better. It does work in certain circumstances, but I agree that it is not as reliable as it should be |
| 15:06.28 | oej | mjordan: Go read the source code and you will see along list of quite fundamental issues that has not been fixed. That was wrong in the code from start. |
| 15:07.10 | jrose_atDigium | oej: Are you talking about TCP/TLS right now or are you talking about the directrtpsetup? |
| 15:07.23 | oej | TCP/TLS |
| 15:07.26 | WIMPy | has directrtpsetup enabled. |
| 15:07.38 | oej | The directrtp would not have been committed with the current review policies. |
| 15:07.46 | mjordan | oej: you are correct about that :-) |
| 15:07.57 | mjordan | oej: which is why we're working on fixing it |
| 15:08.18 | russellb | signal to noise ratio continues to get worse and worse ... |
| 15:08.20 | leifmadsen | there are probably a lot of things that wouldn't have been committed with the current review policies |
| 15:08.31 | leifmadsen | that's not really a valid talking point |
| 15:08.49 | putnopvut | *cough* imap voicemail *cough* |
| 15:12.25 | acidfoo | <PROTECTED> |
| 15:15.35 | oej | Why do I get conflicts in 10 different files I haven't touched in my branch when trying to merge it up to date? It happens more and more often. |
| 15:17.21 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.116.90) |
| 15:20.10 | pabelanger | newextenpatternmatch? |
| 15:20.13 | pabelanger | hides |
| 15:20.39 | opticron | heh |
| 15:21.27 | opticron | I've made some minor fixes to the newextenpatternmatch engine to make it behave more like the current one |
| 15:21.38 | opticron | it's still not exact, though |
| 15:21.58 | WIMPy | When was that? |
| 15:22.06 | Qwell | opticron: Are you aware of the weird issue jmls had recently? |
| 15:22.35 | opticron | WIMPy, quite a while back |
| 15:22.41 | opticron | Qwell, no, issue? |
| 15:22.43 | Qwell | oh, well then. |
| 15:22.50 | Qwell | Highly unlikely |
| 15:23.05 | leifmadsen | Qwell: ohai! |
| 15:23.09 | WIMPy | I think it was about two months ago I tried it and it failed completely. |
| 15:23.10 | Qwell | leifmadsen: lies and slander. |
| 15:23.23 | leifmadsen | Qwell: I'd like to validate my lmadsen-cert.p12 file plz |
| 15:23.24 | opticron | I think some of the testsuite tests fail when that's enabled as well |
| 15:23.34 | Qwell | leifmadsen: Validation failed. |
| 15:23.35 | leifmadsen | Qwell: since I can't connect to origsvn |
| 15:23.36 | Qwell | (checking) |
| 15:24.23 | Qwell | mmm, it's still valid |
| 15:24.28 | Qwell | need a new copy? |
| 15:51.35 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:51.37 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:57.57 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 15:57.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:04.48 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 16:32.10 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 16:32.11 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:51.43 | *** join/#asterisk-dev n0tk (~n0tk@gateway/tor-sasl/n0tk) |
| 17:03.52 | *** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 17:07.39 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-wvdlqpxnxddpxrus) |
| 17:07.39 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:11.23 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 17:11.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:47.44 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 17:47.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:11.58 | *** join/#asterisk-dev jpepper (~jpepper@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 19:13.26 | jpepper | Is anyone looking at ASTERISK-20237? I ask because I think I figured out what's going on, but I don't want to step on anyone's toes. |
| 19:14.24 | pabelanger | jpepper: just attach your patches to the issue |
| 19:14.29 | pabelanger | that we can triage it from there |
| 19:14.42 | pabelanger | s/that/then |
| 19:14.48 | leifmadsen | any work being done on the issue would be posted there |
| 19:14.57 | leifmadsen | so if you see no work, assume no one is working on it ;) |
| 19:15.38 | jpepper | Fair enough… thanks! |
| 19:35.59 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 19:36.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:24.48 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 21:01.06 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 21:19.38 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 21:19.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 22:17.16 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-urixuacqbfrebhjr) |
| 22:22.18 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 22:22.18 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:48.41 | *** join/#asterisk-dev acidfu (~inetrio.c@206-248-131-201.dsl.teksavvy.com) |