| 00:34.40 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:9999:c971:6a89:f097) |
| 00:52.27 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 01:33.21 | *** join/#asterisk-dev spditner (~simon@206-248-134-215.dsl.teksavvy.com) |
| 01:42.30 | *** join/#asterisk-dev spditner (~simon@206-248-134-215.dsl.teksavvy.com) |
| 02:15.13 | *** join/#asterisk-dev leifmadsen (~free-mads@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:15.13 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 03:45.08 | jameswf | newtonr: https://wiki.asterisk.org/wiki/display/AST/System+Libraries |
| 05:37.14 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 05:58.00 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip24-251-34-116.ph.ph.cox.net) |
| 06:31.29 | *** join/#asterisk-dev spditner (~simon@206-248-134-248.dsl.teksavvy.com) |
| 06:48.47 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:48.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:19.29 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:8503:2689:64a0:5571) |
| 07:45.41 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 07:45.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:06.54 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 08:13.40 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:13.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:15.22 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 09:15.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:53.01 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 11:53.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:05.28 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 12:15.48 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 12:15.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:23.24 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:28.00 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:28.15 | *** part/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:28.16 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:34.58 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 12:34.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:17.06 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 13:17.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:23.03 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-jzfxykjevdzviqlv) |
| 13:23.03 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:57.42 | Marquis42 | Possibly n00b question about a02 objects: Is the object's lock held when its destructor is called? |
| 14:01.30 | file | no |
| 14:03.15 | mjordan | once you're in the destructor, the ao2 object is on its way out the door. No one should be holding a reference to it or using it any longer |
| 14:04.34 | Marquis42 | OK, cool, thanks. |
| 14:04.35 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 14:04.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:04.43 | file | if they are... then you've broken the world |
| 14:04.58 | Marquis42 | lol |
| 14:05.11 | Marquis42 | Just trying to ferret out a probable lock inversion with chan_sip. |
| 14:05.14 | Marquis42 | There be dragons. |
| 14:12.43 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-nrxwhfeicqviyrav) |
| 14:15.18 | leifmadsen | mjordan: ohai! |
| 14:15.37 | leifmadsen | mjordan: any chance today you can help denub me and help figure out why jira hates me? |
| 14:15.53 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-xdtlxqfpylwwqptp) |
| 14:15.53 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:16.47 | jameswf | Jira likes no one... it simply tolerates some of us |
| 14:16.54 | leifmadsen | indeed |
| 14:18.16 | mjordan | leifmadsen: e-mail me whatever e-mail you want to use. I think the e-mail associated with your account is invalid |
| 14:18.35 | leifmadsen | mjordan: it's right, because I get the email to reset (it was in a folder filtering out jiras) |
| 14:18.42 | leifmadsen | however, when I reset, I still can't login |
| 14:18.55 | leifmadsen | I tried a couple times |
| 14:38.32 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:38.43 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:39.30 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-vfzrbkhavuwangjh) |
| 14:44.29 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 14:44.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:15.00 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:15.00 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:56.55 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 16:03.59 | pabelanger | Does stasis fire an event when MOH is added to a bridge? |
| 16:11.58 | pabelanger | doesn't look like it |
| 16:12.51 | pabelanger | How did we determine which HTTP requests generate events and which don't? |
| 16:21.22 | jameswf | pabelanger: lottery |
| 16:26.23 | pabelanger | ... |
| 16:27.20 | pabelanger | I guess what I am asking, is this a bug or a specific reason not to raise the event |
| 16:35.14 | leifmadsen | mjordan: yea I think there might be something wrong with the backend authentication |
| 16:35.23 | leifmadsen | I just reset it again, simple password, took, try to login and it fails |
| 16:39.17 | file | there is no mapping of HTTP requests to events because the HTTP request doesn't generate the events, what may occur does - one could be made but it would be a "you may or may not receive this" sorta thing... as for MOH added to a bridge I don't think so |
| 16:39.48 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 16:41.41 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 16:42.03 | pabelanger | file, Ya, so I think the missing events are just because they are missed, not intentional. |
| 16:42.27 | pabelanger | So, on that note, going to file bugs and see if I can raise them in the code. |
| 16:44.10 | pabelanger | Another issue is I don't see BridgeCreated event when I create my bridge |
| 16:44.17 | pabelanger | checking jira to see if that is an issue |
| 16:45.46 | file | I vaguely remember that somewhere... problem being you don't specify an application when creating a bridge, so it wouldn't know who to send it to |
| 16:46.01 | file | and you get the bridge back when creating it, so it doesn't really add value |
| 16:46.27 | pabelanger | Hmm |
| 16:46.32 | pabelanger | okay, that gets me started |
| 16:54.43 | tzafrir | datachomper, one minor thing about your patch: do we want to maintain the compatibility between indication.conf data and tonezone data? |
| 16:54.54 | tzafrir | (The '@' symbol) |
| 16:58.25 | datachomper | Hmm |
| 16:59.52 | datachomper | I think indication.conf may need the same sort of fix for AU. I dialed into the congestion() function and got the wrong tone, i'm guessing that is where it is controlled |
| 17:03.55 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip24-251-34-116.ph.ph.cox.net) |
| 17:13.37 | mjordan | leifmadsen: sorry, was out. I think I know what's up - give me just a sec |
| 17:13.45 | leifmadsen | mjordan: sure thx |
| 17:15.06 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:16.03 | mjordan | leifmadsen: try now |
| 17:16.38 | leifmadsen | mjordan: still fails |
| 17:16.40 | mjordan | pabelanger: file is correct. ARI (through the Stasis dialplan application) works on a subscription based model. For channels in a Stasis application, it creates a subscription for that channel |
| 17:16.49 | mjordan | leifmadsen: hm.... maybe it hasn't hit crowd yet. Give it about 5 min |
| 17:16.53 | leifmadsen | mjordan: will do |
| 17:17.00 | leifmadsen | I figured it was a crowd/auth backend sync issue :) |
| 17:17.12 | mjordan | pabelanger: when that channel enters a bridge, you get bridge related stuffs because something you have a subscription to has entered that bridge |
| 17:17.25 | mjordan | pabelanger: but in general, you need to subscribe to things in order to get notifications about them |
| 17:17.42 | mjordan | pabelanger: if you create a subscription to a bridge, then you'll always get all information about that bridge (until you unsubscribe, anyway) |
| 17:18.44 | mjordan | leifmadsen: are you using leifmadsen or lmadsen are your user? |
| 17:18.46 | mjordan | er, as your |
| 17:18.52 | leifmadsen | lmadsen |
| 17:18.57 | leifmadsen | that's the one I reset anyways |
| 17:19.08 | leifmadsen | apparently I have two users... ? |
| 17:19.25 | mjordan | yup! |
| 17:19.36 | mjordan | ah |
| 17:19.36 | leifmadsen | ic :) |
| 17:19.47 | mjordan | hm. |
| 17:19.55 | leifmadsen | I can try resetting the leifmadsen user as well |
| 17:20.02 | mjordan | I reset your leifmadsen one, but I'll try and see what is going on with lmadsen. It looks .... different. |
| 17:20.08 | leifmadsen | email should just be <first_name>@<full_name>.com |
| 17:20.23 | leifmadsen | maybe lmadsen was an old account, or something digiumesque |
| 17:20.34 | leifmadsen | it's been seriously far too long since I've logged into jira... |
| 17:21.40 | mjordan | both look okay now... |
| 17:22.03 | mjordan | if this doesn't work, I'll get more drastic |
| 17:24.39 | leifmadsen | mjordan: ok, not sure what is up with the lmadsen user, still can't get in there, but tried leifmadsen and figured out a password that worked :) |
| 17:25.07 | leifmadsen | I think lmadsen is my "real" user though |
| 17:25.14 | leifmadsen | because this leifmadsen one has no actual issues assigned to me |
| 17:25.27 | leifmadsen | maybe this leifmadsen was created in the "great backend upgrade of 2012"? |
| 17:27.38 | mjordan | potentially |
| 17:27.41 | mjordan | looks |
| 17:28.54 | mjordan | I removed you from one group that may be ... odd. We'll see if that changes any other thing. From the admin perspective, your user should be fine - so if this didn't fix it, we'd either have to delete the user or start digging into the DB |
| 17:29.39 | pabelanger | mjordan, you setup the subscription for events when the WS client connects to ARI right? |
| 17:29.53 | pabelanger | unless I am missing something, I have that, but BridgeCreated is not raised |
| 17:30.14 | pabelanger | but, things have changed in the last 7 months, so I'm looking at my code to make sure I am doing it correct still |
| 17:30.47 | mjordan | pabelanger: no |
| 17:31.05 | mjordan | pabelanger: you don't subscribe to events, you subscribe to resources |
| 17:31.12 | sgriepentrog | You have to subscribe to the bridge to get the bridge event. |
| 17:31.21 | mjordan | pabelanger: there is no "subscribe to all things in Asterisk" |
| 17:31.41 | mjordan | Since BridgeCreated happens before any subscription could ever be made, it is sort of a phantom event |
| 17:31.44 | mjordan | TRIVIA! |
| 17:31.52 | mjordan | what other event is impossible to currently get? :-D |
| 17:32.04 | Qwell | mjordan: FullyBooted |
| 17:32.08 | mjordan | Qwell: touche |
| 17:32.12 | Qwell | :D |
| 17:32.16 | file | mjordan, technically any named event which does not exist |
| 17:32.23 | file | example: the Toast event |
| 17:32.36 | Qwell | ToAst* |
| 17:32.51 | mjordan | file: The set of events which may exist but do not currently exist is not a valid set :-P |
| 17:33.03 | file | mjordan, you were not that specific |
| 17:33.06 | jameswf | monitor state.. |
| 17:33.16 | mjordan | file: I'm having a real problem with my requirements definition these days |
| 17:33.56 | mjordan | (ChannelCreated) |
| 17:34.05 | mjordan | hides |
| 17:35.31 | pabelanger | okay, so this concept of subscribe to resource is new to me, since I last used ARI. Is there any documentation on how to do this? |
| 17:36.19 | sgriepentrog | https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Applications+REST+API#Asterisk12ApplicationsRESTAPI-subscribe |
| 17:37.33 | pabelanger | sgriepentrog, thanks |
| 17:38.33 | pabelanger | how does one find out what events you have to subscribe too and which you don't? For example, ChannelStateChange appears on WS by default |
| 17:39.27 | mjordan | "pabelanger: file is correct. ARI (through the Stasis dialplan application) works on a subscription based model. For channels in a Stasis application, it creates a subscription for that channel" |
| 17:39.58 | mjordan | When a channel enters into the Stasis dialplan application, the WebSocket connection for that application gets an implicit subscription for that channel |
| 17:40.06 | sgriepentrog | You get the ChannelStateChange on the websocket for the stasis application because/when the channel is actively in that application. |
| 17:40.19 | sgriepentrog | What he said.. |
| 17:40.43 | mjordan | keep in mind that you can subscribe to things outside your 'application' |
| 17:40.55 | mjordan | you can subscribe to channels not in your app, as well as bridges |
| 17:41.09 | mjordan | and bridges can technically be shared between apps |
| 17:41.42 | mjordan | the only thing that is explicitly tied to an app is a channel - and obviously only while it is in there. You're only subscribed to the channel while it is in your app |
| 17:42.00 | pabelanger | okay, I think I understand |
| 17:51.13 | pabelanger | mjordan, when you say phantom event for BridgeCreated there is no way to obtain it? |
| 17:51.58 | mjordan | how would you get a creation event when you have to subscribe to get it? |
| 17:52.24 | pabelanger | Right, so why does it exist? |
| 17:52.57 | sgriepentrog | Unless there was a generic object creation topic that could be subscribed for... that would probably only useful for testing though. |
| 17:53.04 | pabelanger | So, my question is, aide from waiting for a return result from the HTTP POST for /bridge, how do you know the bridge is actually created? |
| 17:53.20 | mjordan | the return result is the canonical way of knowing |
| 17:53.21 | pabelanger | aside* |
| 17:53.23 | file | if you get a result it was created |
| 17:53.31 | mjordan | And! For two reasons |
| 17:53.43 | pabelanger | which, ATM, is not async in my app (something on my side that needs updated) |
| 17:54.15 | mjordan | (1) The events were based on the Stasis messages. When we first created the subset of events that could be possibly returned, we picked the ones that made the most sense. As it turns out, the subscription based nature of the Stasis dialplan application meant that some didn't actually get emited. |
| 17:54.42 | mjordan | (2) ARI and - to some extent, the events - are not the Stasis dialplan application. The Stasis dialplan application is one way (and currently the only way) to control resources in Asterisk |
| 17:54.57 | mjordan | There may (and probably will) be other ways in the future. In which case, those events are going to be super useful. |
| 17:56.45 | jameswf | resource wise which is "cheaper" REST or manager |
| 17:56.51 | mjordan | depends |
| 17:57.07 | mjordan | event wise, they are the same |
| 17:57.27 | mjordan | from the perspective of controlling resources... it depends. ARI is much more flexible. |
| 17:57.49 | mjordan | It ends up being a bit of apples and oranges there, since AMI is so tied to the dialplan applications |
| 17:58.10 | mjordan | about the only thing that really maps cleanly is creating channels, in which case, they're basically the same. |
| 17:58.32 | mjordan | they both call the same function under the hood. AMI might be just a tad faster just because it isn't sneaking through quite so many layers. |
| 17:58.47 | mjordan | but it's highly unlikely to be the limiting factor. |
| 17:59.04 | file | from a user perspective ARI is certainly easier for origination >_> |
| 17:59.21 | file | (if you want to fire and forget) |
| 17:59.29 | pabelanger | <mjordan> pabelanger: there is no "subscribe to all things in Asterisk" <- So, why is that? Not the model of ARI? |
| 17:59.43 | mjordan | It's not the model of the Stasis dialplan application |
| 17:59.44 | mjordan | ARI != Stasis |
| 17:59.47 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:00.02 | mjordan | ARI is a way to control things in the Stasis dialplan application |
| 18:00.09 | mjordan | And, theoretically, other things as well |
| 18:00.12 | pabelanger | and stasis events would never fire over AMI |
| 18:00.51 | mjordan | uhm... |
| 18:00.54 | mjordan | how do you mean? |
| 18:01.05 | mjordan | if you change the state of a channel, that is reflected over everything |
| 18:01.17 | pabelanger | well, creating a bridge in the case |
| 18:01.27 | mjordan | sure you get the events over AMI. |
| 18:01.36 | mjordan | AMI has a 'global show me anything and everything' policy |
| 18:01.45 | pabelanger | ok |
| 18:01.50 | mjordan | there is no such thing as a subscription in AMI |
| 18:01.59 | pabelanger | right |
| 18:02.04 | mjordan | which is great for when you want to know the state of the world, but bad when the state of the world overwhelms you |
| 18:05.10 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 18:07.40 | pabelanger | okay, so just to recap. Events like ChannelEnteredBridge and StasisStart I don't need subscriptions for, because when ever a channel enters stasis, they are auto subscribed. But things like bridges, would have to be manually subscribe to after creating them, having the potential to miss events between the subscription request, right? |
| 18:08.30 | file | the bridge is yours, if you don't manipulate it... it shouldn't change |
| 18:09.03 | pabelanger | Right, so, basically after creation, I shouldn't do anything to it until the subscription is setup |
| 18:09.13 | pabelanger | then, I'll get events as I manipulate it |
| 18:09.47 | sgriepentrog | Yup |
| 18:10.04 | pabelanger | okay, thank you for the info. Helpful |
| 18:10.21 | sgriepentrog | Create, then subscribe - unless you don't need the events and are just controlling/using it. |
| 18:10.51 | pabelanger | or setup a connection to AMI to get all the events |
| 18:11.33 | sgriepentrog | If you needed to, or already had the ami connection going, yes. |
| 18:11.44 | file | key phrase being "needed to" |
| 18:12.28 | sgriepentrog | Right. Getting a copy of everything happening on the system is not fun, unless that's what you needed to do for some reason. |
| 18:12.30 | pabelanger | Right, asterisk being a toolkit, there is many ways to accomplish something. Some ways might be creative. |
| 18:13.10 | sgriepentrog | The nice thing about ARI is it by default tells you just what you need to do your application, but still gives you the flexibility of asking for more info where needed. |
| 18:37.02 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 18:46.03 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:46.03 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:48.09 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:48.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:47.56 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 19:58.13 | tm1000 | are there any bugs with parking in 12? I am trying to pickup a parked call from slot 71 and it keeps telling me there is now call parked. But if I run “parking show default” it works |
| 19:58.26 | tm1000 | s/works/shows |
| 19:59.49 | file | any bugs with would be in the issue tracker :P |
| 20:00.14 | file | if you see nothing open related then not anything we are aware of |
| 20:00.27 | file | console output and such would be useful |
| 20:03.07 | tm1000 | file: yeah I am just trying to figure out if its me or asterisk |
| 20:03.13 | tm1000 | usually its me, so im going with me |
| 20:03.29 | file | notes nobody ever adds "or both" |
| 20:06.14 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 20:08.58 | tm1000 | file: http://pastebin.com/08uf2ipx |
| 20:09.09 | tm1000 | so the call is sitting in 71 |
| 20:09.27 | tm1000 | when I call/dial 71 I get “Could not find the requested parking lot” |
| 20:09.34 | tm1000 | which is weird because the lot is ‘default’ |
| 20:10.09 | file | swap the arguments to ParkedCall |
| 20:10.56 | file | yes random person outside, make tons of noises with your idle motorcycle |
| 20:11.08 | file | gah dang it |
| 20:11.55 | *** join/#asterisk-dev jrose_atDigium (~jrose@nat/digium/x-latmmllmqjsthiyq) |
| 20:12.13 | file | jrose_atDigium, why did you change the argument order to ParkedCall? |
| 20:12.24 | jrose_atDigium | What do you mean? |
| 20:12.28 | tm1000 | file: man when did that change! |
| 20:12.32 | jrose_atDigium | Oh |
| 20:12.33 | tm1000 | it worked in 12.0.0 |
| 20:12.35 | jrose_atDigium | the application |
| 20:13.01 | tm1000 | jrose_atDigium: yeah just give me a version number if you can |
| 20:13.07 | tm1000 | over here in freepbx land I have to version it out |
| 20:13.14 | tm1000 | but you definately changed it mid stream :-D |
| 20:13.22 | jrose_atDigium | It's been what it's been since the first release of 12 |
| 20:13.34 | tm1000 | jrose_atDigium: I disagree with that statement |
| 20:13.43 | jrose_atDigium | Well, I can take a look. |
| 20:14.13 | tm1000 | jrose_atDigium: I will say, it makes waaaaay more sense this way though :-) |
| 20:14.47 | jrose_atDigium | And that was why I changed it... because the old way made no sense and enough other stuff about parking was changing to kind of justify it at the time. |
| 20:15.22 | tm1000 | jrose_atDigium: yeah. I *might* have been on trunk so if you changed it during the beta to release then there you go |
| 20:15.27 | jrose_atDigium | But I'm pretty sure the argument order is what it's been since res_parking was initially introduced. |
| 20:15.46 | tm1000 | jat one point it worked ….. I though |
| 20:15.56 | tm1000 | jrose_atDigium: anyways if you think so I will just mark it at 12 and be done with it |
| 20:16.31 | jrose_atDigium | mark it? |
| 20:16.40 | file | jrose_atDigium, mark it in their generator code |
| 20:16.43 | tm1000 | jrose_atDigium: internally mark it |
| 20:16.48 | tm1000 | jrose_atDigium: sorry :-) |
| 20:16.58 | jrose_atDigium | No problem |
| 20:17.01 | file | so that when it produces the dialplan for 12 it puts it in the correct order and thus parking works |
| 20:17.05 | tm1000 | if (a >= 12) *do 12 stuffs* |
| 20:17.13 | file | and then cake! |
| 20:17.20 | tm1000 | file: exactly |
| 20:17.32 | tm1000 | file: thanks for spotting that, my fault for somehow looking at 1.8 documentation |
| 20:19.48 | file | tm1000, and confirmed for 12.0.0 |
| 20:20.07 | tm1000 | file: well that means I wrote the dialplan and never fully checked it. ouch to me |
| 20:20.46 | file | you should get cake |
| 20:21.45 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 20:21.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:22.30 | file | or rather, you still get cake |
| 20:41.56 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:41.56 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:43.50 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 20:43.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 22:56.12 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-nrxwhfeicqviyrav) |
| 23:24.47 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:33.51 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:33.51 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:38.19 | tm1000 | file: you still working? |
| 23:42.13 | file | sure! |
| 23:46.04 | tm1000 | file: Im having this strange issue, still with parking in 12, when I do attended transfer (*2<parkinglot> here) then it tells me the slot, but then it bridges me into a MOH? then when I hangup the parked caller gets two MOH mixed together (so its loud) then immediately after its back to normal. Meanwhile asterisk is saying something about swaping calls |
| 23:46.12 | tm1000 | is getting you a pastebin |
| 23:46.30 | file | ah I don't know the parking stuff that well |
| 23:47.59 | file | and am currently half asleep - if the pastebin will last the night I will grab jrose tomorrow |
| 23:48.13 | tm1000 | I’ll just hit you both up tomorrow :-) |
| 23:48.14 | tm1000 | thats ok |