| 00:14.14 | *** join/#asterisk-dev acidfoo_ (~acidfoo@108.175.228.140) |
| 00:49.59 | *** join/#asterisk-dev kasanop1 (~kasanop@ivanpoddubny.com) |
| 00:55.02 | *** join/#asterisk-dev lumasepa (~gestoip@193.145.124.30.local.ull.es) |
| 01:03.04 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 01:15.41 | kpfleming | file: stabbity |
| 01:15.53 | file | deflects |
| 01:17.07 | file | offers kpfleming some water |
| 01:24.09 | kpfleming | i need some cookies. oh look, there are some right here. |
| 01:24.31 | file | I lack cookies but I did have some milk chocolate covered Lay's |
| 01:24.55 | kpfleming | what about salty potato covered chocolate? |
| 01:25.15 | file | I'm afraid not |
| 01:29.04 | *** join/#asterisk-dev gtjoseph_ (~gtjoseph@unaffiliated/gtj) |
| 01:33.46 | *** join/#asterisk-dev gtjoseph (~gtj@unaffiliated/gtj) |
| 01:34.41 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-arnxhbjtnvtlhiqv) |
| 01:56.48 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 02:41.47 | *** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net) |
| 07:06.49 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:51.43 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:52.21 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:07.18 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:38.29 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:38.29 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:40.04 | *** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-lognpfvmymqotvyi) |
| 08:40.38 | *** join/#asterisk-dev GameGamer43 (sid5533@gateway/web/irccloud.com/x-yeqnyktgrzqrtafz) |
| 08:57.57 | *** join/#asterisk-dev oej (~oej@c-89-160-55-195.cust.bredband2.com) |
| 08:57.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:37.11 | *** join/#asterisk-dev oej (~oej@c-89-160-55-195.cust.bredband2.com) |
| 09:37.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:15.23 | WIMPy | [13:46] hexanol has joined #asterisk-dev |
| 10:15.28 | WIMPy | (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 10:15.30 | WIMPy | <file> do you wanna build a snowmannnnnnnnn |
| 10:15.33 | WIMPy | [14:29] [TK]D-Fender has joined #asterisk-dev |
| 10:15.40 | WIMPy | (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 10:15.42 | WIMPy | [14:39] fr8nk87 has left IRC (Ping timeout: 276 seconds) |
| 10:15.45 | WIMPy | [15:00] otherwiseguy has joined #asterisk-dev |
| 10:15.50 | WIMPy | (~otherwise@23-255-230-241.mci.googlefiber.net) |
| 10:15.52 | WIMPy | [15:09] acidfoo_ has joined #asterisk-dev |
| 10:15.58 | WIMPy | (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 10:16.02 | WIMPy | [15:22] cresl1n has joined #asterisk-dev |
| 10:16.04 | WIMPy | (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 10:16.06 | WIMPy | [15:22] ChanServ makes cresl1n +o |
| 10:16.09 | WIMPy | <file> woah cresl1n |
| 10:16.11 | WIMPy | <cresl1n> file!!!! |
| 10:16.14 | WIMPy | <file> WOAH CRESL1N |
| 10:16.16 | WIMPy | <cresl1n> FILE!!!!! |
| 10:16.21 | WIMPy | <file> oh, hi |
| 10:16.26 | WIMPy | Argl |
| 11:04.04 | *** join/#asterisk-dev nunopereira (~nuno.pere@alpes.nortenet.pt) |
| 11:10.32 | nunopereira | Hi all. We're implementing call interception in asterisk. We have a an AGI script that receives the calls, checks on DB if it needs to register meta data, intercept the audio and send back the call, so that it's sent to the destination. This works, but it needs to be transparent to both the call originator and call destination. |
| 11:10.46 | nunopereira | All channels are SIP, and the best approach would be that there were no Headers manipulation. |
| 11:11.23 | nunopereira | We're using Monitor() to save the audio and Dial() to send back the call, but Dial() manipulates the headers. |
| 11:12.33 | nunopereira | We're using AGI. Is it possible to have Asterisk receive a call and transparently send it back, without headers manipulation and recording the audio? |
| 11:23.41 | *** join/#asterisk-dev oej (~oej@c-89-160-55-195.cust.bredband2.com) |
| 11:23.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:28.33 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:28.33 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:36.00 | file | nunopereira, Asterisk is not a SIP proxy it's a B2BUA so they will always be completely separate call legs |
| 11:36.48 | file | some stuff can be conveyed across such as CallerID, but otherwise the headers will differ |
| 11:40.45 | nunopereira | @@file, not all headers must be equal (and that's impossible) |
| 11:41.20 | nunopereira | what it needs is to be transparent to both end users |
| 11:42.24 | nunopereira | which aren't connected directly to the Asterisk server. Asterisk is acting as an intermediate step on (some of) the calls |
| 11:44.09 | file | what does "needs to be transparent to both end users" mean? as I said, you can convey some stuff across but otherwise it'll be different... |
| 11:49.16 | nunopereira | is resume, that an intercepted called and a non-intercepted call have no visible difference: both are received from "123456" and not from "654321", if one is received from "anonymous" then the other isn't from "Anonymous", if one is from "anoymous" then the other isn't from "unknown", if one takes 3 seconds to be established then the other doesn't take 5 or 6, if one has a "Contact:unknown:X.Y.Z |
| 11:49.16 | nunopereira | ..." then the other has a "Contact:X.Y.Z ...", etc |
| 11:50.37 | file | you can ensure some of that but otherwise without hacking stuff up there's no guarantees, particularly on such things as the Contact header |
| 12:08.21 | stefan27 | I'm really happy with the responsiveness of the #asterisk channels. Many communities ive been in are really unresponsive, creds to you especially file |
| 12:09.18 | file | stefan27, glad to hear it! it makes the people shouting "why isn't this getting worked on? why has noone responded to me yet?" less bothersome :D |
| 12:10.24 | skrusty | :) |
| 12:18.12 | stefan27 | #webrtc is all right too, but whenever someting only has a developersupport-email for question it takes ages to get a response (I do understand why -- it's not paid support so they invest their time based on common good) |
| 12:20.39 | file | nods |
| 12:21.09 | file | I'll happily answer questions but I can't take a day to explain in intricate detail how to completely do something |
| 12:24.01 | file | in particular when it's for a company who has no intention of contributing back >_> |
| 12:26.30 | file | on an unrelated note - THURSDAY! |
| 12:28.54 | stefan27 | I've only had that type of role of assisting people in #math but only on spare time; in professional life 99% of the time im the one asking the questions. The challenge in asking questions is usually that in order to phrase a question _well_ you need to understand the problem context well, and when you do understand the problem context well you can often solve the problem yourself too |
| 12:29.34 | file | sometimes, yes |
| 12:30.07 | nunopereira | on a side note, I second stafan27 on what he said, specially about file |
| 12:30.32 | file | I KNOW NOTHING |
| 12:31.44 | nunopereira | @file, what do you mean by "some stuff can be conveyed across such as CallerID" and "without hacking stuff up"? |
| 12:31.53 | nunopereira | :) |
| 12:32.22 | file | nunopereira, CallerID is conveyed through the Asterisk core and can be set on outgoing legs - but otherwise you aren't guaranteed that the other leg will match the incoming in any way |
| 12:34.18 | file | to try to do otherwise would require testing and then manually adjusting code most likely |
| 12:56.06 | *** join/#asterisk-dev pc-m (~user@modemcable094.94-70-69.static.videotron.ca) |
| 12:56.21 | nunopereira | we're calling «$AGI->exec('Dial', "SIP/$original_trunk/$input{'extension'}, 300");» in order to dial the new call |
| 12:57.47 | nunopereira | input is being filled with %input = $AGI->ReadParse(); |
| 12:57.58 | nunopereira | and isn't being manipulated |
| 12:59.45 | nunopereira | with that, we're pretty much getting what we need, but not everything, as you said |
| 13:22.41 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 14:03.15 | *** join/#asterisk-dev acidfoo_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 15:10.47 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-qittpxwzddpcpnsz) |
| 15:22.21 | *** part/#asterisk-dev lumasepa (~gestoip@193.145.124.30.local.ull.es) |
| 15:37.41 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-sopqnoxjmvtkhufs) |
| 15:38.41 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-scqxukloxtdfbfwd) |
| 15:38.41 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:39.58 | *** join/#asterisk-dev Qwell (~north@asterisk/developer/Qwell) |
| 15:39.58 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 16:06.18 | gtjoseph | Wow! mjordan's back on IRC!! |
| 16:10.16 | file | sometimes |
| 16:22.34 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 16:22.34 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Hell hath frozen over: Asterisk is moving to Git -=- Follow on Twitter at @AsteriskDev |
| 16:44.26 | *** join/#asterisk-dev roramirez (~rodrigo@190.209.106.228) |
| 16:44.38 | roramirez | Hello guys |
| 16:51.39 | file | helllllllo |
| 16:52.28 | roramirez | i have a stranger situation in my test system. In the same system, with version 11 is set ICE cantidates in the SDP but dont have the same result with 13.7.2. I try the debug the problem in the 13.7.2 |
| 16:52.48 | roramirez | i using chan_sip |
| 16:53.33 | roramirez | in 13.7.2 when call to add_ice_to_sdp is return in |
| 16:53.33 | roramirez | /* If no ICE support is present we can't very well add the attributes */ if (!ice || !(candidates = ice->get_local_candidates(instance))) { return; } |
| 16:53.59 | roramirez | the ice var is null |
| 16:55.55 | roramirez | the ldd of res_rtp_asterisk.so of differents Asterisk http://pastebin.com/b0cyq36j |
| 16:56.23 | roramirez | the ice is set in rtp.conf for 13.7.2 |
| 16:59.07 | roramirez | What could it be? |
| 17:15.15 | file | do you have pjproject installed? |
| 17:16.19 | roramirez | no, i using chan_sip |
| 17:16.42 | file | pjproject was included in 11 but was removed in 13, as a result you have to install it to get ICE/STUN/TURN support |
| 17:17.50 | roramirez | ok, understand |
| 17:17.55 | roramirez | let me try |
| 17:18.13 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-qjdrlgdepezfilml) |
| 17:21.06 | roramirez | i see, https://github.com/asterisk/asterisk/blob/13.7/res/res_rtp_asterisk.c#L2556 |
| 18:38.55 | *** join/#asterisk-dev lnxslck (~lnxslck@av3-84-90-160-135.netvisao.pt) |
| 19:13.42 | roramirez | is work with pjproject to add ice candidates. Thanks file ! |
| 19:13.51 | file | you're welcome |
| 19:15.27 | roramirez | maybe is neccessary add a note into https://wiki.asterisk.org/wiki/display/AST/Interactive+Connectivity+Establishment+%28ICE%29+in+Asterisk |
| 19:15.56 | file | if you add a comment mentioning what you'd like to see it can be added |
| 19:17.21 | acidfoo_ | $ grep "p->initreq.data" chan_sip.c |
| 19:17.21 | acidfoo_ | if (!p->alreadygone && p->initreq.data && ast_str_strlen(p->initreq.data)) { |
| 19:17.22 | acidfoo_ | if (ast_str_strlen(p->initreq.data) > 0) { |
| 19:17.38 | acidfoo_ | in asterisk 11.21.2 |
| 19:17.51 | *** join/#asterisk-dev lnxslck (~lnxslck@av3-84-90-160-135.netvisao.pt) |
| 19:17.53 | acidfoo_ | the first one properly check if initreq.data is NULL, not the second one :| |
| 19:25.07 | acidfoo_ | if that interest anyone... |
| 19:41.42 | gtjoseph | Can someone grab Mark? re 2368 |
| 19:43.15 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 19:43.15 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 19:45.07 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:45.08 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:45.32 | gtjoseph | putnopvut: So, the sceanrio you describe in 2368 is correct but I changed the "no matching endpoint" message to a debug 1 |
| 19:45.42 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:45.42 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:45.43 | gtjoseph | except it did it in the wrong patch. :) |
| 19:46.12 | gtjoseph | the big sorcery realtime optimization patch has the change for the message |
| 19:46.45 | putnopvut | oops. Well, just to go on record, I don't like the idea of changing that to a debug message. That's a legitimate problem and should not be relegated to a debug message. |
| 19:47.17 | gtjoseph | well, it's not really though. |
| 19:47.29 | gtjoseph | it indicates that a client screwed up. |
| 19:47.43 | putnopvut | My biggest problem with the issue on 2368 is that I just don't understand the use case. If I can understand that better, then I might appreciate the code change more. But as it stands, my thinking is that the problem is "I don't want to change my configuration" to which the solution is "tough shit" |
| 19:48.08 | gtjoseph | an Anonymous header won't match anything |
| 19:49.47 | putnopvut | So a couple of things: 1) If you have local phones connected to Asterisk, why would you be sending anonymized caller ID to Asterisk in the first place? Asterisk should be in charge of doing that to the call once it's directed outbound. 2) If you're receiving calls from a second Asterisk or a SIP provider that are anonymized, then that's not a good time to be recognizing by username in the first place. Identifying the endpoi |
| 19:49.48 | putnopvut | nt by IP address or using the line option for an outbound registration fits that case much better. |
| 19:50.44 | gtjoseph | But that only works when you control the remote end. |
| 19:51.11 | gtjoseph | whether it's a phone, pbx, provider, whatever |
| 19:51.14 | putnopvut | What do you mean by "remote end?" |
| 19:51.35 | gtjoseph | the sender of the message with the From header. |
| 19:52.27 | gtjoseph | The sender may authenticate but still send Anonymous in the from |
| 19:52.36 | putnopvut | So, what are the situations where you aren't in control? You're either talking with another PBX, a provider, or some other "peer" of some sort. In those cases, they very well may send you anonymized caller ID. But why would you be trying to recognize those peers by username in the first place? |
| 19:52.58 | gtjoseph | because that's all you have |
| 19:54.13 | putnopvut | Buy why though? What actual scenario involves that? Why would you not have an IP address/domain name/something that you can use to recognize who the incoming call is from? |
| 19:54.20 | gtjoseph | i'm a peer without a fixed address sending Asterisk an INVITE where presentation is prohibited. |
| 19:54.49 | gtjoseph | real life strikes again. :) |
| 19:54.52 | putnopvut | If you don't have a fixed address, then how am I supposed to ever send anything to the peer? |
| 19:55.07 | putnopvut | Do you have a DNS address that stays constant at least? |
| 19:55.41 | gtjoseph | Hmmm |
| 19:55.45 | gtjoseph | maybe |
| 19:57.26 | gtjoseph | i'm still thinking |
| 19:57.30 | putnopvut | The thing about this is, even if it turns out that there is a legit case where caller ID is anonymized and I don't know an IP address/domain name to match against, I still don't like using the authentication username as the matching method since 1) The Authorization header is not going to be present half the time, and 2) If you try changing the realm for the endpoint you're identifying by authentication, you're going to hav |
| 19:57.30 | putnopvut | e a bad time since Asterisk's "fake" authentication response it sends when it can't find an endpoint is hardcoded to use the realm "asterisk" |
| 19:59.18 | putnopvut | I have to run to a meeting. Sorry about the timing. |
| 19:59.27 | gtjoseph | no worries. i'll keep thinking |
| 20:04.37 | *** join/#asterisk-dev lnxslck (~lnxslck@av3-84-90-160-135.netvisao.pt) |
| 20:16.25 | gtjoseph | putnopvut: I've asked Ross to give me more info, but just thinking more... I can't even register if From can't be matched. |
| 20:21.09 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-unancbkcqlkgavdw) |
| 20:48.13 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dlhqdlhsujajlltt) |
| 21:12.40 | gtjoseph | putnopvut: i have a scenario and it's pretty obvious... |
| 21:12.46 | putnopvut | okie-dokie |
| 21:12.58 | gtjoseph | i'm a small business with a pbx... |
| 21:13.12 | gtjoseph | i register to a service provider |
| 21:13.24 | gtjoseph | the register works because it has a matchable endpoint |
| 21:13.33 | gtjoseph | i now send an INVITE |
| 21:13.37 | gtjoseph | poof. |
| 21:14.09 | gtjoseph | because the from has the From from the original call leg. |
| 21:15.03 | gtjoseph | this works in chan_sip BTW |
| 21:15.52 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-ldtonarkwdycnhoz) |
| 21:15.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:15.54 | gtjoseph | ;match_auth_username=yes ; if available, match user entry using the |
| 21:15.54 | gtjoseph | <PROTECTED> |
| 21:15.54 | gtjoseph | <PROTECTED> |
| 21:22.11 | putnopvut | I don't understand the scenario. So from your PBX, you send a REGISTER to the provider, and everything's gravy. Why do things go poof when you send an INVITE? |
| 21:22.43 | gtjoseph | what's the distributor going to match against? |
| 21:22.56 | putnopvut | I don't understand what's to match, we're sending an INVITE? |
| 21:23.15 | putnopvut | Are we looking from the provider's POV? |
| 21:23.35 | gtjoseph | customer sends an invite with a From that has a Callerid in it. |
| 21:23.45 | gtjoseph | what does Asterisk match against |
| 21:24.01 | putnopvut | This is why providers use IP address to know which customer a call is coming from. |
| 21:24.07 | gtjoseph | real world |
| 21:24.12 | gtjoseph | they don't |
| 21:24.27 | gtjoseph | I don't set up my customers that way |
| 21:24.31 | gtjoseph | they all register |
| 21:24.35 | gtjoseph | to providers |
| 21:26.05 | putnopvut | So how does the provider know that the registration is kosher to begin with? Is there some sort of out-of-band session between the customer and provider to say "I'll be sending a REGISTER with username XXXXX in it?" |
| 21:26.15 | gtjoseph | authed |
| 21:26.24 | gtjoseph | sorry, didn't mention that |
| 21:26.26 | file | this conversation confuses me so much |
| 21:26.36 | putnopvut | RIght, but how does the registrar know how to authenticate properly? |
| 21:26.47 | putnopvut | I'm with you file. |
| 21:26.51 | gtjoseph | they use chan_sip |
| 21:26.55 | gtjoseph | :) |
| 21:27.11 | gtjoseph | try it |
| 21:27.50 | putnopvut | That likely works with chan_sip because the authentication realm is globally configured rather than configurable per auth. |
| 21:28.12 | gtjoseph | it works because they have an option match_auth_username=yes |
| 21:28.14 | putnopvut | And I imagine that chan_sip's fake authentication challenges actually still use the globally-configured realm |
| 21:28.20 | putnopvut | Right, that too |
| 21:28.22 | gtjoseph | probably but that's ok |
| 21:28.48 | putnopvut | With res_pjsip_outbound_authenticator_digest, we send fake authentication with hard-coded "asterisk" as the realm. |
| 21:28.56 | gtjoseph | i can fix that easily. |
| 21:29.02 | putnopvut | How? |
| 21:29.05 | file | how could you "fix" that? |
| 21:29.15 | gtjoseph | even without it, if you just use asterisk all around you're ok |
| 21:29.19 | gtjoseph | by adding an option |
| 21:29.30 | gtjoseph | default_realm |
| 21:29.48 | putnopvut | Well that's great as long as you're only authenticating for a single realm. |
| 21:30.00 | gtjoseph | which is what service providers do |
| 21:30.27 | gtjoseph | what's the alternative? tell them "sorry"? |
| 21:32.39 | putnopvut | Well, the current alternative is what I've been saying: match on IP address/domain. Just because a service provider isn't currently doing that doesn't mean it can't be done. If you want to write up some new piece of code to match in a different way, then that's cool. But do so in a way that isn't going to result in not matching an endpoint half the time. |
| 21:34.06 | gtjoseph | match by ip/domain isn't viable. |
| 21:34.30 | gtjoseph | <PROTECTED> |
| 21:35.31 | gtjoseph | and if it's the message that's bothering you, then we shouldn't be spitting it out in the first place. |
| 21:35.48 | putnopvut | You're essentially undermining Asterisk's intent to ward off an attack by sending a fake authentication challenge. Plus the false positives for security events saying you're receiving messages from invalid endpoints. If you grow used to ignoring those warnings, then it can hide when you are actually being targeted by someone malicious |
| 21:36.43 | gtjoseph | im not understanding. we don't send any "extra" security events |
| 21:37.44 | gtjoseph | the only thing we do is spit out a NOTICE from the distributor. |
| 21:38.18 | putnopvut | If you are planning to match on authentication username, then we will. Alice sends an INVITE to us with anonymized caller ID. There's no Authorization header, so we don't find a matching endpoint. We send a security event saying an invalid endpoint tried to call us. We send a "fake" authentication challenge. Now Alice sends an INVITE with auth. |
| 21:38.36 | putnopvut | That initial SIP request from every call from Alice is going to result in invalid endpoint security events being sent. |
| 21:38.37 | gtjoseph | let me check again... |
| 21:43.22 | gtjoseph | Ah. I could swear that message wasn't there. |
| 21:43.26 | gtjoseph | it is, ok |
| 21:50.06 | gtjoseph | putnopvut: how about something like keepadead. :) If we don't find an endpoint match for the same ip address twice in a row, we spit out the event. |
| 21:50.57 | putnopvut | The idea being that we only are spitting out the security event when someone actually attempts authentication and we don't match the endpoint? Hmmm... |
| 21:51.14 | gtjoseph | even if they don't attempt |
| 21:53.19 | gtjoseph | 2 non matches in a row and we send the event |
| 22:04.05 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 22:04.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:23.22 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:39.18 | *** join/#asterisk-dev kasanop1 (~kasanop@ivanpoddubny.com) |
| 22:42.51 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-oifetlasedxbjefr) |
| 22:42.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 23:26.32 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 23:26.32 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |