| 03:57.43 | *** join/#asterisk-bugs leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:57.43 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |
| 06:01.17 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 06:52.51 | *** join/#asterisk-bugs Pagautas (n=bigman@ns.voip.ktu.lt) |
| 08:56.15 | Entomologist | *** CLOSED (14989) [Applications/app_queue] [patch] invalid XML syntax in doc of 'Queue' |
| 08:56.15 | Entomologist | Reported by: tzafrir Karma: 120.5 |
| 08:56.16 | Entomologist | http://bugs.digium.com/view.php?id=14989 |
| 08:56.16 | Entomologist | ********************************************************* |
| 08:58.41 | Entomologist | *** CLOSED (14990) [Resources/res_indications] [patch] Missing error message if indications.conf is not found |
| 08:58.41 | Entomologist | Reported by: tzafrir Karma: 120.5 |
| 08:58.41 | Entomologist | http://bugs.digium.com/view.php?id=14990 |
| 08:58.41 | Entomologist | ********************************************************* |
| 09:23.28 | Pagautas | i've tried almost all versions from 1.4.17 to 1.6.2-beta1 |
| 09:23.28 | Pagautas | and 1.4.17 is the latest version |
| 09:23.29 | Pagautas | where mixmonitor doesnt stops on call transfer using phone transfer button |
| 09:23.32 | Pagautas | call comes to queue |
| 09:23.34 | Pagautas | monitor insted of mixmonitor doesnt work at all |
| 09:24.12 | Pagautas | ask if you need aditional info |
| 09:41.31 | Pagautas | also something wrong with playing audiofiles from dialplan from version 1.6.1 and above |
| 09:41.41 | Pagautas | i'm using default install |
| 09:41.57 | Pagautas | added simple iax user |
| 09:42.42 | Pagautas | user dials 1000, * answers but there is a huge lag of sound file played |
| 09:43.03 | Pagautas | there is no such problem with sip |
| 12:12.41 | *** join/#asterisk-bugs eliel (n=eliels@200.61.172.61) |
| 12:33.17 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:05.07 | *** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim) |
| 13:24.06 | *** join/#asterisk-bugs guaxinim (n=guaxinim@unaffiliated/guaxinim) |
| 13:35.28 | *** join/#asterisk-bugs bbryant (n=brett@68.208.65.50) |
| 13:36.39 | *** join/#asterisk-bugs bbryant (n=brett@68.208.65.50) |
| 13:36.39 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 13:37.21 | Entomologist | *** CLOSED (14085) [Applications/app_cdr] Userfield not updating when the call is answered, if not answered it updates properly |
| 13:37.21 | Entomologist | Assigned to: mnicholson |
| 13:37.21 | Entomologist | Reported by: unservices Karma: 0 |
| 13:37.21 | Entomologist | http://bugs.digium.com/view.php?id=14085 |
| 13:37.21 | Entomologist | ********************************************************* |
| 13:49.31 | *** join/#asterisk-bugs putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:49.31 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 13:51.07 | *** join/#asterisk-bugs leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:51.07 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |
| 14:42.45 | *** join/#asterisk-bugs JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 14:42.45 | *** mode/#asterisk-bugs [+o JunK-Y] by ChanServ |
| 15:41.29 | *** join/#asterisk-bugs bbryant (n=brett@68.208.65.50) |
| 15:41.29 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 16:26.09 | *** join/#asterisk-bugs bbryant_ (n=bbryant@m425a36d0.tmodns.net) |
| 16:27.07 | *** join/#asterisk-bugs flujan (n=flujan@189.111.254.251) |
| 16:27.09 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 17:02.27 | *** join/#asterisk-bugs bbryant (n=bbryant@m425a36d0.tmodns.net) |
| 17:02.27 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 17:47.11 | *** join/#asterisk-bugs d1mas (n=chatzill@host-99.dataart.net) |
| 17:48.34 | Entomologist | *** CLOSED (13930) [dahdi_dummy] dahdi_dummy does not tick on some systems |
| 17:48.34 | Entomologist | Assigned to: sruffell |
| 17:48.34 | Entomologist | Reported by: tzafrir Karma: 120.5 |
| 17:48.34 | Entomologist | http://bugs.digium.com/view.php?id=13930 |
| 17:48.34 | Entomologist | ********************************************************* |
| 17:48.35 | Entomologist | *** CLOSED (14884) [dahdi_dummy] loading dahdi_dummy crashes CentOS-xen kernel |
| 17:48.37 | Entomologist | Reported by: ask Karma: 0 |
| 17:48.39 | Entomologist | http://bugs.digium.com/view.php?id=14884 |
| 17:48.41 | Entomologist | ********************************************************* |
| 17:48.43 | Entomologist | *** CLOSED (14963) [dahdi_transcode] [patch] wctc4xxp fails building with kernel 2.6.30-rc3: implicit declaration of function ânetif_rx_completeâ |
| 17:48.46 | Entomologist | Assigned to: sruffell |
| 17:48.48 | Entomologist | Reported by: tzafrir Karma: 120.5 |
| 17:48.50 | Entomologist | http://bugs.digium.com/view.php?id=14963 |
| 17:48.52 | Entomologist | ********************************************************* |
| 18:02.19 | d1mas | hello. I have a question regarding switches in Asterisk. It seems that when DUNDi switch executes, it just runs Dial command and there is no way to patch options or do something like that, I'm thinking about switch first checking for the existense of special context/extension and if found - doing Gosub there instead of Dial. |
| 18:02.38 | d1mas | if the extension is not found - old way (plain dial) is used. |
| 18:03.12 | d1mas | The question is: does it sound like the right approach or the same problem musst be approached in a different way? |
| 18:07.35 | jsmith | d1mas: If you want to add options, etc... then use the DUNDILOOKUP function instead |
| 18:08.01 | Entomologist | *** CLOSED (14689) [Core/General] Asterisk Crashes when typing 'remove extension' and using the tab key in CLI |
| 18:08.01 | Entomologist | Assigned to: dbrooks |
| 18:08.01 | Entomologist | Reported by: isaacgal Karma: 0 |
| 18:08.01 | Entomologist | http://bugs.digium.com/view.php?id=14689 |
| 18:08.01 | Entomologist | ********************************************************* |
| 18:08.42 | d1mas | jsmith: I know about this approach. Unfortunately it is very difficult to use it |
| 18:08.58 | jsmith | Why? |
| 18:09.18 | d1mas | jsmith: I will explain :) it gonna be long... one min... |
| 18:10.20 | leifmadsen | I wish I didn't have to go offline right now because I'm curious... |
| 18:11.25 | d1mas | jsmith: Imagine my dialplan consists of contexts A, B, C and D. These are internal users, internal services, outbound e164 etc. I can build different contexts for different users allowing them to access sets of numbers (like A+B+C, or just A, or D+A etc). |
| 18:12.18 | jsmith | OK, I'm with you so far |
| 18:13.04 | d1mas | jsmith: now imagine all these ABCD use DUNDi lookups. Now asterisk lets me quickly understand if given dial-number is allowed for particulat user to do. If the context of user includes A,B and D - Asterisk will do three DUNDi lokups and tell me if number dialed matches anything or not. |
| 18:13.28 | jsmith | I'm with you so far |
| 18:14.21 | d1mas | jsmith: Now if I try converting this to DUNDILOOKUP finction, My dialplan can not be set of context and inclusions anymore - it has to be plain program into which I should jump by _X. and doing all these lookups one by one. |
| 18:14.41 | d1mas | There are two major drawbacks: |
| 18:15.09 | jsmith | I don't see why? |
| 18:15.15 | d1mas | 1. i have to process any number (_X.) because I can not rely on Asterisk doing lookup and checking existence anymore |
| 18:16.13 | jsmith | Presumably your A, B, C have *some* extensions in them already, right? |
| 18:16.23 | jsmith | Let's assume you have something that looked like: |
| 18:16.34 | jsmith | [internal-users] |
| 18:16.39 | d1mas | 2. As dialplan becomes application which loookups "remote contextx" one by one, it becomes significantly less transparent to provide different users with different set of services |
| 18:17.09 | jsmith | exten => 6001,1,Macro(my-macro,SIP/george) |
| 18:17.32 | jsmith | exten => 6002,1,Macro(my-macro,SIP/alice) |
| 18:17.47 | jsmith | and maybe you have |
| 18:17.52 | jsmith | [local] |
| 18:18.16 | jsmith | exten => _NXXXXXX,1,Dial(SIP/provider/${EXTEN}) |
| 18:18.35 | jsmith | Now, if I understand you correctly, you would have had a DUNDi switch in each of those contexts before, correct? |
| 18:19.23 | d1mas | lets say I have all you listed above on the server1. And now I want server2 to be able to lookup/dial these |
| 18:20.30 | d1mas | so on server2 in some test-contest I have either to use DUNDi switch (which will do all the lookups) |
| 18:20.43 | d1mas | or add _X. exten which does DUNDILOOKUP function |
| 18:25.30 | d1mas | you see what I mean? |
| 18:27.28 | jsmith | I see what you mean, but I have another alternative |
| 18:28.26 | jsmith | Instead of putting a DUNDi switch in each of your a,b,c contexts, put a single dundi switch in its own context, and include in your includes (A+B+C+dundi) |
| 18:28.53 | jsmith | Then, you could replace that one DUNDI switch with _X. exten which does the DUNDILOOKUP function |
| 18:28.59 | d1mas | jsmith: this way I will loose different user roles |
| 18:29.16 | d1mas | jsmith: u1 can access extensions in A while user B can not |
| 18:29.23 | jsmith | Let me ask this... is each of the DUNDI switch statements looking up on a different dundi network? |
| 18:29.41 | d1mas | jsmith: no, the same servers but different contexts |
| 18:30.22 | jsmith | d1mas: I'm still not sure I understand... are you looking up 6001@usera vs. 6001@userb? |
| 18:31.18 | d1mas | ok, lets name things properly. contexts are 'users', 'services' and 'e164' |
| 18:31.43 | d1mas | depending on the user who dials, I can lookup 'users' only, 'users'+'services' or all three |
| 18:31.58 | jsmith | OK... with you so far, and I'm assuming that you're using includes for various classes of users, right? |
| 18:32.02 | jsmith | Something like: |
| 18:32.06 | jsmith | [employees] |
| 18:32.14 | jsmith | include => users |
| 18:32.18 | jsmith | include => services |
| 18:32.22 | d1mas | yes |
| 18:32.22 | jsmith | [managers] |
| 18:32.26 | jsmith | include => users |
| 18:32.30 | jsmith | include => services |
| 18:32.31 | d1mas | exactly |
| 18:32.33 | jsmith | include => e164 |
| 18:33.12 | d1mas | all the servers in my "lookup group" are my own servers - one per office |
| 18:33.13 | jsmith | OK... now, in your current setup, does each of the "super" contexts (such as managers or employees) contain the dundi switches, or does users, services, and e164? |
| 18:33.46 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 18:34.19 | d1mas | in my current setup, individual context (users, services) contain dundi switches and the "super" contexts only include these users and services |
| 18:34.33 | jsmith | OK. |
| 18:34.51 | d1mas | so yes, it can run up to 3 dundi lookups to finally find the route |
| 18:34.59 | jsmith | Actually, it wouldn't. |
| 18:35.03 | d1mas | (i lnow it is not efficient) |
| 18:35.16 | d1mas | well, it will :)) |
| 18:35.19 | jsmith | If it found a match in say the users context (via dundi), it wouldn't bother to continue looking it services |
| 18:35.33 | jsmith | *unless* you're looking up the number in different dundi networks |
| 18:35.38 | d1mas | yes, I said UP TO three, not exxactly three :) |
| 18:36.04 | jsmith | It would only do it three times if there were *no* match in DUNDI |
| 18:36.13 | d1mas | so if it does not find user - it continues with services (another lookup) and then e164 |
| 18:36.19 | jsmith | So it would either do it once, or three times |
| 18:36.36 | jsmith | Here's how I suggest you change it. |
| 18:36.42 | d1mas | no. each of switches looks up in different context |
| 18:36.51 | d1mas | [users] |
| 18:37.01 | d1mas | switches => DINDi/users |
| 18:37.04 | jsmith | Oh... those aren't really contexts.... those are dundi networks |
| 18:37.07 | d1mas | [services] |
| 18:37.22 | d1mas | switches => DUNDi/services |
| 18:37.31 | jsmith | Right... I'm following you now |
| 18:37.38 | d1mas | hm.... terminology issue :) |
| 18:37.53 | *** join/#asterisk-bugs |Cybex| (n=John@80.100.126.176) |
| 18:38.05 | jsmith | OK, now that we're both on the same page, I suggest you take out those dundi switches, and do the following: |
| 18:38.13 | *** join/#asterisk-bugs DennisD2 (n=DennisD2@d149-67-216-2.clv.wideopenwest.com) |
| 18:38.15 | jsmith | [employees] |
| 18:38.23 | jsmith | include => users |
| 18:38.28 | jsmith | include => services |
| 18:38.35 | jsmith | include => dundi |
| 18:38.40 | jsmith | [dundi] |
| 18:39.22 | Corydon76-dig | jsmith: makes no difference. Switches always are evaluated after includes |
| 18:39.37 | jsmith | Corydon76-dig: No they aren't. |
| 18:39.43 | jsmith | Corydon76-dig: They're evaluated *before* includes |
| 18:39.54 | d1mas | includes are after switches according to code |
| 18:40.07 | Corydon76-dig | Really? |
| 18:40.11 | d1mas | yes |
| 18:40.18 | jsmith | Corydon76-dig: (or if that's changed, I've been teaching the whole world incorrectly for years) |
| 18:40.22 | d1mas | pbx.c I believe |
| 18:40.24 | jsmith | Corydon76-dig: Really |
| 18:40.44 | jsmith | Matching order is: exact matches, pattern matches, switches, and then includes |
| 18:40.44 | Corydon76-dig | Oh, you're right |
| 18:41.06 | d1mas | anyway, what does it change? |
| 18:41.38 | Corydon76-dig | d1mas: it forces users and services to get evaluated first |
| 18:42.09 | d1mas | corydon, you alway have control over it - just rearrqange includes etc |
| 18:42.21 | jsmith | d1mas: If you then create a [dundi] context with _X. as a pattern match, it then only does the DUNDI lookup(s) after all the local possibilities have been tried |
| 18:42.32 | d1mas | yes but... |
| 18:42.48 | jsmith | d1mas: *And* then you have one location which to add your extra flags |
| 18:43.09 | d1mas | I will have to do two lookups manually |
| 18:43.16 | d1mas | and for managers - three |
| 18:43.46 | d1mas | and if I ave more user "roles" - even more |
| 18:44.11 | DennisD2 | I hate to rudely interrupt (sorry), but can someone reopen bug 14412? I can reproduce it (I just did with 1.6.1.0). I'll put all the info I have on the bug. |
| 18:45.46 | jsmith | DennisD2: Done |
| 18:45.46 | *** join/#asterisk-bugs bbryant (n=bbryant@m425a36d0.tmodns.net) |
| 18:45.46 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 18:45.49 | d1mas | jsmith: and this may lead to tons of copy&paste in the dialplan, you know :) If you want to avoid that, you will have to write universal dundi lookup code which does proper lookups based on user rile (that is context in which we are |
| 18:46.27 | DennisD2 | Thanks! |
| 18:46.53 | jsmith | bbryant: Would you mind revisiting commit r132514 -- it seemed to include some 1.6.1-branch specific changes to the sample features.conf file that aren't available in the 1.6.0 branch |
| 18:47.00 | jsmith | bbryant: (specifically regarding multiple parking lots) |
| 18:47.23 | d1mas | And there is another thing: I want to pass variables to the remote server with the call. 1.4 does not have a way to do it. 1.6 offers IAXVAR function but anyway - it has to be set before outbound dial to remote node |
| 18:48.10 | jsmith | d1mas: I guess what it comes down to is that because using DUNDILOOKUP isn't the most efficient for your dialplan, you think it's broken. |
| 18:48.36 | d1mas | I'm not saying DUNDILOOKUP is broken in any way! |
| 18:48.48 | bbryant | jsmith, it's been a while... let me look it up |
| 18:49.17 | jsmith | d1mas: No, you're saying the DUNDI switch is broken! :-) |
| 18:49.20 | jsmith | bbryant: Thanks! |
| 18:49.20 | d1mas | I'm only saying dialplan have to be rewritten completely and organized more like a plain program than like a asterisk dialplan with nested contexts |
| 18:49.32 | d1mas | jsmith: neither I do that |
| 18:49.37 | jsmith | d1mas: And I'm saying you can still nest them... |
| 18:50.06 | d1mas | my idea was to give user easy way to hook into dial executed by DUNDi switch |
| 18:50.07 | jsmith | d1mas: It may not be the most *elegant* solution, or use the fewest number of lines |
| 18:50.43 | jsmith | d1mas: Feel free to write a patch, and I'd be happy to take a look at it (as would the other developers, I'm sure)... I was only providing a workaround that didn't require code changes |
| 18:51.01 | jsmith | d1mas: I'm not saying it wouldn't be useful... only trying to show there's another way to do it today |
| 18:51.09 | d1mas | so if user creates special context (like std-switch-dial) and provides s extension there, the switch will GoSub there instead of running Dial explicitly |
| 18:52.46 | d1mas | jsmith: I CAN do it in other way. But it means complete rewrite of the dialplan and God, if I'll do that I better do everything as huge AGI script beacuse doing things like this is too painful even with AEL :) |
| 18:53.52 | d1mas | so I started with the question: does such a patch for switches make any sense or it is useful for me only? because if I'm the only person in the world who needs it, I better go The Big Rewrite way :) |
| 18:53.54 | Corydon76-dig | If your script is huge, you're doing it wrong |
| 18:54.25 | Corydon76-dig | Take advantage of databases |
| 18:54.27 | d1mas | corydon: you are not serious I hope |
| 18:54.45 | jsmith | d1mas: Oh, he's serious |
| 18:55.06 | jsmith | d1mas: And I'm serious about doing it with DUNDILOOKUP... if it's more than 15 lines of additional code, I'll lick my shoe |
| 18:55.21 | d1mas | asterisk coddebase is huge. Aren't you guys doing something wrong? :) |
| 18:56.38 | d1mas | I can not use databases for thatt - the idea is that system should live even if one of offices disconnect from others. |
| 18:56.38 | bbryant | jsmith, do you mean the line about setting the parkinglot variable in the channel configuration? |
| 18:57.01 | d1mas | so there should be no central database |
| 18:57.27 | bbryant | 132514 was a revision to trunk |
| 18:57.49 | d1mas | jsmith: with single lookup context it is definitely within 15 lines of code. With different user roles... wwell.. I hope your shoe is clean :) |
| 18:59.03 | jsmith | bbryant: Sorry, r132515 |
| 19:05.01 | bbryant | jsmith, so you're saying that the code the documentation refers to was in 1.6.1 but later got taken out of the 1.6 branch? |
| 19:06.16 | jsmith | bbryant: No... I'm saying that the code for multiple parking lots was not in the 1.6.0 branch, only in 1.6.1 branch and later. |
| 19:06.48 | bbryant | ok, i misunderstood |
| 19:06.49 | jsmith | bbryant: When you made that commit, however, you copied the config file changes pertaining to multiple parking lots back to the 1.6.0 branch config files |
| 19:07.11 | jsmith | bbryant: So the sample configs in 1.6.0 make it look like that feature exists, but it doesn't until 1.6.1 |
| 19:07.39 | bbryant | right, that makes sense |
| 19:16.28 | d1mas | jsmith: btw, i forgot one reason why _X. is not good - Background+ReadExten will be waiting even after last digit of very unique extension because _.X. can match to any longer one. |
| 19:17.28 | jsmith | d1mas: Only if you have the [dundi] context included |
| 19:19.30 | d1mas | how can I doo DUNDi lookups without including it?... the goal is to let users registered on one server dial users registered on another, services published by it etc... |
| 19:45.06 | *** join/#asterisk-bugs tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 19:45.59 | jsmith | Any developers care to look at bug 14996? (multiple parking lots don't work) |
| 21:08.33 | jpeeler | jsmith: did you include the other parking lot context? |
| 21:09.29 | jsmith | jpeeler: Aye! |
| 21:09.50 | jsmith | jpeeler: See my sample config :-) |
| 21:10.19 | jpeeler | attached the issue? |
| 21:10.50 | jsmith | In the "steps to reproduce" section |
| 21:11.03 | jsmith | See the line that says "include => edvinapark" |
| 21:11.07 | jpeeler | i never remember to check the advanced view |
| 21:11.20 | jsmith | Notice that I *didn't* include the "parkedcalls" context |
| 21:12.09 | jpeeler | i'm not totally sure you can do that, but ok |
| 21:13.00 | jpeeler | so what does your features.conf look like? |
| 21:13.45 | Entomologist | *** CLOSED (14770) [Channels/chan_sip/TCP-TLS] Need ability to select TLS version in outgoing messages |
| 21:13.45 | Entomologist | Assigned to: dvossel |
| 21:13.45 | Entomologist | Reported by: TheOldSaint Karma: 0 |
| 21:13.45 | Entomologist | http://bugs.digium.com/view.php?id=14770 |
| 21:13.45 | Entomologist | ********************************************************* |
| 21:13.46 | Entomologist | *** CLOSED (14768) [Channels/chan_sip/TCP-TLS] TLS Client Hello handshake sent within SSLv2 header and not TLS header |
| 21:13.49 | Entomologist | Assigned to: dvossel |
| 21:13.51 | Entomologist | Reported by: TheOldSaint Karma: 0 |
| 21:13.53 | Entomologist | http://bugs.digium.com/view.php?id=14768 |
| 21:13.55 | Entomologist | ********************************************************* |
| 21:17.38 | jsmith | jpeeler: Just attached it to the bug |
| 21:18.57 | jpeeler | wait |
| 21:19.34 | jpeeler | set the parking lot variable to parkinglot_edvina |
| 21:27.36 | jpeeler | jsmith: did that work for you? |
| 21:29.01 | jsmith | jpeeler: I'll try that. |
| 21:29.41 | jpeeler | might want to test with the other parkinglot context too... maybe |
| 21:47.59 | *** join/#asterisk-bugs leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:47.59 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |
| 22:05.49 | jsmith-away | jpeeler: OK, that worked when I used the parking lot name, and not the parking lot context name |
| 22:06.01 | jsmith-away | jpeeler: Feel free to close the ticket! |
| 22:09.50 | jpeeler | i see you got it for me, thanks |
| 22:10.16 | jsmith-away | Yeah... didn't know I could do that. |
| 22:30.19 | jsmith-away | feels like such a newb sometimes |
| 22:30.27 | jsmith-away | And with that, I'm calling it a day |
| 22:43.33 | *** join/#asterisk-bugs bbryant (n=bbryant@m4a5a36d0.tmodns.net) |
| 22:43.33 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 22:57.03 | *** join/#asterisk-bugs leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:57.03 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |