| 00:19.51 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ijzoenesibgstspn) |
| 00:35.04 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:35.04 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:58.22 | wedhorn | snuff-home: you around? |
| 01:01.02 | snuff-home | yer |
| 01:01.26 | wedhorn | with the fiddling around found some interesting stuff with the 14a packets |
| 01:01.58 | wedhorn | I'll work on the basis that the first string is string1 (rather than the c representation) |
| 01:02.26 | wedhorn | first string appears to be the fromnum, 8th is the from name |
| 01:02.55 | wedhorn | 2nd appears to be orig from and the 9th is the origfromname |
| 01:03.15 | *** join/#asterisk-dev mwally (~mwally@mwally.opencnam.com) |
| 01:03.19 | wedhorn | 3rd is the tonum and 10th is the to name |
| 01:03.32 | wedhorn | all simple, until you get this exception |
| 01:03.56 | wedhorn | if the 2nd string is null, the 9th string is not included (not even a null) |
| 01:04.22 | wedhorn | so if you have nums of from, null and to for the first 3 strings |
| 01:04.37 | wedhorn | 8th will be from name and 9th will be to name |
| 01:05.24 | snuff-home | interesting.. and annoying @ same time |
| 01:05.40 | wedhorn | yep, so not only variable length, but variable content |
| 01:06.02 | wedhorn | and oh yeah, all the name strings above should be plus 1, doh |
| 01:06.47 | wedhorn | so if we just use the 1st, 3rd, 9th and 10th strings and leave everything else null, the caller info seems to be correct, both inbound and outbound |
| 01:07.12 | wedhorn | missed calls log fine, received and placed don't get logged at all |
| 01:08.36 | snuff-home | :( |
| 01:08.53 | wedhorn | yeah yeah, but it's a start |
| 01:09.15 | snuff-home | mm.. but if i recall.. we send a 2nd 14a when the user picks up |
| 01:09.32 | wedhorn | maybe additional info is sent when a call is connected. Most of the pcaps you sent were unanswered... |
| 01:09.48 | wedhorn | possibly, need to have a look at it |
| 01:09.59 | snuff-home | try call-info3 pcap |
| 01:10.09 | snuff-home | i think.. that also had some answered ones |
| 01:10.48 | snuff-home | shakes fist @ ticketek.. where's my stupid mms with my aus open ticket :( |
| 01:11.30 | wedhorn | don't think you sent that one to me |
| 01:12.01 | snuff-home | mm.. i go check on work pc.. gimme sec |
| 01:12.12 | snuff-home | (will find useful picked up call pcap) |
| 01:15.31 | *** join/#asterisk-dev litan (~litan@erft-5d8093db.pool.mediaWays.net) |
| 01:16.36 | snuff-work | sent u another 1.. |
| 01:20.32 | wedhorn | looks like unknown4 is originally 0 and becomes 1 when connected |
| 01:21.58 | wedhorn | everything else appears to be the same |
| 01:22.41 | snuff-work | remind me.. which 2 numbers is that between.. aka who call who.. |
| 01:22.52 | snuff-work | (looking @ another pcap atm) |
| 01:23.35 | wedhorn | 3202 -> 3204 |
| 01:24.09 | snuff-work | ok.. so the pcap is from 3202 |
| 01:25.00 | wedhorn | yep |
| 01:25.19 | wedhorn | I think anyway (assuming i'm reading the 14a message correctly ;) |
| 01:25.40 | snuff-work | possible that unknown4.. could also swap to diff value if its the one recieving and gets connected ? |
| 01:26.59 | wedhorn | hangon, so that's an outbound pcap you gave me?? |
| 01:27.20 | snuff-work | looks like.. |
| 01:27.57 | wedhorn | um actually yeah, does look like it. Starts with a redial from that IP. |
| 01:29.10 | wedhorn | you know if skinny places unsuccesful outbound calls in the calls made list? |
| 01:29.17 | wedhorn | sorry, ccm |
| 01:30.15 | snuff-work | i think so.. can't check atm course ;) |
| 01:31.26 | wedhorn | yeah probably |
| 01:34.39 | wedhorn | i've found one of the original xfer pcaps you sent that has the same, unknown4 is 0, changes to 1 when connected |
| 01:35.17 | wedhorn | that one is inbound (but indirectly) |
| 01:35.34 | snuff-work | yes.. probably same 1 i'm lookin @ |
| 01:35.44 | snuff-work | so it seems 'sane' |
| 01:36.03 | wedhorn | don't think there is anything sane about 14a |
| 01:36.17 | wedhorn | if it seems sane, it's probably wrong ... |
| 01:36.53 | snuff-work | now.. that 3202 -> 3204.. that was an outbound call.. was anything diff u could see that might make it show as a 'placed call' ? |
| 01:37.10 | snuff-work | i'm sure if we had the actual spec it wouldn't seem too crazy |
| 01:39.51 | wedhorn | yep, we've already got that. calldirection, 1 is inbound, 2 is outbound (and 3 is some sort of xfer) |
| 01:39.57 | snuff-work | mm |
| 01:41.07 | wedhorn | if we work on the basis that unknown4 is a sort of callstate (unanswered=0, answered=1) that still leaves us 4 other unknowns |
| 01:42.05 | snuff-work | true.. |
| 01:43.11 | wedhorn | i noticed that the pcap you just sent has 00100 initially and then 00110 when connected for the 5 unknowns |
| 01:44.04 | wedhorn | I was sending 20020, so completely different |
| 01:44.22 | snuff-work | mm |
| 01:44.41 | snuff-work | i believe that 00100 = placing outbound call |
| 01:44.58 | wedhorn | actually, I think I initially tried 20010 which seemed to remove the first digit of the dialed number |
| 01:46.06 | snuff-work | and 22100 = fwd call non picked up.. and 22110 = fwd + pickup |
| 01:46.08 | wedhorn | possibly, but both 20020 and 20010 knew that the call was outbound because it displayed the "to" details rather than the "from" details |
| 01:46.20 | wedhorn | it must have picked up that from the calldir var |
| 01:46.46 | wedhorn | I think more playing is need to try to identify what some of these unknowns do |
| 01:48.04 | snuff-work | get feeling that 00 = outbound (unknown 1/2) .. 11 = inbound and 22 = fwd |
| 01:48.47 | snuff-work | the next always seems '1'.. then its 0/1 depending if picked up |
| 01:48.58 | snuff-work | then our random always 0 |
| 01:50.07 | snuff-home | sound reasonable? |
| 01:52.58 | wedhorn | I don't think so |
| 01:53.56 | wedhorn | wireshark trunk has got a bit of a guess at the packet structure, but they code pretty much says it's a guess |
| 01:54.20 | wedhorn | there's additional stuff |
| 01:54.33 | wedhorn | but I think they've got some of it wrong |
| 01:54.46 | wedhorn | it seams a lot more dynamic than just size |
| 01:54.52 | wedhorn | seems |
| 01:57.05 | wedhorn | http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-skinny.c?view=markup line 2827 |
| 01:59.43 | wedhorn | anyway, i've got to diappear for a while |
| 02:03.18 | snuff-home | np me too |
| 02:19.21 | snuff-home | btw i think those always 0's.. being vmail.. makes sense.. my ccm doesn't have vmail |
| 02:46.25 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 02:46.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:34.34 | *** join/#asterisk-dev sustav (~vpp@76.73.166.16) |
| 03:58.16 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 04:11.26 | *** join/#asterisk-dev sustav (~vpp@76.73.166.16) |
| 04:23.40 | *** join/#asterisk-dev sustav (~vpp@76.73.166.16) |
| 05:34.12 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 06:31.49 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 08:34.23 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 08:34.24 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:48.27 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 08:51.10 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 10:04.42 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 10:04.42 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 13:07.12 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:c1ed:23f0:ea46:87bb) |
| 13:35.10 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:35.10 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:05.40 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 14:05.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 14:47.16 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:47.16 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:26.51 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 15:50.04 | pabelanger | So, why to we ship sln16 prompts but not the sln/raw formats? |
| 15:50.11 | pabelanger | for core sounds |
| 15:56.18 | pabelanger | s/to/do |
| 16:01.51 | jsmith | pabelanger: To make curious kids like you ask questions :-p |
| 16:02.04 | pabelanger | indeed |
| 16:02.52 | pabelanger | jsmith: which conference you at now? |
| 16:03.21 | jsmith | pabelanger: Fedora Users and Developers Conference |
| 16:10.21 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 16:15.40 | *** join/#asterisk-dev Deeewayne (~dwayne@c-76-29-244-10.hsd1.al.comcast.net) |
| 16:15.40 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:45.31 | jmls | this is a dumb question, I know. but I have to ask it. |
| 16:45.40 | jmls | is asterisk multi-threaded ? |
| 16:46.00 | jmls | thread_storage etc would give me a clue that it is ;) |
| 17:19.59 | jsmith | jmls: Yes |
| 17:20.11 | jsmith | jmls: (for various definitions of multi-threaded) |
| 17:20.24 | jmls | ah. what I am trying to figure out is that if devstate changes are processed serially by a consumer |
| 17:21.17 | jmls | then changes that are published to a web service using curl will have to be processed one at a time by the devstate consumer, right ? |
| 17:22.19 | jmls | so, is execution in the dialplan multi-threaded ? (one channel does it's thing at the same time another channel does it's own) |
| 17:23.13 | jmls | if so, this would explain the behaviour that I am seeing - if I use func_curl in the dialplan I see no problems with processing 10000 calls that make curl requests |
| 17:23.35 | jmls | whereas the devstate consumer is getting bogged down (as is ActiveMQ) |
| 17:23.44 | jmls | the data packets seem the same |
| 17:28.16 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 17:28.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 18:05.46 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 18:18.02 | *** join/#asterisk-dev sustav (~vpp@76.73.166.16) |
| 19:35.49 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:35.49 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:28.13 | jmls | is there any socket libraries in asterisk ? |
| 20:28.33 | jmls | is thinking of writing a very basic stomp client in asterisk using sockets |
| 20:29.15 | jmls | so the device state consumer would connect to a stomp server on module load, and then just post data down the socket |
| 20:51.19 | wedhorn | snuff-home: wohoo. call logs all working on 7961. Missed, received and placed. If unknown number, dial and editdial are greyed... |
| 20:53.47 | snuff-home | OMG :P |
| 20:54.03 | snuff-home | so were we right with our 00 / 11 / 22 parts? |
| 20:54.27 | wedhorn | yeah bit messy, seems we've got issues with the call loggin using the old callinfo as well |
| 20:55.17 | snuff-home | mm.. well can't wait to test when i get in tomorrow :) |
| 20:55.24 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 20:55.24 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 20:55.28 | wedhorn | it's all based on callstate and callinfo |
| 20:56.15 | wedhorn | the 144 and 145 packets appears to be prompts (7961 sends a message that it doesn't understand our current display_prompt message) |
| 20:57.17 | snuff-home | k gotta go.. off to the tennis now :) |
| 20:57.34 | snuff-home | good work.. mostly by u but glad i can help |
| 20:58.14 | snuff-home | *gonerz* |
| 21:11.22 | *** join/#asterisk-dev jarg (~dsystem@pool-96-244-254-28.bltmmd.fios.verizon.net) |
| 21:26.29 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 21:26.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:40.39 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:40.40 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:19.28 | Tim_Toady | ; |
| 22:24.21 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:24.22 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:24.51 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 22:49.11 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 22:49.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 23:52.47 | wedhorn | snuff-home: inital patches for the call logging issues at https://issues.asterisk.org/jira/browse/ASTERISK-20964 |
| 23:53.08 | wedhorn | bit of a worry that it doesn't include any of the packet stuff we were working on ... |