| 00:11.53 | leifmadsen | danjenkins: ping |
| 00:13.58 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 00:13.58 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:29.51 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 00:29.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 00:38.01 | snadge | pong ;) |
| 00:38.24 | snadge | error.. unexpected icmp echo reply |
| 00:43.57 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.58) |
| 00:48.14 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.117) |
| 01:03.18 | *** join/#asterisk-dev suneye (~atcmmi@116.25.198.6) |
| 01:08.03 | *** join/#asterisk-dev atcmmi (suneye@116.25.194.200) |
| 01:19.08 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 01:19.08 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:19.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.117) |
| 01:39.45 | *** join/#asterisk-dev Pullphinger (~Pullphing@c-24-13-69-42.hsd1.il.comcast.net) |
| 01:50.04 | *** join/#asterisk-dev suneye (suneye@121.34.41.255) |
| 02:36.19 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 02:36.19 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:21.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.76) |
| 04:37.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.248) |
| 05:18.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.90) |
| 06:53.42 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 07:05.04 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.90) |
| 07:34.40 | *** join/#asterisk-dev kesselklopfer79 (~kesselklo@astaro.starface.de) |
| 07:35.37 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:35.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:41.37 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.90) |
| 08:06.24 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:b4e0:8e37:cffe:d3f8) |
| 08:11.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.90) |
| 09:11.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.90) |
| 10:11.37 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.90) |
| 10:15.24 | *** join/#asterisk-dev barbosa2 (~juliano.b@177-069-248-123.static.ctbctelecom.com.br) |
| 10:42.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.90) |
| 11:23.37 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 11:23.41 | *** join/#asterisk-dev oej (~Adium@189.188.166.41) |
| 11:23.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:35.38 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 11:55.09 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.80) |
| 12:00.11 | file | yawns |
| 12:03.26 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 12:25.09 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 12:51.28 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:11.38 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 13:18.04 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 13:19.54 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-bbnjnwcmaelaqqlt) |
| 13:30.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:434:5101:3e97:eff:fe14:ef66) |
| 13:37.53 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-rphknwicheahikkn) |
| 13:38.49 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-79-141.user.veloxzone.com.br) |
| 13:45.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:45.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:58.34 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 14:19.50 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 14:21.04 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:21.04 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:21.59 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:21.59 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:28.53 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-nchdqxjecwzcteyr) |
| 14:28.53 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:44.16 | danjenkins | leifmadsen: pong |
| 14:44.43 | leifmadsen | danjenkins: I think I was going to ask you about some of your astrics stuff last night, got some time? |
| 14:45.03 | danjenkins | yeah sure |
| 14:45.31 | leifmadsen | danjenkins: I'll msg you |
| 14:46.26 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:46.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:02.36 | snadge | guys.. remember i was asking about adding support for an inserted header for source ip, for load balancing purposes? |
| 15:02.41 | *** join/#asterisk-dev gtjoseph (~gtj@unaffiliated/gtj) |
| 15:03.09 | snadge | it turns out some fancy load balancers, such as netscaler, actually have a use source ip mode.. which makes adding support for the inserted header, far less important |
| 15:03.42 | snadge | there are restrictions to using load balancers in use source ip mode, but they're not significant enough to be overly concerned about |
| 15:04.03 | Marquis42 | That sounds like it makes your life easier at least. |
| 15:04.24 | snadge | there is a concurrency limit of about 64,000 apparently.. due to a quirk in how it works |
| 15:05.29 | snadge | so perhaps going beyond that level.. might make supporting the additional header worth it.. for now, im not going to worry about that :) |
| 15:07.14 | snadge | the source port address is changed to match the ip address of the source.. |
| 15:07.57 | snadge | so that it can keep track of which server to load balance the connection to.. and it times out after 3 minutes.. something like that.. connections from same source ip are reused |
| 15:08.01 | snadge | complicated |
| 15:08.26 | Marquis42 | Yeah, although that time limit shouldn't be of concern if you're using qualify. |
| 15:09.04 | snadge | it should make the boss happy anyway, i think that more than justifies using netscaler |
| 15:09.07 | WIMPy | Sounds like nf_nat_sip |
| 15:09.42 | snadge | linux has lvs .. which is an l7 based load balancer.. and there is ip_conntrack_sip .. i have sort of looked into that.. but, im not sure if it has the use source ip magic |
| 15:09.51 | snadge | thats what nf_nat_sip does? |
| 15:10.08 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 15:10.26 | Marquis42 | snadge: I'll bet you *can* do that with LVS, but it's been a long time since I've really done much with to either say for sure or really help much. |
| 15:10.33 | WIMPy | yes |
| 15:11.07 | WIMPy | And the reason why you should make sure not to have it loaded under any "normal" circumstances. |
| 15:12.17 | snadge | i couldn't find any documentation for that.. is it RNAT? |
| 15:12.57 | snadge | the part i dont understand.. is how netscalers "use source ip" works.. it seems quite tricky.. obviously it changes the source address when it sends the packet out to the server node |
| 15:13.04 | WIMPy | That's what all the nf_nat_* do. |
| 15:13.26 | WIMPy | What is RNAT? |
| 15:13.48 | snadge | reverse nat.. so connection comes in.. router changes the source ip to its own, before forwarding the packet on to the server |
| 15:13.55 | snadge | this is what we dont want.. because it hides the real source ip address |
| 15:14.35 | snadge | and the only way around that, is to insert an additional header which contains the actual source ip address.. and for the server to then process or support that |
| 15:16.19 | WIMPy | nf_nat_* is for normal NAT. |
| 15:16.23 | snadge | with use source ip.. connection comes in.. router internally forwards that to load balanced server, but uses the clients real ip.. server then responds directly to client |
| 15:16.48 | WIMPy | Not sure about your question now. Thought you needed to change the headers because te real IP gets lost. |
| 15:18.14 | snadge | that was the approach I was looking at trying.. until i found that netscaler can load balance to a cluster of servers, and use the client ip address, instead of changing it to its own |
| 15:18.19 | WIMPy | That again sounds like one of the LVS setups. |
| 15:19.19 | WIMPy | .. and like we're in the wrong channel. |
| 15:43.27 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-wmstuaelfrleviso) |
| 15:43.27 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:55.09 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 16:58.58 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:10.18 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 17:10.18 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:12.39 | dwayne | does anyone here have an opinion on which side of a SIP TLS call should initiate the SSL connection teardown ? I'm not sure it matters who initiates it but I'm debugging a scenario where a SSL connection between two Asterisk 1.8.23.1 boxes is left up after the call is complete. After about ~30 min of no call activity, it appears the SSL session is still there on the calling side, so the calling side tries to send an INVITE to |
| 17:12.39 | dwayne | the called side, but the INVITE never gets to the destination |
| 17:14.20 | Qwell | Does a TCP connection stay up, throughout the registration period? |
| 17:14.21 | dwayne | The only work arounds are to unload chan_sip, restart asterisk, wait until a SSL_shutdown() failed: 5 ERROR is displayed so it can create a new connection to the destination |
| 17:14.27 | Qwell | I could be completely wrong |
| 17:14.35 | putnopvut | Qwell: I don't think so |
| 17:14.48 | dwayne | the destination is not registered |
| 17:16.25 | putnopvut | dwayne: Hm, not sure about that. My guess would be that the party that sends the SIP BYE would be responsible for tearing down the connection, presumably once a response to that BYE is received. |
| 17:17.21 | dwayne | putnopvut, ok. I'm going to try to fix this issue and provide a patch, I just wasn't sure if the SSL client or server should specifically be the one to break the connection or if it should be the sender or receiver of the BYE |
| 17:19.08 | dwayne | putnopvut, also, not sure if you can clarify this, but it looks like SIP TLS connections are setup on a caller-called basis regardless of the number of calls using the connection |
| 17:28.18 | putnopvut | what do you mean by caller-called basis? |
| 17:30.18 | dwayne | In the model I'm using, I have a platform that will initiate calls to SIP TLS destinations. It appears that on the first call to a SIP TLS destination, a tcptls session is created to connect to the SIP TLS destination. It also looks like multiple concurrent calls will reuse the existing SSL connection to the SIP TLS destination |
| 17:31.10 | dwayne | but after all the concurrent calls to the SIP TLS destination have completed, the tcptls session to the SIP TLS destination is staying up for a period of time |
| 17:31.57 | putnopvut | Well if the connection is being re-used for each call, then I may be wrong with my initial gues.s |
| 17:31.59 | dwayne | I would have expected that the tcptls session would be closed after the last call to the SIP TLS destination completes |
| 17:32.27 | dwayne | also, I'm assuming that re-using the tcptls sessions was expected, by-design, functionality |
| 17:33.19 | pabelanger | Questions! |
| 17:33.21 | pabelanger | and good ones |
| 17:34.29 | dwayne | so... after the last call is gone, I think the session should be killed but it is staying up. After ~30 min or so, a new call to that SIP TLS destination will hangup because the INVITE never gets to the SIP TLS destination. Some time later, I will see a ERROR: SSL_shutdown failed: 5 ... which tells me that old tcptls session has now been destroyed and a subsequent call to that destination will succeed |
| 17:35.26 | pabelanger | So, imagine 2 asterisk boxes with ARI running. And I had an application that connected to both. I know I can use channel_id to track the channels, but somebody was also mention some other field to combine to it with the system name, but events don't really pass that value right now. |
| 17:36.27 | dwayne | s/will hangup because the INVITE/will hang because the INVITE |
| 17:36.29 | pabelanger | so, I guess you would need to look up /ari/asterisk/info each time to get it? But that might not work because you don't know which ARI to hit when the channel comes in |
| 17:37.12 | pabelanger | guess, I need to keep track on which websocket the event came over, because I would need 2 websockets for each ARI |
| 17:37.44 | pabelanger | maybe something system name or id in the app element |
| 17:39.24 | Qwell | pabelanger: tracking which socket it came over would be the right way |
| 17:39.39 | Qwell | systemname is useful, because the places where it's used, doesn't have access to such information |
| 17:41.32 | pabelanger | Ya, was thinking about SystemInfo class too |
| 17:41.42 | pabelanger | it has entity_id |
| 17:41.51 | pabelanger | which looks like a MAC or something |
| 17:42.11 | pabelanger | but adding some additional info into the event might be an option too |
| 17:42.21 | pabelanger | tracking the socket is what I'll do for now |
| 17:43.41 | pabelanger | Woah |
| 17:43.53 | pabelanger | <PROTECTED> |
| 17:43.54 | pabelanger | nice |
| 17:47.56 | mjordan | pabelanger: channel IDs automatically have the system name prepended if you have systemname specified in asterisk.conf |
| 17:48.21 | pabelanger | Hmm |
| 17:48.23 | pabelanger | let me try that |
| 17:49.46 | pabelanger | "id": "my_system_name-1382550561.0", |
| 17:49.53 | pabelanger | okay it is there |
| 17:50.13 | pabelanger | but, not sure I like the idea of having to parse it out from the channel ID |
| 17:50.47 | mjordan | it'd be pretty trivial to add a new field that emits it on every event. |
| 17:50.54 | pabelanger | let me play around with it and see what I can do |
| 17:50.58 | pabelanger | cool |
| 18:31.30 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 18:39.03 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-tqlyrulupxfbnpmf) |
| 18:43.43 | *** join/#asterisk-dev oej (~Adium@189.188.166.41) |
| 18:43.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:04.59 | dwayne | re: my previous SIP TLS comments, after the 'last' call to a SIP TLS destination completes, the SSL connection to the SIP TLS destination appears to stay up because the AO2 refcount is 2: one being the threadt container and the other being the _sip_tcp_helper_thread which is blocked in ast_poll(timeout: -1) |
| 19:15.54 | dwayne | OK, I think I have a fix for my scenario; just not sure if its the right fix the asterisk source tree |
| 19:18.03 | dwayne | I'm just changing the timeout to 10 seconds and if ast_poll returns 0 and if ((refcount = ao2_ref(tcptls_session, 0)) ==2) make the TLS Server timeout |
| 19:19.09 | dwayne | I guess at this point I'll open a jira issue and submit the patch unless someone here definitely thinks that's a bad fix for some reason |
| 19:21.59 | dwayne | Maybe a higher timeout period ? |
| 19:46.22 | putnopvut | In general, if you're having to check refcounts in order to know how to proceed, things are being done in a suboptimal way. |
| 19:46.56 | dwayne | putnopvut, yeah, that's a good point |
| 19:48.23 | dwayne | I haven't yet seen a way to link a SIP dialog to the tcptls session. If there is one, then maybe that is the place to trigger ast_poll() to return and have the TLS helper thread function die? |
| 19:48.43 | putnopvut | My problem is that I don't have a good enough understanding of what correct behavior is supposed to be in order to give good advice on how to fix :) |
| 19:49.47 | dwayne | Do you think it makes any sense to provide this patch with the issue description to give people on optional fix until the proper fix is found? |
| 19:51.03 | dwayne | at least I now have an understanding of what is causing my problem. That's hopefully half way to the proper solution. :-) |
| 19:51.43 | putnopvut | dwayne: yeah, no problem with that at all. |
| 19:52.26 | dwayne | OK. I'll do that and send a dev-asterisk mailing list email to try to solicit feedback on the proper fix |
| 19:52.59 | dwayne | putnopvut, thanks |
| 20:11.19 | dwayne | Jira issue created: https://issues.asterisk.org/jira/browse/ASTERISK-22750 with temporary work-around patches for 1.8.23.1 and trunk |
| 20:19.26 | *** join/#asterisk-dev skirmisha (~vk@46.47.82.189) |
| 20:19.43 | skirmisha | hi guys |
| 20:20.13 | skirmisha | i have some phones that use port 0 for rtp to direct something which cause asterisk to throw an error |
| 20:21.13 | skirmisha | sip_xmit of 0x859d350 (len 542) to xxx.xxx.xxx.xxx:0 returned -1: Invalid argument |
| 20:21.46 | skirmisha | chan_sip.c:3391 __sip_xmit: SIP_NAT_FORCE_RPORT=262144, SIP_NAT_RPORT_PRESENT=0 |
| 20:21.57 | skirmisha | ver is 1.8.8.1 |
| 20:22.43 | mjordan | skirmisha: that doesn't look like RTP. That looks like SIP signaling. |
| 20:23.09 | skirmisha | yes i thought so, but was wondering why |
| 20:23.19 | mjordan | why what? |
| 20:23.33 | putnopvut | Well, it may be some bug in chan_sip that is causing the port to be 0 instead of the correct port. |
| 20:23.37 | skirmisha | why is giving and error and how can i fix it |
| 20:23.40 | mjordan | ah |
| 20:24.01 | skirmisha | no, i see it in firewall port 0 is used there as well |
| 20:24.09 | skirmisha | probably i have to add it in chan_sip |
| 20:24.12 | mjordan | so something is telling it to send to port 0? |
| 20:24.17 | *** join/#asterisk-dev dronacid (~dronacid@osbk-4db16b00.pool.mediaWays.net) |
| 20:24.17 | skirmisha | any ideas how |
| 20:25.04 | mjordan | I'm confused. Something has sent a request to Asterisk and informed it that where it should send its replies is back to some address at port 0. Correct? |
| 20:26.01 | skirmisha | yes |
| 20:26.12 | skirmisha | its aastra phone i think |
| 20:26.40 | mjordan | k. Port 0 isn't a valid port. What do you want Asterisk to do? |
| 20:27.21 | skirmisha | just to accept it or ignore it without an error |
| 20:27.29 | skirmisha | in ver 1.4 this does not exist |
| 20:27.42 | skirmisha | chan_sip.c:3390 __sip_xmit: p->recv=xxxxxx:0 | p->sa=xxxxxxx:0 |
| 20:28.36 | mjordan | Back up a second: if the phone said "contact me at port 0", what is Asterisk supposed to do? It can't send replies there. There is not a real address. |
| 20:28.38 | skirmisha | its tiptel phone |
| 20:28.45 | putnopvut | skirmisha: Just so we can be 100% clear on this, can you pastebin a sip debug of what happens? |
| 20:29.25 | putnopvut | I want to see the INVITE/REGISTER/whatever that the phone is sending to Asterisk that in turn causes the error. |
| 20:31.05 | skirmisha | <--- SIP read from UDP:3.3.3.3:0 ---> |
| 20:31.05 | skirmisha | REGISTER sip:1.1.1.1 SIP/2.0 |
| 20:31.05 | skirmisha | Via: SIP/2.0/UDP 192.168.168.14:5062;branch=z9hG4bK1185400322 |
| 20:31.17 | skirmisha | ips are changed |
| 20:31.53 | skirmisha | rest is normal register request |
| 20:31.55 | putnopvut | wtf. In 1.4, does it say 3.3.3.3:0 there, too? |
| 20:32.14 | skirmisha | in 1.4 it just does not throw that error |
| 20:36.18 | mjordan | I'm with putnopvut. I'm not sure how something is sending something to us from an IP address at port 0. |
| 20:36.33 | putnopvut | 1.4 is likely either 1) assuming that port 0 really means to use the default 5060, or 2) does not have the forcerport behavior on by default and results in sending the resopnse to 5062. |
| 20:38.13 | putnopvut | mjordan: right, I find it likely that there is some bug present that is making Asterisk think the port is 0 but it really isn't. That's why I wanted to know what the SIP debug looked like on 1.4. If 1.4 still shows as port 0, it's a long-standing issue that 1.4 works around somehow. It's also possible 1.4 will show the source port as something other than 0. |
| 20:38.48 | putnopvut | Other option is to try a version newer than 1.8.8.1 (which is like ~2 years old) and see if the same thing happens in a more recent version of 1.8. |
| 20:39.06 | putnopvut | And yes, I used both "like" and "~" to describe the age of the version. |
| 20:39.28 | file | putnopvut, ~~~ |
| 20:40.50 | skirmisha | i see |
| 20:40.58 | skirmisha | i have to check what 1.4 shows |
| 20:49.46 | pabelanger | ~collectdebug |
| 20:49.46 | infobot | somebody said collectdebug was a method of collecting logs allowing others help troubleshoot an issue. Refer to https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information |
| 20:49.49 | pabelanger | skirmisha, ^ |
| 20:51.06 | skirmisha | yes |
| 20:51.14 | skirmisha | i have to test with another version |
| 21:03.45 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:14.03 | skirmisha | guys |
| 21:14.18 | skirmisha | with 1.4 it shows same port 0 |
| 21:14.23 | skirmisha | but error is missing |
| 21:16.23 | pabelanger | skirmisha, show us |
| 21:16.29 | pabelanger | pb a debug log |
| 21:19.28 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-qcazphuocjqcvsvq) |
| 21:20.26 | skirmisha | its exactly the same as above, i think that xmit does not exist in 1.4 ver therefore i don't get that error |
| 21:21.22 | putnopvut | The __sip_xmit function has been in Asterisk a loooong time. What port does Asterisk send the response to on version 1.4? |
| 21:21.47 | pabelanger | skirmisha, You are missing the point, we are asking you for more information. So, please do so. PB a debug log so people can see what is going vs you just guessing |
| 21:22.34 | mjordan | pabelanger: I'm not sure a pb is going to tell us much else in this case. He pasted in the message from Asterisk showing where it read the request from |
| 21:23.07 | putnopvut | I have a working theory, and it's one that I stated earlier: I think the default nat = force_rport is causing 1.8 to fail in this particular case. If the "working" 1.4 version sends to port 5062, then I'll consider my theory correct. |
| 21:23.11 | skirmisha | strange, i do not see asterisk to reply |
| 21:23.26 | putnopvut | Well, that's weird. |
| 21:24.32 | putnopvut | I'm heading out for a bit. I'll be back later. |
| 21:32.21 | skirmisha | nope, 1.4 is not answering and peer is not added at all |
| 21:35.42 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 21:50.14 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:50.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:07.13 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-wmstuaelfrleviso) |
| 22:38.46 | putnopvut | I have returned. |
| 23:02.02 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:17.11 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 23:45.40 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-98-224-144-181.hsd1.mi.comcast.net) |