| 00:03.01 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 00:12.43 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 00:17.06 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:17.06 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 13.0.0 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 00:21.17 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-jrylasbugpnimfwc) |
| 00:33.35 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 00:33.59 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:25.47 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 03:53.00 | *** join/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 03:53.17 | *** part/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 03:57.36 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 04:16.19 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 04:22.25 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 06:06.06 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 06:18.18 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 06:28.01 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 06:35.29 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 06:41.30 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:41.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:47.32 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 07:34.36 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:56.01 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:56.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:20.50 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:f077:83b1:1400:512d) |
| 08:37.36 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:37.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:37.44 | oej | Good morning folks! |
| 08:59.31 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:f077:83b1:1400:512d) |
| 12:01.31 | *** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-ssharjiytdwotbuy) |
| 12:09.09 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 12:09.09 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:21.03 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 12:21.03 | *** join/#asterisk-dev X-Rob (sid14615@gateway/web/irccloud.com/x-dbhayxujxsexsbhm) |
| 12:21.03 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 12:21.03 | *** mode/#asterisk-dev [+o file] by orwell.freenode.net |
| 13:01.54 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:20.20 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-fzhswjlgfhwjzfon) |
| 13:24.53 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 13:24.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:39.53 | oej | Afternoon folks |
| 13:40.26 | skrusty | lo |
| 14:01.03 | oej | Skrusty! Hello there! |
| 14:11.43 | *** join/#asterisk-dev angler (angler@pdpc/sponsor/digium/angler) |
| 14:38.05 | skrusty | oej: sorry! i totally forgot about today, had our twnety week scan this morning, so been a bit all over the place |
| 14:38.09 | skrusty | (having a boy! :D) |
| 14:39.05 | Marquis42 | skrusty: Congrats! Is this your first, or? |
| 14:39.43 | skrusty | my second, lisa's 3rd (my step daughter is 12!), my youngest, Arthur is 21 months :) |
| 14:39.59 | skrusty | so a bit of an age gap between the first two :) |
| 14:41.22 | Marquis42 | Hah, sounds like me! I've got a step daughter who's 13 and then three boys, two at almost 7 (birthday on the 20th) and one at 3 1/2. |
| 14:41.38 | Marquis42 | So not quite as big of a gap, but a sizeable one nevertheless. |
| 14:43.00 | skrusty | hehe :) |
| 14:43.08 | skrusty | 11 years and 1 day between ella and arthur :) |
| 14:43.49 | Marquis42 | On the bright side you have a live-in babysitter when she gets a little older. :) |
| 14:46.00 | skrusty | yeah, although at the moment Ella's a pain! |
| 14:46.27 | Marquis42 | I won't promise you it gets better, that'd be a lie. ;) |
| 14:46.37 | skrusty | noooooooooooooo! :D |
| 14:46.51 | Marquis42 | :D |
| 14:47.28 | Marquis42 | I suppose we've been sufficiently off-topic for long enough, but congrats again and good luck with the eldest... |
| 14:48.54 | file | it's Friday, Friday is off-topic day |
| 14:50.11 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:50.11 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:52.39 | skrusty | haha :) |
| 14:52.46 | Marquis42 | :) |
| 14:53.13 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-xikzjrnoglxnxlyn) |
| 14:53.36 | skrusty | so, ari reconnect ... i'm thinking it's a non-issue! you can get all the data you need by querying applications |
| 14:53.39 | skrusty | :) |
| 14:53.42 | skrusty | there, back on topic |
| 14:55.25 | Marquis42 | Nice |
| 14:55.31 | Marquis42 | I don't disagree. |
| 14:55.57 | file | skrusty, I disagree in the sense that it's a non-issue - there should at least be some information about how to handle such situation and what state the system will be in when you reconnect |
| 14:56.23 | skrusty | ok, maybe i worded it wrong then, but the proposed fix isn't required, from what i can see |
| 14:57.00 | skrusty | as far as i can tell from my testing, the informaiton i think would be needed, is already available |
| 15:04.56 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gierjtceourjriba) |
| 15:09.15 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-uomxjsdebabdmnem) |
| 15:09.15 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:11.46 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-iapxjmwgqplnqrxe) |
| 15:16.23 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-yqcefhmwjjckytvh) |
| 15:16.23 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:38.45 | mjordan | there's a strange part of me that wants to hit that "Call me!" button and see what happens |
| 15:40.21 | file | eyes mjordan |
| 15:43.07 | mjordan | -dev list |
| 15:43.34 | file | ah |
| 15:44.29 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-zmyssrdkbwhnknte) |
| 16:04.41 | WIMPy | Looks like IP addresses leak in some very strange way. I only discovered it yesterday. |
| 16:05.38 | WIMPy | The day before yesterday my hosted Asterisk had no internet connectivity. The strange thing is that it tried to register one of the sipgate accounts to my home Asterisk. |
| 16:06.50 | WIMPy | And it becomes even more strange as I not only don't use SIP between the two boxes, but IAX and DUNDi run over VPN and it looks like it has used the pubic IP which should not appera anywhere at all. |
| 16:09.10 | WIMPy | Is the address reported in a peerstatus event the real address or the one supplied by the peer in the payload? |
| 16:13.21 | WIMPy | Yes. The secure log confirms that public addresses were used. |
| 16:14.09 | WIMPy | So it tried to register a sip account to an address that is not configured anywhere in any part of Asterisk. |
| 16:19.21 | WIMPy | So far the only place the used IP could have appeared would be in the contents of a DUNDi request/response. |
| 16:21.26 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:50.21 | oej | mjordan: I wonder what those buttons track⦠Hint, hint |
| 17:11.52 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 17:11.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:22.55 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 18:02.13 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 18:05.56 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 18:15.18 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:15.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:15.51 | ipengineer | Does anyone know what part of asterisk handles a user blind transferring a call to an invalid extension and then allowing the call to continue? The question is muddy so let me give an example: I call into asterisk, a device rings I pickup, I then proceed to blind transfer to extension 1234. However, there is no exten=>1234 in the context so the call just continues.. This is great and works as expected. Now if I try th |
| 18:15.51 | ipengineer | again but this time I have a broad pattern match in the context that matches everything and sends it to AGI, AGI picks up the call determines that is an invalid extension and simply closes the socket, it does not issue an ANSWER, HANGUP or anything, simply closes. Asterisk hangs up both channels. What mechanism tells asterisk in the early test to continue on with the call verus using AGI. I am starting to think it hap |
| 18:15.52 | ipengineer | when it is looking for a pattern or a match in the context. If no match is found then the call progresses.. I thought that with AGI closing the socket returned the channel to the dialplan, it seems to do that everywhere else we have it implemented |
| 18:18.15 | *** part/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:32.44 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 18:34.17 | *** join/#asterisk-dev Jacoby6000 (~jbarber@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:30.29 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:30.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:43.51 | mjordan | ipengineer: In the first, it happens in the PBX core. Things call a function to say "does this extension" exist, and the PBX core comes back with a "yes" or "no". |
| 19:44.28 | mjordan | ipengineer: Assuming you are using 13, that is all handled in a single framework (bridging framework). In previous versions, how a blind transfer would occur would be sprinkled throughout the channel drivers/features code/elsewhere. |
| 19:45.49 | mjordan | ipengineer: in AGI, you're kind of in a different "location". From your description, it's hard to say what is occurring. You have an inbound channel in AGI, and they have dialed another party and are in a bridge. Who initiates the blind transfer? Is it a DTMF features based transfer, or a channel driver initiated blind transfer? |
| 19:49.51 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 19:56.13 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:56.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:57.52 | rmudgett | Either way the transfer code asks the dialplan: Does this number match an exten? If so then proceed with the blind transfer. |
| 19:58.38 | rmudgett | If not then the transfer fails |
| 20:02.40 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 20:05.29 | ipengineer | mjordan: Sorry I ran to lunch.. It is a channel driver initiated transfer I believe.. âxferâ button on the phone. So what happens now is once the call is bridged fastAGI disconnects and the call goes on. If they hit xfer, dial an extension number and hit send it re-enters AGI because of the broad pattern match in the context. |
| 20:08.31 | ipengineer | âthe PBX core comes back with a "yes" or "noâ.â <- this is what we were beginning to think after several hours of monkeying around.. We will have to change our approach if this is the case and eliminate the broad pattern match in the context and instead explicitly declare valid extensions and then go to AGI⦠So what I am understanding now is that when we do a channel driver initiated transfer asterisk core |
| 20:08.32 | ipengineer | basically looks to see if the extension is valid in the context, if so it executes and is at the point of no return basically. |
| 20:15.05 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 20:26.43 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 20:26.45 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-ivmzupxkbllvjzsa) |
| 20:26.50 | rmudgett | ipengineer: That's how it works. |
| 20:27.45 | ipengineer | Cool. Thanks mjordan rmudgett for verifying! |
| 20:28.33 | rmudgett | Transfers only know what dialplan has for extens. How could it know what your AGI is going to say about a dialed number? |
| 20:30.32 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 20:30.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:30.36 | ipengineer | it cant. I just didnt know if there was someway to hand it back. basically not acknowlege it.. That was obviously the wrong approach/crazy thinking. |
| 20:31.15 | *** join/#asterisk-dev Jacoby6000 (~jbarber@static-71-252-134-63.dllstx.fios.verizon.net) |
| 20:35.38 | mjordan | I wouldn't say "crazy" :-) |
| 20:39.40 | *** join/#asterisk-dev dustinm (~dustinm@192.241.142.243) |
| 20:54.17 | ipengineer | mjordan: Working to get off this realtime⦠That was another poor approach! Wrote this fastAGI server in scala.. Built a stress tester that plays back all of the asterisk events and was pushing 1700 connections setup in less than a second⦠then simulated calls at that level for over an hour. Minimal load⦠We are trying to get these last few edge issues worked out but are really close. Looking forward to sharing w |
| 20:54.18 | ipengineer | we did on this end. To date we have about 98% of the functionality moved over. The sticking point on this end seems to be the lack of Asterisk domain knowledge.. But we are surely learning! What we are really curious of on this end is how many concurrent socket connections asterisk will support. |
| 20:57.57 | ipengineer | http://postimg.org/image/46jo9i59h/ |
| 21:08.17 | skrusty | nice |
| 21:18.22 | *** join/#asterisk-dev snuff-home (~brad@203-219-29-182.tpgi.com.au) |
| 21:18.22 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 21:22.34 | mjordan | ipengineer: that sounds awesome |
| 21:22.43 | mjordan | ipengineer: I think it'd be great if you could disclose some aspect of what you have done |
| 21:27.54 | coreyfarrell | mjordan: I tried looking at the ref checks bamboo job, for some reason it doesn't have any artifacts or logs. not sure when it happened |
| 21:28.49 | mjordan | Hm. |
| 21:28.53 | mjordan | Bamboo did go down a day or two ago |
| 21:29.03 | mjordan | java sucked up the memory |
| 21:29.15 | coreyfarrell | i'm not sure when it started, I haven't been on bamboo in a while |
| 21:29.17 | ipengineer | I think we owe that at a minimum for the support we have gotten from here. Once we get everything flushed out we will see what we can put together. |
| 21:29.46 | coreyfarrell | none of the history I looked at has the artifacts |
| 21:32.37 | mjordan | artifacts get purged out after a bit due to their size |
| 21:33.59 | coreyfarrell | so anyways sorry to bug you about this.. I don't have access to look into it anymore (that access broke jira for me) |
| 21:34.37 | mjordan | want to just kick one off tonight? |
| 21:34.51 | mjordan | the artifacts are definitely gone, so about the best we can do is just get a new batch |
| 21:35.21 | coreyfarrell | no need, assuming everything should work this weekend |
| 21:35.38 | mjordan | it should work... I may run the trunk one, just to be sure |
| 21:36.00 | mjordan | can't remember if it runs Friday or Saturday night |
| 21:36.27 | coreyfarrell | I think sunday |
| 21:36.48 | mjordan | yeah, at noon |
| 21:36.53 | coreyfarrell | so if you're going to do a manual run I'd prefer you do 11 |
| 21:37.00 | mjordan | I'll run one tonight. That way if it doesn't work I can fix it this weekend |
| 21:37.03 | mjordan | sure, I can do 11 |
| 21:37.23 | coreyfarrell | thanks |
| 22:47.36 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-uomxjsdebabdmnem) |
| 23:01.57 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 23:59.16 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:59.16 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |