| 00:08.11 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:08.11 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:27.15 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 00:27.15 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:34.25 | snuff-work | mm.. i'm surprised still how much we have to manage for sip with an external library.. |
| 00:34.44 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 01:17.10 | pabelanger | Oh ast_queue_log why don't you support UTC timezones |
| 01:20.37 | pabelanger | wait, I might be wrong |
| 01:22.05 | pabelanger | rage |
| 01:22.06 | pabelanger | nope |
| 01:22.52 | pabelanger | why not just use the epoch like /var/log/asterisk/queue_log does |
| 01:30.43 | snuff-work | because it was overlooked? |
| 01:32.56 | file | snuff-work, what do you mean? |
| 01:34.05 | snuff-work | so the library pjsip will handle much by itself? or is it literally just parsing sip msgs + state machine? |
| 01:34.15 | pabelanger | heh, time to write a patch. Now to figure out where to put the queue_log setting |
| 01:34.48 | file | snuff-work, there's different higher level stuff that's built upon the lower level so it will handle some stuff... like INVITE sessions, presence, authentication |
| 01:35.08 | pabelanger | logger.conf |
| 01:35.16 | file | but they are all APIs for use - you still need to write stuff to use and make them useful |
| 01:36.44 | snuff-work | mm will admit i didn't look super hard at it all.. reviewed some examples on their site etc |
| 01:37.11 | file | you can use it at any level you want in the end |
| 01:42.20 | file | runs off to bed |
| 01:42.30 | snuff-work | later |
| 01:42.46 | file | snuff-work, if you come up with any questions/concerns/whatever don't hesitate to shout |
| 01:43.30 | snuff-work | if there is something a crap coder can help u with let me know :) |
| 01:43.38 | snuff-work | np file |
| 02:16.45 | *** join/#asterisk-dev sustav (~vpp@76.73.166.16) |
| 02:30.43 | pabelanger | Who is generating SSL certs for origsvn these days? |
| 02:42.17 | mjordan | Qwell |
| 02:42.22 | mjordan | did yours expire? |
| 03:00.42 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 03:00.42 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 03:16.26 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 03:16.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:35.39 | *** join/#asterisk-dev sustav (~vpp@76.73.166.16) |
| 05:04.44 | snuff-work | wedhorn: i think i found another variable |
| 05:39.36 | snuff-work | 7960 has slightly diff set of strings for the 14 in the 'unknown1-4 fields' |
| 06:11.19 | wedhorn | snuff-work: just got home |
| 06:11.28 | wedhorn | having a look at the pcap you sent |
| 06:17.51 | snuff-work | got another 1 from 7961 again |
| 06:18.38 | snuff-work | http://pastebin.com/vrs7Bb3q |
| 06:18.51 | snuff-work | those should be values for 4 unknowns for inbound call |
| 06:19.32 | wedhorn | just found some data in what I guessed was a space |
| 06:19.46 | wedhorn | packet 74 of your pcap has data there |
| 06:19.47 | snuff-work | yes.. that seems to signify 'unknown' |
| 06:20.15 | wedhorn | well i guess it becomes unknown5 at the moment |
| 06:20.22 | snuff-work | :) |
| 06:20.38 | snuff-work | still shame that missed calls etc still waay broken |
| 06:20.39 | wedhorn | yep, i noticed the same pattern (which is completely different to what I had |
| 06:21.05 | snuff-work | i'd say that pattern u initially had.. is for fwd'd calls |
| 06:21.40 | wedhorn | yep, but it was the second packet in the xfer series (first had direction of 3, second had direction of 1) |
| 06:21.47 | snuff-work | atm tryin to work out why i'm getting wrong caller name being displayed.. the pcap looks correct |
| 06:22.23 | wedhorn | add an extra \0 and it corrects the name, but then the pcaps don't line up .... |
| 06:23.33 | wedhorn | are you sending the 145 message as well, or just 14A |
| 06:23.49 | snuff-work | just the 14a atm |
| 06:23.59 | snuff-work | for my * |
| 06:24.19 | wedhorn | okay |
| 06:24.34 | wedhorn | Im guessing the 145/144 messages have to do something |
| 06:28.40 | wedhorn | interesting, if you look at the pcap you sent, messages 144 and 145 have 0x8038 where the number normally shows up when 14A has anonymous as the from callerid |
| 06:29.09 | wedhorn | one of those could signal the device to disable buttons |
| 06:29.52 | wedhorn | my bets are on 145 as its the only one with a callreference |
| 06:41.18 | snuff-work | mm.. lookin over 145/144 with anon call vs normal.. |
| 06:42.36 | snuff-work | 145 + 145.. have 80 17 39 30 / 80 17 80 38 |
| 06:43.27 | wedhorn | we were using the 8017 as a spacer |
| 06:43.37 | wedhorn | 3930 is ascii isn't it |
| 06:43.45 | snuff-work | yep |
| 06:43.53 | snuff-work | but the anon call.. has '80' |
| 06:44.11 | wedhorn | so the first has a number, the second seems to have some sort of control |
| 06:44.17 | snuff-work | nfi where the 8 come from |
| 06:44.52 | wedhorn | i think its 0x8038 rather than ascii 8 |
| 06:45.01 | snuff-work | mm k |
| 06:45.07 | wedhorn | just a guess |
| 06:45.21 | snuff-work | i will send u my 7961 pcap as well |
| 06:47.40 | snuff-work | dont look much diff from 60's |
| 06:56.48 | snuff-work | see what u mean bout the extra nul.. soo anonying |
| 06:57.12 | snuff-work | but yer my call list is in shambles :) |
| 06:57.26 | snuff-work | somehow every call is from itself.. |
| 06:59.31 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 07:04.06 | wedhorn | yep, now your at the fun I had yesterday |
| 07:05.45 | snuff-work | maybe we missing some other 'setup' msg when phone boots to parse v2 call info |
| 07:05.57 | wedhorn | quite possibly |
| 07:06.13 | wedhorn | or the number in the missed call message is based on 144/145 instead |
| 07:06.30 | wedhorn | or something else completely |
| 07:06.55 | snuff-work | mm.. i will do 1 dump start to finish of phone booting to ccm and taking 2 calls.. |
| 07:07.08 | snuff-work | see if we can spot somethin else |
| 07:12.52 | wedhorn | good luck with that, there's a lot of crap that gets sent around |
| 07:12.52 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:14.21 | snuff-work | will send u a copy.. but i'll probably look over it more tomorrow |
| 07:14.46 | wedhorn | okay, i'll do a bit more mucking around |
| 07:17.23 | wedhorn | snuff-home: guessing you of to catch a train |
| 07:17.39 | wedhorn | snuff-work: even - damn tab completion |
| 07:18.00 | snuff-work | yep pretty much :) |
| 07:18.34 | wedhorn | okay, i've got a patch that sets every field to a different value, some interesting results |
| 07:19.06 | snuff-work | u get diff stuff in the missed/recv call? or the 'unknown' fields ? |
| 07:19.07 | wedhorn | those 4 bytes in the middle aren't spacing, their 4 null terminated strings |
| 07:19.45 | wedhorn | so the first 8 strings are probably numbers, then at least 4 more for names, I used 8 and it didn't complain |
| 07:19.58 | wedhorn | so that's 16 string I sent to the device |
| 07:20.14 | snuff-work | better results? |
| 07:20.35 | wedhorn | on dialing in, it show string0 and string 8 |
| 07:20.47 | wedhorn | in the missed call, it shows string1 and string8 |
| 07:21.08 | wedhorn | however, in details it indicates string0 is the "alternate" whatever that means |
| 07:22.33 | snuff-work | nice.. guess we should have tried more strings to begin with :) |
| 07:22.55 | snuff-work | since callinfo v1 has quite a few |
| 07:23.08 | wedhorn | yep, sort of feel stupid that we were trying to send real data rather than a different string in each field |
| 07:23.09 | snuff-work | almost makes slight sense that v2 should have same number |
| 07:23.44 | snuff-work | k really gotta go.. :P |
| 07:23.48 | wedhorn | k |
| 07:23.54 | snuff-work | 8 min 1/2 run/walk |
| 08:22.11 | jmls | morning |
| 08:22.51 | jmls | got a bare-bones device state subscriber working, but there is some problem with it. Would appreciate someone's eyes on what I've done wrong |
| 08:22.53 | jmls | http://pastebin.com/4Wc7dTF3 |
| 08:23.15 | jmls | what I am trying to do right now is simply print on the console the device state when it changes |
| 08:23.59 | jmls | however, there's some dodgy-looking character at the end of the message which looks like I haven't converted something properly, and then I get some verbose message |
| 08:24.11 | jmls | which shouldn't be there as I have verbose = 0 |
| 08:24.57 | jmls | the dodgy character always seems to be ΓΌ |
| 08:26.13 | jmls | oh. |
| 08:26.15 | jmls | wow. |
| 08:26.25 | jmls | added \n to the end of the message, and all the crap goes away |
| 08:26.30 | jmls | really? |
| 08:28.48 | wdoekes | jmls: it's a verbosity byte |
| 08:29.38 | jmls | interesting. why does a missing \n cause the problem ? |
| 08:30.27 | wdoekes | I believe it's the thing Corydon76-home added a couple of months back: per console setting of verbosity. the message now needs a flag (the first byte) which its verbosity. and if you don't terminate your messages, they get concatenated |
| 08:31.12 | jmls | in that case, shouldn't ast_log terminate the message automatically before sending ? |
| 08:31.41 | jmls | cause it's broken if you don't anyway |
| 08:31.47 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-124-50.red.bezeqint.net) |
| 08:31.48 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:32.48 | wdoekes | depends on the internals. these messages get queued so they can be spread out to different logs. you could call it a bug, unless you mandate that log messages need a terminating LF (which they do) |
| 08:34.16 | jmls | I understand. IMHO (which, truthfully, doesn't count for much!) ast_log should automatically add a \n if it doesn't exist. |
| 08:34.21 | jmls | thanks for the insight. |
| 08:34.46 | jmls | is just pleased that he has gotten device state printing on the console ;) |
| 08:35.07 | wdoekes | (my opinion is that you shouldn't leave things to runtime which you can do at compile or code time.. this isn't the user-interface after all) |
| 08:35.52 | wdoekes | good luck with that :) |
| 08:38.52 | jmls | lol |
| 08:39.05 | jmls | wdoekes is a cli warrior ;) |
| 08:46.28 | jmls | does func_curl require a channel to post data to a web service ? |
| 08:46.46 | jmls | iow can I use func_curl in my resource module to send data ? |
| 08:49.24 | wdoekes | that's be wrong. I don't think you can access stuff in func_curl at all. |
| 08:49.34 | wdoekes | *that'd |
| 08:50.39 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 08:50.44 | WIMPy | linocis |
| 08:52.07 | wdoekes | func* stuff is supposed to depend on res* stuff, not the other way around |
| 08:57.07 | jmls | thought so. |
| 08:57.17 | jmls | goes looking for curl-like stuff in res |
| 09:00.12 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-124-50.red.bezeqint.net) |
| 09:00.13 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:07.19 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:f4a3:b127:e986:c8a7) |
| 09:09.01 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 09:11.45 | *** join/#asterisk-dev alsuren (~dlaban@80.169.133.251) |
| 09:18.26 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-124-50.red.bezeqint.net) |
| 09:18.27 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:21.58 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 09:23.01 | jmls | wdoekes : if you have the patience, I have another question |
| 09:24.49 | jmls | I see that func_curl checks to see if there is a valid channel passed , otherwise it uses a "global" config. If this is the case, does this mean that it can be used from outside the dialplan functions ? |
| 09:26.16 | jmls | I also see that res_config_curl requires func_curl.so to be loaded |
| 09:46.32 | *** join/#asterisk-dev mwally (~mwally@mwally.hbx.us) |
| 09:47.43 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 09:56.23 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 09:56.43 | wdoekes | jmls: eek. that's not pretty (to put it mildly) |
| 09:56.57 | jmls | heh |
| 09:57.06 | wdoekes | .. well .. if res_config gets to do it, you could too |
| 09:57.44 | jmls | was thinking along the same lines ... |
| 10:10.58 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-124-50.red.bezeqint.net) |
| 10:10.59 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:18.26 | jmls | holy cow, it worked !! |
| 10:30.25 | jmls | device states now being posted to jms, where anyone can subscribe . woot! |
| 10:30.32 | jmls | has a big cheesy grin. |
| 10:30.48 | jmls | code needs a *lot* more work (options etc) |
| 10:34.02 | jmls | to make things simple, I was going to propose that the only option is the url (http://localhost/foo) with the state posted as json - {"device":"SIP/155c12ebfb","state":"Not in use"} |
| 12:07.14 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 12:07.14 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:07.58 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 13:12.48 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-tveebcfrleitqllr) |
| 13:12.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:16.37 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-tveebcfrleitqllr) |
| 13:37.19 | opticron | jmls, you could use file's sorcery api! |
| 13:37.39 | file | haha |
| 13:38.32 | jmls | great. I've just run a stress test on my http device state thingy. asterisk : 100% ok. ActiveMQ : 100% cpu |
| 13:55.11 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-nlzvmowosiipwnoy) |
| 13:57.00 | Corydon76-home | jmls: in answer to your earlier question, there's a priority flag in the definition of the module, which orders modules for loading |
| 14:01.58 | *** join/#asterisk-dev sustav (~vpp@nat/digium/x-liupuscooptalecw) |
| 14:04.08 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:04.08 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:26.22 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ijzoenesibgstspn) |
| 14:26.22 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:34.16 | *** join/#asterisk-dev sustav (~vpp@nat/digium/x-tbglxcsaxuvzbxij) |
| 14:37.01 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:37.01 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:38.35 | jmls | ok, I think the problem is in my code. I've broken activemq on three different machines, 3 different versions and 3 different O/S ;) |
| 14:39.15 | jmls | I *know* that the code is , cough, not perfect, and hardcoded in places, but it's a work in progress. Bear with me ... |
| 14:39.16 | jmls | http://pastebin.com/HaRgsLpv |
| 14:48.28 | mjordan | do you get the device state notifications? |
| 14:48.40 | jmls | yup, it all seems to work peachy |
| 14:48.59 | jmls | but after a couple of thousand calls, activemq starts to go titsup |
| 14:49.10 | jmls | asterisk memory seems ok |
| 14:49.36 | mjordan | hm. Alas, my activemq foo is non-existant |
| 14:49.48 | jmls | I've got mq processing over 1m records per day using func_curl from the dialplan, so pretty sure it's not that |
| 14:49.49 | mjordan | kudos on writing a device state consumer though :-D |
| 14:50.04 | jmls | bows |
| 14:50.44 | jmls | I think that perhaps the connection is not dropped / removed / cleared / disconnected or something like that |
| 14:51.06 | jmls | but don't know anything about func_curl so I'm kinda stuck :(* |
| 14:52.38 | mjordan | how are you currently calling the function? |
| 14:53.03 | jmls | ast_str_set(&query, 0, "${CURL(http://localhost:8161/demo/message?persistent=no&type=queue&destination=hash42.devicestate,body={\"device\":\"%s\",\"state\":\"%s\"})}", device, device_state); |
| 14:53.12 | jmls | ast_str_substitute_variables(&buffer, 0, NULL, ast_str_buffer(query)); |
| 14:53.34 | mjordan | hm |
| 14:53.53 | jmls | (see pastebin for full source) |
| 14:53.58 | mjordan | I'd do it a bit differently, personally. |
| 14:54.06 | jmls | is all ears |
| 14:54.12 | mjordan | I'd format the arguments to the CURL function, than call ast_func_read or ast_func_read2 |
| 14:54.21 | mjordan | that way you're guaranteed to go through the same mechanisms that the dialplan uses |
| 14:54.51 | mjordan | you will need to get the channel |
| 14:55.47 | jmls | func_curl checks if a channel is void |
| 14:56.28 | mjordan | yup |
| 14:56.32 | mjordan | and act_func_read doesn't care either |
| 14:56.36 | Corydon76-home | mjordan: Same thing, just a different level |
| 14:56.36 | mjordan | so you should be able to pass NULL to it |
| 14:57.11 | mjordan | Corydon76-home: probably, but I'm a big fan of using APIs when you start to get behavior that you can't explain |
| 14:57.13 | Corydon76-home | ast_str_substitute_variables is exactly what the dialplan does |
| 14:58.09 | jmls | I copied most of the code from res_config_curl |
| 14:58.49 | jmls | perhaps there is something not right in there, but doesn't show because it may not make the same volume of calls that devstate changes would ? |
| 14:59.10 | mjordan | well, scratch my theory then |
| 14:59.32 | jmls | do i need to call a disconnect or close or something like that after I've run the function ? |
| 15:00.16 | jmls | *or* is there a problem with a null channel to func_curl that hasn't been found before, again because of volume ? |
| 15:00.35 | mjordan | no, as Corydon76-home pointed out the variable substitution will call the function in the same fashion. So my idea was wrong |
| 15:00.50 | mjordan | jmls: if that were the case, Asterisk would be seg faulting |
| 15:01.08 | jmls | the dialplan function always uses a channel |
| 15:01.15 | jmls | my call doesn't |
| 15:01.29 | jmls | that's a difference between dialplan and my consumer call |
| 15:01.35 | Corydon76-home | The dialplan function has a channel as an argument, but it doesn't always use it |
| 15:02.07 | Corydon76-home | Remember res_config_curl... |
| 15:03.49 | jmls | yeah |
| 15:03.50 | mjordan | jmls: one thing you could do is configure your module to only make CURL requests for a subset of devices and see what effect that has on activemq. |
| 15:04.18 | jmls | I only have 4 devices on this test system. :) |
| 15:04.23 | mjordan | hm. |
| 15:05.37 | Corydon76-home | Not a clue what the problem is, but an optimization would be to allocate buffers larger than 16 bytes, because it's always going to reallocate in the next step |
| 15:06.10 | jmls | it's definitely mq that's getting "stuck" because if I restart it, everything kicks back in. It's almost as if it's running out of connections |
| 15:06.33 | jmls | like the post sends the data but doesn't disconnect |
| 15:07.03 | jmls | Corydon76-home : what value should I use ? |
| 15:07.29 | Corydon76-home | Uh, of course the post doesn't disconnect. It's the server's responsibility to close the connection when it's through sending a response. |
| 15:08.03 | mjordan | file: so, pjproject supports TLS out of the box. Do you know of any changes we'd need to make for it? Obviously we'd need to tell pjproject that a SIP session wants to use it as its transport (and tie it back to endpoint configuration, yada yada yada), but other than that I don't see anything else that would need to be done |
| 15:08.18 | Corydon76-home | Count the number of bytes used in the set below, including a reasonable amount of space for the substituted strings |
| 15:08.18 | file | there isn't |
| 15:08.23 | mjordan | file: yay |
| 15:08.31 | mjordan | so we have only one transport to write ourselves |
| 15:09.06 | Corydon76-home | jmls: but if the server didn't disconnect, the CURL() function would never return |
| 15:09.21 | jmls | bugger |
| 15:09.27 | jmls | this is a real head scratcher. |
| 15:09.36 | Corydon76-home | jmls: if you're getting the LOG notice at the end, then CURL() is definitely returning |
| 15:09.36 | jmls | never had mq break like this |
| 15:09.48 | jmls | getting the log ok |
| 15:10.02 | Corydon76-home | So it's definitely closing the HTTP connection |
| 15:10.03 | opticron | jmls, can you produce the same behavior by running curl from the command line pointed at mq? |
| 15:10.18 | jmls | doh. hadn't thought of trying that :) |
| 15:10.24 | jmls | will do and report back. |
| 15:32.40 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 15:32.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 15:33.14 | *** join/#asterisk-dev killown (~killown@pdpc/supporter/student/killown) |
| 15:42.24 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-hdqktdejnizolril) |
| 15:43.26 | *** join/#asterisk-dev serafie1 (~erin@76.73.167.231) |
| 15:46.20 | jmls | dammit. seem to be having some really strange behaviour on this box (virtual machine on citrix) |
| 15:47.05 | jmls | going to rebuild everything. what's the favourite os / flavour ? 64-bit seems to have caused me nothing but grief ... |
| 15:47.47 | jmls | centos / scientific / ubuntu (can't seem to get on with this ..) |
| 15:48.00 | coreyf1513 | not sure why 64-bit would be a problem. I can't remember the last 32-bit system i've deployed |
| 15:48.17 | jmls | meh |
| 15:48.32 | jmls | 64 bit it is ;) |
| 15:50.22 | *** join/#asterisk-dev sustav (~vpp@nat/digium/x-xvajvoyywohegcap) |
| 15:50.23 | file | so for those who may be curious... I'm about to start throwing SIP traffic at res_sip, then res_sip_session, and finally chan_gulp |
| 15:50.32 | mjordan | file: ! |
| 15:50.52 | file | I actually already did but the monitor thread isn't registered with pjlib, so it aborts |
| 15:51.10 | killown | please fix this /usr/src/dahdi-linux-2.6/drivers/dahdi/xpp/xdefs.h:152 from dahdi there is no need for typedef int bool; |
| 15:52.00 | coreyf1513 | file: is any code of that new sip driver available (I know it's not ready, just to look) |
| 15:52.04 | jmls | so, is there any device state change events through ami ? Thought that I saw something recently .. |
| 15:52.06 | mjordan | https://issues.asterisk.org/jira/browse/DAHLIN-312 |
| 15:53.09 | mjordan | it's already in the issue tracker. |
| 15:53.15 | file | coreyf1513, it's all in SVN under http://svn.digium.com/svn/asterisk/team/group/pimp_my_sip/ |
| 15:54.11 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:54.11 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:54.17 | coreyf1513 | file: nice label thanks |
| 15:54.23 | file | although we just really started so don't expect the world |
| 15:56.27 | coreyf1513 | file: I know it's not ready, honestly I don't plan on even compiling it yet |
| 15:57.51 | pabelanger | Who is issueing origsvn certs these days? |
| 16:08.41 | *** join/#asterisk-dev alsuren (~dlaban@93.93.133.71) |
| 16:10.56 | jmls | some guys in turkey apparantley ;) |
| 16:22.15 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:22.16 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:26.04 | pabelanger | mjordan, ^ |
| 16:34.53 | jmls | grr. go figure. 18474 messages and counting. no problems. |
| 17:04.55 | jmls | ok. I used sipp to make 3000 calls , with a limit of 20 calls each lasting 10s. The extension sets a device state |
| 17:05.29 | jmls | sipp stopped around 5 minutes ago |
| 17:06.14 | jmls | however, I am still getting device state changes through on Device [SIP/sipp] and Device [Custom:DND_7015] |
| 17:06.40 | jmls | looks like the events are stacking up |
| 17:07.24 | jmls | is there any way of seeing what the number of events waiting to be processed is ? |
| 17:09.46 | pabelanger | Gah, queuerules BUGS! |
| 17:14.50 | pabelanger | So, just ran into https://issues.asterisk.org/jira/browse/ASTERISK-20862 |
| 17:14.57 | pabelanger | which is likely a documentation fix |
| 17:15.08 | pabelanger | leifmadsen, ^ Maybe you can comment |
| 17:15.48 | leifmadsen | huh, you're possibly right |
| 17:16.59 | pabelanger | And can also confirm https://issues.asterisk.org/jira/browse/ASTERISK-19368 |
| 17:39.42 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 17:40.43 | jmls | there may be some sort of problem with either my dialplan or set(DEVICESTATE(custom:foo)=value) |
| 17:41.21 | jmls | if I take out the set() , then there is no problem with mq or curl with 1000 calls |
| 17:41.46 | jmls | I get 5 change of states per call, ending up with 5000 messages being sent |
| 17:42.19 | jmls | when I had the set() in, I had 30000 messages sent for 1000 calls. and it kept going. had to stop asterisk |
| 17:43.08 | jmls | what happens if more than one channel tries to change the same device state ? |
| 17:43.16 | jmls | at the same time |
| 17:49.55 | Corydon76-home | There's no such thing as 'the same time'. Events are serialized. |
| 17:50.10 | Corydon76-home | One will be queued before the other |
| 17:50.27 | Corydon76-home | So the events from the two channels will interleave |
| 17:52.10 | jmls | mm |
| 17:52.45 | jmls | so what could cause the 6x + increase in messages when I have set(devicestate) in the dialplan ? |
| 18:00.23 | jmls | right. got a lead on the problem |
| 18:01.41 | jmls | looks like either AST_EVENT_DEVICE_STATE , func_curl or MQ cannot cope with a large number of changes per second |
| 18:02.21 | jmls | I've got around 5000 messages backed up and waiting to be processed |
| 18:02.24 | leifmadsen | I would not suspect it is MQ |
| 18:02.29 | jmls | (in asterisk, that is) |
| 18:02.42 | leifmadsen | ah, not AMQP :) |
| 18:02.56 | jmls | the console is still logging devstate changes after there are no calls to process |
| 18:03.04 | jmls | leifmadsen apache activeMQ |
| 18:03.48 | leifmadsen | gotcha, not sure if that is erlang as well or not |
| 18:03.56 | jmls | no, java |
| 18:04.03 | leifmadsen | yuck |
| 18:04.10 | leifmadsen | but that's just my opinion :) |
| 18:04.15 | jmls | what's interesting is that the MQ process is now @ 100 % cpu |
| 18:04.30 | jmls | however, if I use another client to send messages, I can send over 16000 per second |
| 18:04.45 | jmls | to the same broker |
| 18:05.14 | jmls | just had an error |
| 18:05.17 | jmls | java.lang.OutOfMemoryError: GC overhead limit exceeded |
| 18:08.47 | *** join/#asterisk-dev phonebuff (~chatzilla@23.31.148.65) |
| 18:11.42 | Corydon76-home | jmls: if it works on one and not the other, I'd run a packet capture to see what the difference is |
| 18:11.52 | phonebuff | Good Afternoon -- I am attempting to apply a patch to 1.8.19 (gareth-1.8.19.0.patch) and I have a number of exceptions and I can not build Asterisk |
| 18:12.28 | phonebuff | Since this is my first attempt at a patch I am a lttle lost |
| 18:12.40 | Corydon76-home | phonebuff: ask for support from the person who generated the patch |
| 18:12.52 | phonebuff | ./channels/sip/include/sip.h.rej |
| 18:12.53 | phonebuff | ./channels/chan_sip.c.rej |
| 18:12.55 | phonebuff | ================ |
| 18:14.05 | pabelanger | gets ready for it |
| 18:16.41 | phonebuff | Well, I went looking here: https://issues.asterisk.org/jira/browse/ASTERISK-13145 |
| 18:17.17 | phonebuff | but I am not real clear who would be the right contact -- As II have never used this before |
| 18:20.45 | phonebuff | Am I looking for the person who is the reporter or someone else ? I don;t see any contact / creator in the patch file itself . |
| 18:21.18 | *** join/#asterisk-dev serafie1 (~erin@76.73.167.231) |
| 18:21.45 | jmls | opticron : just ran a curl version sending the same message to the same queue |
| 18:22.05 | jmls | sent 10000 messages, received 10000 messages, last message arrived just as the script ended |
| 18:22.25 | Corydon76-home | phonebuff: given that the name of the patch has "gareth" in it, I'd suggest contacting the person named "Gareth". |
| 18:22.56 | jmls | what I did notice though, was that curl printed some data ("sentMessage") after every send |
| 18:23.44 | jmls | if I didn't process any returned data from func_curl would that cause a slowdown / problem ? |
| 18:24.14 | Corydon76-home | jmls: it shouldn't |
| 18:25.12 | Corydon76-home | jmls: Just curious, how is your server process responding to the POST? |
| 18:25.15 | phonebuff | So I am looking for Garth Palmer --- IS he on this irc ? |
| 18:26.03 | Corydon76-home | phonebuff: don't know, but probably not |
| 18:28.07 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:28.07 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:28.14 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 18:28.49 | jmls | Corydon76-home : mq reached 65% cpu |
| 18:29.07 | *** join/#asterisk-dev sustav (~vpp@nat/digium/x-fwapkivqbijkcspz) |
| 18:29.13 | jmls | it was a pretty intensive script, though ;) |
| 18:29.21 | jmls | for i in {1..10000}; do curl -d |
| 18:30.45 | phonebuff | So is there a way to leave Garth a Message on the Jira site ? |
| 18:31.39 | Corydon76-home | phonebuff: you can put a comment on the issue itself |
| 18:32.01 | Corydon76-home | but I would recommend not doing that and instead trying to contact him directly |
| 18:33.44 | jmls | does asterisk accept code that has an apache licence ? |
| 18:33.59 | pabelanger | file, so what backends have you done with your sorcery api? |
| 18:34.09 | file | pabelanger, in-memory and configuration file |
| 18:34.20 | file | astdb and realtime will probably end up being done too |
| 18:34.22 | Corydon76-home | jmls: don't think so, no |
| 18:34.31 | jmls | bugger |
| 18:35.00 | pabelanger | file, So if I want another backend, I need a new resource module? |
| 18:35.05 | pabelanger | EG: json |
| 18:35.06 | file | pabelanger, yes |
| 18:35.41 | file | although json itself isn't a persistence mechanism |
| 18:36.57 | pabelanger | file, okay, lets say redis |
| 18:37.17 | file | yup |
| 18:37.25 | file | each one in its own resource module |
| 18:37.44 | file | sorcery would map well to redis actually |
| 18:38.16 | phonebuff | Corydon - I am not having much luck finding him.. Lots of notes and comments by him, but no email |
| 18:39.03 | pabelanger | file, I can't seem to find your wiki page about it |
| 18:39.57 | pabelanger | or is there one? |
| 18:41.33 | file | sorry, phone |
| 18:41.36 | file | it's on wiki.asterisk.org |
| 18:42.02 | file | https://wiki.asterisk.org/wiki/display/AST/Data+Access+Layer+Design has basic details on the general idea, and there's documentation in the code on reviewboard |
| 18:43.58 | phonebuff | Having issue with applying a patch - gareth-1.8.19.0.patch or locating the author - Gareth Palmer -- https://issues.asterisk.org/jira/browse/ASTERISK-13145 |
| 18:45.48 | pabelanger | Might have to play with it in the next few weeks |
| 18:58.11 | jmls | Corydon76-home : what about a MIT licence ? |
| 19:00.13 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:15.04 | mjordan | pabelanger: I answered you last night - Qwell does. Last time I checked, he doesn't live in Turkey :-) |
| 19:21.16 | leifmadsen | shakes fist at CentOS/RHEL 6 DAHDI RPMs |
| 19:27.17 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 19:29.13 | jmls | it *must* be something in the way I'm using curl in the resource module |
| 19:29.20 | jmls | here's the scenario |
| 19:29.50 | jmls | remove the resource module, restart asterisk |
| 19:30.25 | jmls | change the dialplan to execute Set(EMPTY=${CURL(http://localhost:8161/demo/message?persistent=yes&type=queue&destination=hash42.devicestate,body=foo:bar1)}) |
| 19:30.45 | jmls | 5 times each call to simulate the 5 devstate changes I see per call |
| 19:31.01 | jmls | make 1000 calls, get 5000 messages by the time the calls stop |
| 19:31.08 | jmls | scenario #2 |
| 19:31.32 | jmls | rebuild the resource , having taken out the curl call |
| 19:31.44 | jmls | take out the 5 ${CURL calls from the dialplan |
| 19:32.12 | jmls | oh, added a sequence counter to devstate so that I can track the number of changes |
| 19:32.41 | jmls | make 1000 calls, get 5000 notices NOTICE[13104]: res_curl_state.c:99 curl_devstate_cb: DEVSTATE_CHANGE: seq [5011] Device [SIP/sipp] changed to state [Unavailable]] |
| 19:32.57 | jmls | again, notices stop when calls stop |
| 19:33.58 | jmls | so, dialplan func_curl keeps up with the calls (which fits in with what I see in production ) |
| 19:34.29 | jmls | curl_devstate_cb keeps up with the calls |
| 19:35.03 | jmls | so it *has* to be the way I'm using / calling / not doing something func_curl in my resource. |
| 19:35.13 | jmls | Or there's a problem with null channels in func_curl ;) |
| 19:50.26 | Corydon76-home | Does memory usage spike? |
| 19:51.48 | Corydon76-home | I'd still recommend that you do a packet dump and see what is functionally different between the packets sent one way or the other |
| 20:57.16 | *** join/#asterisk-dev mwally (~mwally@mwally.opencnam.com) |
| 21:00.54 | coreyf1513 | liefmadsen: what are you having trouble with for dahdi/centos6? I have working specs (i think i disabled misdn because I don't use it and got lazy). |
| 21:11.21 | leifmadsen | coreyf1513: just getting a sane spec file to build dahdi-linux and dahdi-tools |
| 21:11.31 | leifmadsen | if you have a reasonable spec file, I'd be appreciative of it being shared :D |
| 21:14.21 | jsmith | would like to see it as well, if possible |
| 21:15.31 | coreyf1513 | sure how would you like me to send them? note I did not document the changes I made from the SRPMS on packages.asterisk.org, shouldn't be too hard to diff the specs |
| 21:15.42 | leifmadsen | pastebin is fine with me |
| 21:17.50 | leifmadsen | I'll take it try building it in mock |
| 21:17.56 | leifmadsen | any additional clean up I do I'll post back |
| 21:20.35 | coreyf1513 | they work in mock (atleast with my mock config) |
| 21:20.43 | coreyf1513 | dahdi-linux-kmod: http://pastebin.com/2pA4gznk |
| 21:21.19 | coreyf1513 | dahdi-linux: http://pastebin.com/QcwA0QVc |
| 21:21.56 | coreyf1513 | dahdi-tools: http://pastebin.com/NLHZJY2M |
| 21:24.05 | leifmadsen | awesome thanks! I'm gonna play with those now and try to build my asterisk rpms against it |
| 21:27.02 | coreyf1513 | liefmadsen: for asterisk I remember I had to rediff the voicemail patches. centos 6 rpmbuild does not default to patch fuzz=2, so it was rejecting those patch files that would be accepted by centos5 |
| 21:30.00 | leifmadsen | gotcha |
| 21:30.22 | leifmadsen | I got asterisk rpms already building, and they were building against some dahdi stuff, but need to clean up dahdi RPMs for my own use (was using atrpms) |
| 21:35.40 | leifmadsen | coreyf1513: how do you build them via mock? are you building one rpm then loading it into a local repo to build the rest? |
| 21:35.45 | leifmadsen | maybe you have a mock trick I'm not aware of |
| 21:38.18 | coreyf1513 | my mock server is also my local yum server, I use a script to run mock, copy output rpm's to yum directory and update repodata |
| 21:38.35 | leifmadsen | coreyf1513: ya ok, so basically same thing I do then too |
| 21:39.08 | leifmadsen | I just happen to do it locally and then modify the mock config file to append a local repository for deps |
| 21:41.19 | coreyf1513 | my mock config always has the local repo |
| 21:42.36 | leifmadsen | aye |
| 21:42.42 | leifmadsen | thanks much, I'll play around with this |
| 21:42.48 | coreyf1513 | good luck |
| 21:46.46 | leifmadsen | thanks :) |
| 22:01.43 | jmls | ouch. segfault. |
| 22:02.00 | jmls | is there an unsubscribe for device state changes ? |
| 22:02.24 | jmls | I unloaded my module, and when the next change came through I got a segfault. |
| 22:02.33 | jmls | presume because my callback is now missing ;) |
| 22:05.18 | jmls | umm, I have a core. I have don't optimise set in compiler flags |
| 22:05.30 | jmls | but full says that there is no symbol table |
| 22:07.28 | jmls | running debuginfo-install |
| 22:15.45 | file | slight update for the SIP insanity - I've got one way audio |
| 22:27.41 | leifmadsen | file: oh nice :) |
| 22:27.45 | leifmadsen | sounds about par for the course |
| 22:28.17 | leifmadsen | coreyf1513: odd... using --root epel-6-x86_64 to build the rpm causes it to be built for fc17 |
| 22:28.34 | leifmadsen | I'll have to dig into it next week I suspect |
| 22:28.51 | coreyf1513 | liefmadsen: it's your default mock config? |
| 22:29.29 | coreyf1513 | check the /etc/mock/default.cfg symlink |
| 22:30.02 | leifmadsen | huh, right, that points at fc17 (the base OS)... I thought I was overriding that with --root |
| 22:30.33 | coreyf1513 | oh right |
| 22:30.42 | leifmadsen | so ya... strange |
| 22:30.51 | coreyf1513 | try --root=epel-6-x86_64 |
| 22:32.24 | leifmadsen | ok so that was incredibly strange |
| 22:32.40 | leifmadsen | deleting the files in ~/rpmbuild/SRPMS/ caused it to rebuild correctly |
| 22:33.45 | coreyf1513 | but ~/rpmbuild should have no effect on mock!? |
| 22:35.56 | leifmadsen | I know right?! |
| 22:36.26 | leifmadsen | anyways, thanks :) |
| 22:36.45 | leifmadsen | oh wait... wtf :) |
| 22:36.52 | leifmadsen | dahdi-linux-kmod-2.6.1-1.el6.3.6.11_1.fc17.src.rpm |
| 22:37.45 | leifmadsen | I'm not sure how that's even possible :) |
| 22:37.51 | leifmadsen | ok, I should go drink beers |
| 22:42.33 | coreyf1513 | oh i know what it is |
| 22:42.55 | coreyf1513 | add to your mock config file: config_opts['macros']['%dist'] = '.el6' |
| 22:46.08 | coreyf1513 | no... the 3.6.11_1.fc17 is the kernel version for your host system.. my dahdi-linux-kmod uses uname to find the current running kernel and build for that |
| 22:50.44 | coreyf1513 | you can probably build from fc17 by with --define='kversion 2.6.32-220.17.1.el6' added to your mock command/replace with whatever version you want or edit the spec.. |
| 23:05.04 | *** join/#asterisk-dev sustav (~vpp@nat/digium/x-esjzqfxcdiieoqur) |