| 01:46.16 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 02:08.43 | *** join/#asterisk-bugs KactusOTP (n=kamil@59.191.225.49) |
| 02:16.54 | KactusOTP | Hi Everyone, was wondering whats the best way to proceed with a couple of the cases/issues I've had |
| 02:17.56 | KactusOTP | Seems I'm running into walls all the time, and maybe its better for me to maybe rethink the way I'm going about it. |
| 02:18.43 | jsmith | Have you already opened a bug report? |
| 02:18.54 | KactusOTP | (issues 13045 12708 and 12508) |
| 02:19.05 | KactusOTP | yes a couple with different version |
| 02:20.12 | KactusOTP | I've had issues with svn, 1.6, 1.4.21 and 1.4.17 (which works the best for me so far except for intermittent dead calls) |
| 02:20.53 | jsmith | I'd be happy to take a brief look, but I'm just a training/documentation guy |
| 02:20.59 | jsmith | I'm not a real developer |
| 02:21.28 | KactusOTP | I'd appreciate that :) I've been working on this since April |
| 02:22.13 | KactusOTP | It might just be that I'm doing something wrong all along |
| 02:23.20 | jsmith | Well, on 13045 -- there's definitely something wrong, as there's no SDP |
| 02:23.25 | jsmith | Do you know what SDP is? |
| 02:23.31 | jsmith | can't explain it if you don't |
| 02:23.42 | KactusOTP | Thats when it passes its properties |
| 02:23.54 | KactusOTP | to say "hey I support this" |
| 02:24.11 | KactusOTP | but it still happened with IAX |
| 02:25.33 | jsmith | knows jack about the internal workings of IAX |
| 02:25.50 | jsmith | It still sounds like one end doesn't support *any* codecs |
| 02:26.01 | jsmith | But that's just a wild guess |
| 02:26.20 | jsmith | I'd double-check the "disallow" and "allow" statements for the SIP and IAX peers on both sides |
| 02:26.26 | KactusOTP | hmm I've even hard set everything to only tall g711u its got me stumped |
| 02:27.49 | KactusOTP | I thought it might be that there is a couple of dead lines on the isdn but I checked and it dies on lines it can call through fine |
| 02:30.19 | jsmith | Again, you'd need to track down why the SIP INVITE (or IAX equivalent) doesn't have a session description |
| 02:31.30 | KactusOTP | with IAX its asterisk on the other end as well. What debug options would you suggest appart from IAX/sip ? |
| 02:32.21 | KactusOTP | and is it worth while getting mem debugs? |
| 02:33.16 | KactusOTP | The CTO is quite opposed to me running debug on the cisco though in case the load locks us out (its remote) |
| 02:37.21 | jsmith | Can you run a debug on both Asterisk boxes? |
| 02:37.28 | jsmith | That's the only other thing I can think of. |
| 02:38.25 | KactusOTP | yes, We've got a help desk call centre here so I can just swap them over to use the other boxes as the gateway |
| 02:39.05 | KactusOTP | just wanted to make sure I'm collecting all the debug you need :) |
| 02:41.14 | jsmith | A complete SIP trace (with "sip set debug on" and "rtp debug" and "core set verbose 4" and debug messages enabled in logger.conf) would be most helpful |
| 02:42.54 | KactusOTP | ok thank you very much I'll update the case once I've got it to fail :) |
| 02:43.47 | *** join/#asterisk-bugs ZX81 (n=matt@202.20.97.211) |
| 02:44.13 | jsmith | KactusOTP: You may also want to check rtp.conf and make sure you aren't running out of rtp ports (or open file handles) or something like that. |
| 02:45.10 | KactusOTP | it has rtpstart to end of 10000, 20000 |
| 02:45.34 | KactusOTP | it dies even with only a few calls so I'd assume this is enough? |
| 02:45.52 | jsmith | Yeah... 10,000 ports should be enough for at least 2000 calls |
| 02:46.55 | KactusOTP | we won't be putting that many through it at the moment :) |
| 03:05.14 | KactusOTP | Hmm is all that debug required? the office pbx log is at 30mb after 8 minutes. (rtp mainly) |
| 03:06.03 | jsmith | Technically you could probably get by without the RPT logging, but it's always more helpful to know when the RTP is flowing |
| 03:07.02 | KactusOTP | Since the issue is intermittant (a couple of times per day) I'd image the log will be a couple of gig by the end of it |
| 03:11.59 | jsmith | Yeah... very strange that it's that intermittent |
| 03:12.34 | KactusOTP | on a quiet weekend (only two people on phones) they came across it 4 times |
| 05:20.59 | *** join/#asterisk-bugs codefreeze-lap (n=murf@216.166.159.235) |
| 06:26.15 | KactusOTP | Ok it just failed I'm going to go through 600 MB of logs and clean it down to something reasonable |
| 06:51.24 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 07:21.42 | *** join/#asterisk-bugs grEvenX (n=even@ap39pb.ip.ssc.net) |
| 08:29.04 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 10:40.29 | *** join/#asterisk-bugs mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 10:43.14 | KactusOTP | Jsmith, thank you for your help earlier, I'm updating case 13045 now with the configs |
| 10:44.25 | KactusOTP | unfortunatley it seems to keep erroring out: Database query failed. Error received from database was #1153: Got a packet bigger than 'max_allowed_packet' bytes for the query: INSERT INTO mantis_bug_file_table .... |
| 10:44.53 | mvanbaak | gheh |
| 10:44.56 | mvanbaak | nasty |
| 10:45.07 | KactusOTP | its an 1887k file but it looks like safe text is padding it out I'll trim it down a bit more |
| 10:45.34 | mvanbaak | or upload it |
| 10:46.39 | KactusOTP | its erroring out when I upload it in the bug tracker, should I upload it else where? |
| 10:47.03 | mvanbaak | ah |
| 10:47.05 | mvanbaak | sorry |
| 10:47.11 | mvanbaak | did not know you tried uploading it |
| 10:47.45 | KactusOTP | its ok, its been one of those days for me today :) |
| 10:54.30 | mvanbaak | yeah, same here |
| 11:02.46 | KactusOTP | Gave up and zipped it, anyway have a good night hope your day improves:) |
| 11:03.14 | *** join/#asterisk-bugs DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:36.49 | festr_ | can anyone reopen this bug? http://bugs.digium.com/view.php?id=13047 |
| 11:37.06 | festr_ | sorry for crossposting to asterisk-dev but here it is appropriate |
| 11:37.08 | festr_ | i guess :) |
| 11:37.23 | festr_ | this bug was wrote by me and i'm able to reproduce it now on clean asterisk.14 svn |
| 11:45.09 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:03.59 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:04.00 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 12:13.05 | *** join/#asterisk-bugs shido6 (n=shido6@209.114.208.192) |
| 12:13.36 | *** join/#asterisk-bugs codefreeze-lap (n=murf@216.166.159.235) |
| 12:34.27 | mvanbaak | festr_: done |
| 12:35.37 | festr_ | mvanbaak: thanks |
| 14:02.13 | *** join/#asterisk-bugs DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 14:24.49 | *** part/#asterisk-bugs dwayne (n=dwayne@76.29.245.9) |
| 14:34.43 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 14:46.25 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 14:46.26 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 15:41.18 | *** join/#asterisk-bugs ACiDV (n=acidv@24-230-219-82.dr.cgocable.ca) |
| 15:52.50 | *** join/#asterisk-bugs codefreeze-lap (n=murf@216.166.159.235) |
| 15:58.16 | Corydon76-dig | rathaus: ping |
| 16:14.39 | mvanbaak | meh, Debian runs fine in a 32 MB domU |
| 16:14.50 | mvanbaak | 32MB ram that is |
| 16:40.44 | *** join/#asterisk-bugs fakhir_ (n=fakhir@unaffiliated/fakhir) |
| 18:19.27 | mvanbaak | what's the timeframe to close bugs where you requested feedback and get nothing back ? |
| 18:19.50 | Qwell | dunno, a month? |
| 18:19.59 | Qwell | which bug? |
| 18:20.28 | russellb | unless it's clearly a bug that needs to be addressed ... |
| 18:21.01 | Qwell | well, if nobody but the reporter can reproduce it... |
| 18:21.12 | mvanbaak | http://bugs.digium.com/view.php?id=12698 |
| 18:21.12 | Qwell | and the question was "please test 1.4.x" |
| 18:21.54 | Qwell | hmm |
| 18:22.11 | mvanbaak | tried with all the softkeys on my 7905 and 7960 |
| 18:22.12 | Qwell | softkey in skinny_ss? |
| 18:22.20 | Qwell | that seems odd |
| 18:22.20 | mvanbaak | none of them core asterisk |
| 18:23.19 | Qwell | he was also using the (old) rtp patch, which could potentially cause issues in ast_read |
| 18:23.32 | mvanbaak | k |
| 18:23.39 | Qwell | maybe |
| 18:23.50 | mvanbaak | will comment that, and ask for feedback again |
| 18:24.01 | mvanbaak | ask if he can reproduce it on stock 1.4 |
| 18:24.56 | mvanbaak | there |
| 18:25.03 | mvanbaak | want me to take it ? |
| 18:25.10 | Qwell | sure |
| 18:29.58 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 19:07.35 | *** join/#asterisk-bugs implicit (n=bayan@dhcp-x218-127.mobile.uci.edu) |
| 19:07.35 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 19:36.36 | *** join/#asterisk-bugs wunderkin (n=wunderki@cpe-24-24-210-131.socal.res.rr.com) |
| 19:37.22 | *** join/#asterisk-bugs wunderkin (n=wunderki@cpe-24-24-210-131.socal.res.rr.com) |
| 19:38.42 | *** join/#asterisk-bugs wunderkin (n=wunderki@cpe-24-24-210-131.socal.res.rr.com) |
| 19:40.57 | *** join/#asterisk-bugs DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 20:20.45 | *** join/#asterisk-bugs implicit (n=bayan@dhcp-x218-127.mobile.uci.edu) |
| 20:20.45 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 20:32.54 | *** join/#asterisk-bugs fakhir_ (n=fakhir@unaffiliated/fakhir) |
| 20:43.37 | mvanbaak | russellb: thank you for taking all this time on the xmldocs -dev mailinglist |
| 20:44.22 | russellb | np, i'm not being very helpful beyond expressing my personal goals :) |
| 20:46.35 | jsmith | russellb: In other words, you're being as helpful as me?!? |
| 20:47.07 | russellb | but, nailing down what the goal is, is pretty much step 1, so :) |
| 20:47.21 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 20:56.06 | mvanbaak | yup |
| 20:56.11 | mvanbaak | and I'm slacking |
| 20:56.22 | mvanbaak | so it's very nice that you fill the gap |
| 20:57.11 | mvanbaak | I think we still should stick with the XML format we came up with |
| 20:57.27 | mvanbaak | it's descriptive enough |
| 20:57.45 | mvanbaak | maybe we need to add a couple of attributes for version and dependency |
| 20:57.47 | mvanbaak | but that's it |
| 20:58.07 | jsmith | Yeah... I'm still debating the whole <para> thing |
| 20:58.07 | mvanbaak | the hardest part will be to generate some file with a nice C format to hold all the stuff |
| 20:58.13 | jsmith | I tend to think we need it |
| 20:59.27 | russellb | mvanbaak: does the current code generate the Syntax line in the "core show application foo" output? |
| 20:59.42 | russellb | we need to do that to be able to held demonstrate the completeness of the format ... |
| 20:59.48 | russellb | writing the code won't be trivial, though |
| 21:00.13 | jsmith | No kidding... |
| 21:00.18 | jsmith | But it'll be worth it! |
| 21:00.57 | mvanbaak | russellb: not yet |
| 21:01.01 | russellb | nods |
| 21:01.07 | mvanbaak | russellb: I had a patch that did it |
| 21:01.18 | russellb | put it in as a TODO :) |
| 21:01.20 | mvanbaak | but then the whole wave of comments started |
| 21:01.39 | mvanbaak | so I suspended it |
| 21:01.40 | russellb | i'm not sure that anyone has objected to the XML format itself |
| 21:01.47 | russellb | it's all about where/how it gets stored |
| 21:01.48 | mvanbaak | nope |
| 21:01.54 | Corydon76-dig | mvanbaak: we want it to be as perfect as possible, but not more so |
| 21:02.03 | mvanbaak | but a lot was indirectly objecting the whole idea |
| 21:02.22 | mvanbaak | at least in my opinion |
| 21:02.27 | mvanbaak | sorry if I'm overreacting |
| 21:02.44 | mvanbaak | I'll add a TODO |
| 21:03.10 | Corydon76-dig | You know what it should be written in, don't you? |
| 21:03.14 | mvanbaak | it's a hell of a job to get the syntax line ok |
| 21:03.22 | russellb | nods |
| 21:03.23 | Corydon76-dig | flex and bison |
| 21:03.27 | mvanbaak | Corydon76-dig: uhhuh. python |
| 21:03.34 | mvanbaak | hides |
| 21:03.40 | Corydon76-dig | mvanbaak: I'm serious |
| 21:03.50 | mvanbaak | yup, flex and bison will be the best ones |
| 21:03.59 | mvanbaak | and that's serious as well |
| 21:04.19 | mvanbaak | we'll have to stalk murph |
| 21:04.24 | mvanbaak | murf |
| 21:04.25 | mvanbaak | sorry |
| 21:04.31 | Corydon76-dig | Right |
| 21:04.43 | codefreeze-lap | feels so.... stalked |
| 21:04.44 | Corydon76-dig | He's the only person I know of who can stomach the job |
| 21:05.01 | mvanbaak | but yeah. that will be the best tool for this |
| 21:05.17 | codefreeze-lap | thinks his stomach already is queezy |
| 21:05.29 | codefreeze-lap | is such a tool |
| 21:05.37 | Corydon76-dig | and hence, I'm also leaning towards whatever his recommendation is for the syntax specification |
| 21:05.46 | codefreeze-lap | uh, what are we talking about |
| 21:05.57 | codefreeze-lap | looks back in history |
| 21:06.23 | Corydon76-dig | codefreeze-lap: having each app and function specify its own syntax, such that Asterisk may parse the extensions.conf for syntax violations |
| 21:06.48 | codefreeze-lap | already made a pass at that |
| 21:07.00 | russellb | o.O |
| 21:07.03 | Corydon76-dig | codefreeze-lap: and so third party apps may extend the syntax with their own specifications |
| 21:07.11 | russellb | codefreeze-lap: have you read the discussion on -dev about XML based documentation? |
| 21:07.21 | russellb | codefreeze-lap: if you have not, please do .. |
| 21:07.46 | Corydon76-dig | russellb: we really haven't covered what that job entails |
| 21:08.15 | Corydon76-dig | So reading the coverage so far won't do him much good |
| 21:08.38 | codefreeze-lap | I've seen the discussion slide by... but haven't been paying keen attention to it... I'm trying to figure out why 12960 wasn't affected by all the neat stuff I did |
| 21:08.45 | Corydon76-dig | Thus far, we've been talking about the documentation itself, not the syntax specification |
| 21:09.00 | russellb | the syntax spec is a part of the documentation format proposal! |
| 21:09.03 | russellb | have you looked at it at all? |
| 21:09.13 | codefreeze-lap | What I did previously, was have a file that described all the args to all the apps |
| 21:09.30 | codefreeze-lap | That wasn't real super practical |
| 21:09.32 | Corydon76-dig | I have, but I didn't see anything that covers syntax, other than "it should be here" |
| 21:10.22 | codefreeze-lap | I wanted to make it so the module app decls would include the syntax desc for the call, but haven't gotten there yet. |
| 21:10.58 | mvanbaak | Corydon76-dig: have a look at the apps/app_dial.c in that branch |
| 21:11.03 | russellb | it lists arguments in the proper order, which are required, what valid options are for the options string if there is one, whether the options take arguments, and whether the option argument has a separator ... |
| 21:11.11 | russellb | that is all info that describes the syntax of the args for the app |
| 21:11.12 | mvanbaak | what's in there is also documented in doc/xmldocumentation.txt |
| 21:11.28 | russellb | if you don't think it's enough, then _please_ describe what you feel is missing to the list |
| 21:11.34 | russellb | other than just saying "we don't have it yet" |
| 21:11.37 | codefreeze-lap | but if I had gotten there, the syntax (or structs) would closely parallel what I already did... and it does have all that info there. |
| 21:11.54 | mvanbaak | so we have a document that describes what nodes you can use, what the arguments for the nodes are, and what they are for |
| 21:12.04 | mvanbaak | and it also has apps/app_dial.c converted |
| 21:12.26 | mvanbaak | we picked the Dial application because it has almost everything |
| 21:12.48 | mvanbaak | arguments, variables, some stuff required, some stuff not, some variables writable, some read-only |
| 21:13.04 | codefreeze-lap | The big problems are: 1. at the time of dialplan loading, not all the other modules are yet loaded, and probably also their descriptions |
| 21:13.38 | mvanbaak | codefreeze-lap: that's why we are looking at a way to embed the stuff into asterisk |
| 21:13.39 | Corydon76-dig | russellb: for some option arguments, merely specifying mandatory or not is not enough. For some, there are 3 states: no argument, optional argument, mandatory argument |
| 21:14.02 | putnopvut | no argument has no requirement statement then. |
| 21:14.03 | russellb | ok, seems straight forward enough |
| 21:14.20 | russellb | app_dial has options that fall in the optional category, as well |
| 21:14.31 | Corydon76-dig | putnopvut: yes, but that doesn't differentiate between no argument and optional argument |
| 21:14.47 | mvanbaak | Corydon76-dig: we covered that: |
| 21:14.51 | putnopvut | Then I have misunderstood your complaint. |
| 21:14.57 | mvanbaak | <argument name="options"> |
| 21:15.19 | mvanbaak | <PROTECTED> |
| 21:15.40 | russellb | well, options are single letter :) |
| 21:15.43 | mvanbaak | <PROTECTED> |
| 21:15.52 | mvanbaak | I know, just making up names here |
| 21:15.55 | russellb | k |
| 21:16.14 | Corydon76-dig | mvanbaak: so the omission of an <argument> element means, mandatory, no argument? |
| 21:16.26 | mvanbaak | an <argument name="options"><option></option></argument> means the option takes no arguments |
| 21:16.41 | russellb | so the option argument should also include whether it is mandatory or not |
| 21:16.57 | mvanbaak | an <argument name="options"><option><argument></argument></option></argument> means the option takes one or more arguments. and they have the required attribute |
| 21:16.58 | russellb | include required=true/false there as well |
| 21:17.35 | mvanbaak | russellb: indeed |
| 21:17.55 | mvanbaak | bkruse and me already talked about making the required attribute mandatory |
| 21:18.08 | mvanbaak | so you _always_ have to specify if something is required or not |
| 21:18.09 | codefreeze-lap | Ha, you guys ought to look at my arg checking code. Very similar stuff |
| 21:18.18 | Corydon76-dig | mvanbaak: that's not exactly clear from the xmldocumentation.txt document |
| 21:18.31 | mvanbaak | Corydon76-dig: ah. then I have to fix that |
| 21:21.26 | Corydon76-dig | mvanbaak: while you're at it, you're missing the timeout parameter to the Dial documentation |
| 21:21.39 | mvanbaak | Corydon76-dig: commit r31119 |
| 21:21.41 | mvanbaak | arg |
| 21:21.49 | mvanbaak | Corydon76-dig: commit r131119 |
| 21:21.50 | jsmith | I thought I pointed that out already |
| 21:22.00 | mvanbaak | yup |
| 21:22.01 | jsmith | ducks |
| 21:22.20 | Corydon76-dig | Then svnsync is broken |
| 21:22.48 | Corydon76-dig | http://svn.digium.com/view/asterisk/team/group/appdocsxml/apps/app_dial.c?view=log |
| 21:23.46 | Corydon76-dig | russellb: ping |
| 21:23.57 | russellb | pong |
| 21:24.00 | file | it's there... |
| 21:24.05 | file | that specific commit he mentioned |
| 21:24.10 | russellb | svnsync being stupid? |
| 21:24.20 | Corydon76-dig | file: in app_dial.c ? |
| 21:24.54 | russellb | what's the current rev? we're up to 131120 ... |
| 21:24.57 | file | 13119 modified xmldocumentation.txt only |
| 21:25.16 | mvanbaak | and 131120 documents the timeout argument ;) |
| 21:25.24 | Corydon76-dig | There it is now |
| 21:25.32 | Corydon76-dig | Really slow |
| 21:26.43 | Corydon76-dig | btw, not end of times, just 136 years |
| 21:28.15 | Corydon76-dig | Tis important to be accurate |
| 21:29.37 | *** join/#asterisk-bugs ZX81 (n=matt@202.20.97.211) |
| 23:40.20 | *** join/#asterisk-bugs pabelanger (n=pabelang@OTWAON23-1242541604.sdsl.bell.ca) |
| 23:59.42 | *** join/#asterisk-bugs eliel (n=eliel@host-cotesma-162-8.smandes.com.ar) |