| 00:56.19 | *** join/#asterisk-dev alexoc (~alexoc@187.64.254.47) |
| 00:56.38 | *** part/#asterisk-dev alexoc (~alexoc@187.64.254.47) |
| 00:56.58 | *** join/#asterisk-dev alexoc (~alexoc@187.64.254.47) |
| 00:58.21 | wedhorn | snuff-work: pong |
| 00:58.46 | snuff-work | with skinny.. (currently using trunk) |
| 00:59.10 | snuff-work | if i have a 'ringing' phone using sccp.. i can't 'end call' / reject |
| 00:59.21 | snuff-work | i see * get a 'got hangup softkey' |
| 00:59.28 | snuff-work | but nothin happens |
| 00:59.52 | snuff-work | Received Softkey Event: End Call(1/49) |
| 01:04.26 | wedhorn | having a look |
| 01:07.16 | wedhorn | snuff-work: at about line 6446, if the hookstate is onhook (eg prior to answer), it does nothing |
| 01:08.02 | wedhorn | you could try removing that block and see what happens |
| 01:09.53 | snuff-work | so this is under case SOFTKEY_ENDCALL: ? |
| 01:09.56 | wedhorn | Basically I think that code is a copy of the ONHOOK event, but it probably shouldn't be quite so similar (ie the softkey is more explicit than an onhook) |
| 01:10.00 | wedhorn | yep |
| 01:10.28 | wedhorn | block beginning 4th line after case SOFTKEY_ENDCALL |
| 01:10.33 | snuff-work | remove the check only or the entire if (comment out lot) |
| 01:11.10 | wedhorn | remove the 6 lines (including 2 comment lines) |
| 01:11.24 | wedhorn | remove: |
| 01:11.26 | wedhorn | if (d->hookstate == SKINNY_ONHOOK) { |
| 01:11.26 | wedhorn | /* Something else already put us back on hook */ |
| 01:11.26 | wedhorn | /* Not ideal, but let's send updated time anyway, as it clears the display */ |
| 01:11.26 | wedhorn | transmit_definetimedate(d); |
| 01:11.26 | wedhorn | return 0; |
| 01:11.27 | snuff-work | k recompilin now |
| 01:11.27 | wedhorn | } |
| 01:14.01 | snuff-work | yep.. now works |
| 01:14.10 | wedhorn | cool |
| 01:14.42 | snuff-work | makes sense i think not to have that check for inbound calls |
| 01:14.56 | wedhorn | I'll change mine too and if it runs okay for a while will commit it |
| 01:15.05 | snuff-work | :) |
| 01:15.43 | wedhorn | makes sense not to have that check for the softkey (given that the softkey message includes a specific callreference whereas the onhook doesn't) |
| 01:15.45 | snuff-work | i will be moving 10 phones over to this soon.. work really wants it in now.. and i just noticed that little bug |
| 01:17.09 | wedhorn | cool, 10 more testers - that increases the test base by 6 ;) |
| 01:17.34 | snuff-work | there will be another 20 a few days after that |
| 01:17.40 | snuff-work | when i move the other office |
| 01:17.51 | snuff-work | oh that was another question.. |
| 01:18.02 | snuff-work | does chan_skinny support SRST |
| 01:18.17 | snuff-work | aka can i specify a failover server |
| 01:19.30 | snuff-work | i must admit i haven't looked hard to see if it was supported |
| 01:20.11 | wedhorn | hang on, let me google what SRST is (and therein probably lies the answer) |
| 01:20.42 | WIMPy | I tried chan_skinny yesterday and I have to admit I used a museum piece, a 30vip, but I also produced lots of Asterisk lockups and a crash. |
| 01:20.45 | snuff-work | basically.. its if the CCM dies.. the phone looks to a cisco router which runs it |
| 01:21.14 | snuff-work | aka.. its just a second callmanager entry |
| 01:21.31 | wedhorn | snuff-work: that's config stuff for the device (tftp) not skinny |
| 01:21.37 | wedhorn | so I guess it should work |
| 01:21.49 | snuff-work | k i will have to attempt it soon |
| 01:21.52 | WIMPy | When I put the phone in my usual phone context containing loopback switches, it killed dialling for ever. |
| 01:22.00 | wedhorn | WIMPy: trunk? |
| 01:22.11 | WIMPy | yes |
| 01:22.17 | wedhorn | loopback switches? |
| 01:22.40 | WIMPy | And ithout the switches I could only dial one digit and got an invalid extension then. |
| 01:23.08 | WIMPy | lswitch => Loopback/... |
| 01:23.11 | wedhorn | WIMPy: for info I've still got a 30vip (only disconnected it a couple weeks ago) and it was working fine |
| 01:23.23 | WIMPy | Hmm. |
| 01:23.40 | wedhorn | possibly a config issue? |
| 01:23.44 | WIMPy | I also only got audio on the 1st call. |
| 01:24.07 | wedhorn | sounds weird |
| 01:24.20 | WIMPy | As for terminating dialling after the first digit, quite possible. |
| 01:24.42 | wedhorn | I'm happy to have a look at the config etc if you're interested |
| 01:25.13 | WIMPy | Well, that's quite short. Let me copy that. |
| 01:26.03 | WIMPy | http://wimpy.yeti.dk/skinny.conf |
| 01:30.38 | wedhorn | WIMPy: your dialplan, you "dial(Skinny/1)" and nothing more? |
| 01:31.02 | WIMPy | Dial(skinny/1@30vip) |
| 01:31.28 | wedhorn | oh, I thought we got rid of that a few years ago... |
| 01:31.44 | wedhorn | try removing the @30vip |
| 01:32.15 | WIMPy | Hmm ok, but I can get two calls to the phone. |
| 01:33.07 | wedhorn | sorry, what do you mean? |
| 01:33.14 | WIMPy | The 1st with audio and the second without. I can terminate the second call, but the phone will never notice, even if I hangup on itself. |
| 01:33.27 | WIMPy | The dial seems to work. |
| 01:34.09 | WIMPy | It's dialling from the phoe that I couldn;t get going any more. |
| 01:34.16 | wedhorn | multiple calls on a single line on the 30vip may be dodgy |
| 01:34.31 | WIMPy | I had it working a loong time ago. Probably on 1.4, but I can't remember which cahnnel I used back then. |
| 01:35.11 | WIMPy | Yes, one after another, not simultaneous. That doesn't work and didn't back then. |
| 01:35.23 | wedhorn | yeah, most of the work has been on the more recent devices and so things work differently now |
| 01:36.21 | wedhorn | for simple calls (in and out) I haven't haven't had issues with the 30vip |
| 01:37.20 | WIMPy | Well I do, and as I said, when using myu normal phone context it will make placing calls impossible for other channeltypes as well. |
| 01:37.30 | WIMPy | I did a lot of kill -9. |
| 01:38.50 | wedhorn | if you're context "special" stuff, it may cause issues, especially if it initiates an additional subchannel back to the device |
| 01:39.35 | WIMPy | Not sure what you mean there? |
| 01:39.44 | wedhorn | because the 30vip lacks the subchannel control of the newer devices, you can end up with a sort of zombie channel |
| 01:40.26 | wedhorn | can you paste your context dialplan? |
| 01:43.21 | WIMPy | http://wimpy.yeti.dk/pastebin |
| 01:43.47 | snuff-work | has never used such an interesting looking DP |
| 01:43.50 | WIMPy | [masters] then contains some real extensions. |
| 01:44.16 | snuff-work | don't even know what lswitch stands for :P |
| 01:44.23 | WIMPy | I tried to use masters instead. that was when the call was aborted after dialling the first digit. |
| 01:44.45 | WIMPy | Yes, took me some time to find out about this extremely helpful thing. |
| 01:45.23 | WIMPy | But I'm still not exactely sure about the difference between lswitch and eswitch. This stuff is hardly documented. |
| 01:45.43 | wedhorn | damn, I wouldn't know where to start |
| 01:45.52 | WIMPy | But this way you can dial extensions in any format. |
| 01:47.31 | snuff-work | k reading the little doc there is.. lswitch passes the vars to the switch command to interpret.. where eswitch subs the vars before handing to switch |
| 01:47.56 | wedhorn | looks like a dialplan disa |
| 01:48.04 | WIMPy | Yes, but what exactely is the difference? |
| 01:48.47 | snuff-work | skinny queries the DP to determine if something is dialable |
| 01:48.52 | WIMPy | It uses the same contents in both cases. |
| 01:49.12 | snuff-work | where sip just sends what it has.. non interactive dial |
| 01:49.28 | WIMPy | Yes, that's the nice thign abot SCCP, IMHO. |
| 01:49.47 | WIMPy | You can do it with sip. |
| 01:50.02 | snuff-work | mm.. never done it with sip.. i dont 'think' |
| 01:50.04 | wedhorn | It seems a strange setup to use for skinny given how skinny handles dialing, but I suppose it should be compatible (and if there are issues it's likely because of a bug) |
| 01:50.10 | snuff-work | would have been yeas ago |
| 01:50.33 | WIMPy | I do it with sip. |
| 01:51.09 | WIMPy | You can't have overlapping extensions with timout on sip, but I consider that ugly anyway. |
| 01:51.30 | snuff-work | what's req to make it work with sip.. |
| 01:51.38 | wedhorn | WIMPy: can you give us a snippet of the masters context? |
| 01:51.49 | WIMPy | snuff-work: A phone that can do it. |
| 01:52.04 | snuff-work | ah thought it might be phone dep |
| 01:53.39 | WIMPy | wedhorn: The interesting bit should be an include that contains the real extensions. |
| 01:54.10 | WIMPy | I've appended the masters context. |
| 01:54.18 | snuff-work | mm.. extenpatternmatchnew = evil |
| 01:54.42 | snuff-work | when dealing with included contexts |
| 01:55.59 | WIMPy | Hmm. I don't have that. What's the default? |
| 01:56.14 | snuff-work | i think its still off |
| 01:56.14 | wedhorn | pattern matching, will s be used for a partial match? |
| 01:56.42 | WIMPy | No |
| 01:57.16 | WIMPy | Only for the BRI phones when picking up before dialling. |
| 01:59.24 | snuff-work | mm must admit i dont like using the 'same=>' thing.. prefer to just use the same extension regex |
| 01:59.58 | snuff-work | but i guess it depends how long ur extens might be or how u space ur extensions file |
| 02:01.05 | WIMPy | Better don't look at my forwarding feature codes... |
| 02:02.59 | snuff-work | that 10X!.. almost looks like it would be more clean having a for loop making the long dial string |
| 02:05.03 | WIMPy | Dynamically generate a static string? |
| 02:05.29 | snuff-work | if u really like it looking clean i guess or u get bored |
| 02:06.23 | WIMPy | *10 and *1* should do the same. It's just for testing. |
| 02:07.29 | WIMPy | Maybe the users context would have had less confusing stuff :-) |
| 02:07.45 | snuff-work | always interested in ppls DPs |
| 02:08.29 | wedhorn | WIMPy: I don't think dial-master is skinny compatible, but don't see any real reason why masters shouldn't work |
| 02:09.31 | wedhorn | out of interest what was the first digit that caused the abort when you used the masters context |
| 02:09.45 | WIMPy | any |
| 02:11.27 | wedhorn | any console messages? |
| 02:11.41 | wedhorn | did you try with "skinny set debug on" |
| 02:12.04 | WIMPy | Just a normal message about non-existant extensions. |
| 02:12.21 | WIMPy | Let me get that phone back here... |
| 02:15.54 | WIMPy | Hmm. |
| 02:16.52 | WIMPy | I can dial now, but nothing happens. |
| 02:17.30 | wedhorn | what number? |
| 02:17.49 | WIMPy | After a match it clears the display, no audio and no difference when the call ends. |
| 02:17.58 | wedhorn | ah, also, you may need for it to timeout if it can't find an exact match |
| 02:18.01 | WIMPy | After some time the phone reboots. |
| 02:18.11 | WIMPy | 1191. that just does a SayUnixTime() |
| 02:18.55 | wedhorn | can you "skinny set debug on" and give us the relevant part |
| 02:19.04 | WIMPy | Yes, matching seems to work now. Not sure what's different to yesterday. |
| 02:22.03 | WIMPy | Behaviour is very inconsistant. |
| 02:22.31 | WIMPy | Now I just got a lot of Prodding channel ... failed instead of a dialtone. |
| 02:23.01 | wedhorn | with skinny, once something goes off the rails, it never comes back |
| 02:23.17 | wedhorn | try core show channels and see if there's one floating around in the background |
| 02:23.55 | WIMPy | It is for as long as expected, even if I don;t hear anything or see any indication on the phone that the call is over until it reboots. |
| 02:24.10 | WIMPy | Ok, got a full one now. |
| 02:24.32 | WIMPy | http://wimpy.yeti.dk/pastebin |
| 02:28.43 | wedhorn | WIMPy: did the call work up until the phone resets |
| 02:29.06 | WIMPy | No |
| 02:29.13 | WIMPy | No audio. |
| 02:30.21 | WIMPy | If I place a call TO the phone I get audio. |
| 02:30.30 | WIMPy | At least on the first attempt. |
| 02:30.55 | WIMPy | On the second attempt it's no audio, either and it will eventually reboot. |
| 02:31.31 | wedhorn | strange. Regarding the reset, it looks like asterisk is receiving an unexpected packet. Can you post a log with "skinny set debug packet" |
| 02:31.50 | WIMPy | The interesting thing is that I can still end the call from the 30vip, even if itself won;t show any reaction. |
| 02:33.20 | wedhorn | can you try an answer before sayunixtime (there should be some rtp stuff in the log, which there isn't) |
| 02:36.15 | WIMPy | There was an answer |
| 02:36.50 | WIMPy | After 'skinny set debug packet' I don't seem to get more output than before. |
| 02:37.00 | wedhorn | in the dialplan |
| 02:37.18 | wedhorn | it should note that packets are being sent and received |
| 02:37.29 | WIMPy | Line 24 |
| 02:38.33 | wedhorn | insert an answer() on the line before sayunixtime |
| 02:38.34 | WIMPy | oh, yes a few. Lets see what happens until the reboot. |
| 02:38.43 | WIMPy | There is an Answer(320) |
| 02:40.18 | snuff-work | u need a number in answer? |
| 02:40.58 | wedhorn | sorry, missed that |
| 02:41.10 | wedhorn | snuff, it's a ms delay after answering |
| 02:41.54 | WIMPy | http://wimpy.yeti.dk/pastebin now with packet debug and including the reboot. |
| 02:44.14 | WIMPy | wonders why Asterisk reads the .gsm files and not the .wav files. |
| 02:48.12 | WIMPy | Err, sure, because of the language. Forget about that. |
| 02:48.18 | JunK-Y | Corydon76-home: ping? |
| 02:48.27 | Corydon76-home | pong |
| 02:52.22 | wedhorn | WIMPy: are you sure you're in trunk? |
| 02:53.18 | JunK-Y | about the ast_expr2f.c, not sure how i force the generation? |
| 02:53.21 | WIMPy | Asterisk SVN-trunk-r352626M built by root @ lx3 on a i686 running Linux on 2012-01-25 22:33:37 UTC |
| 02:53.21 | wedhorn | does "skinny set debug packet" work? |
| 02:53.50 | WIMPy | It doesn't moan. |
| 02:53.50 | wedhorn | none of the additional packet stuff came through |
| 02:54.26 | Corydon76-home | JunK-Y: make menuselect, Compiler Options, REBUILD_PARSERS |
| 02:54.28 | WIMPy | It says Skinny Debugging Enabled including Packets. |
| 02:54.56 | snuff-work | u get something like this on trunk with my phone.. |
| 02:55.02 | JunK-Y | i know, but after doing the make, im still with my old files |
| 02:55.24 | wedhorn | is confused |
| 02:55.54 | snuff-work | http://paste2.org/p/1885062 |
| 02:56.50 | wedhorn | snuff-work: is that with debug packet on or off? |
| 02:57.06 | snuff-work | on |
| 02:57.16 | wedhorn | bugger |
| 02:58.29 | WIMPy | Does it need something enabled in logger.conf? |
| 02:58.29 | wedhorn | this is my offhook: http://paste2.org/p/1885063 |
| 02:58.47 | Corydon76-home | JunK-Y: check file dates |
| 02:58.55 | snuff-work | http://paste2.org/p/1885064 |
| 02:59.08 | snuff-work | i forgot to set debug lvl of 5 for the core.. |
| 02:59.14 | snuff-work | now mine looks similar i think |
| 03:00.04 | wedhorn | no, you're missing most of the Transmitting/Received lines |
| 03:00.08 | WIMPy | used verbose 3 and debug 9. |
| 03:02.00 | JunK-Y | Corydon76-home: REBUILD_PARSERS is there, i typed make and ast_expr2f.c is still from 2 days ago. |
| 03:02.17 | Corydon76-home | Do you have flex installed? |
| 03:02.38 | JunK-Y | junky@wireshark:~/asterisk-trunk$ flex --version |
| 03:02.38 | JunK-Y | flex 2.5.35 |
| 03:03.07 | Corydon76-home | Huh, someone must have broken the dependency links |
| 03:06.12 | wedhorn | snuff-work: can you make the change at http://paste2.org/p/1885071 and see if you get some more debug with packet |
| 03:07.43 | snuff-work | mm.. i do have the skinny_debug enabled in the menuselect |
| 03:08.01 | snuff-work | skinny_devmode i mean |
| 03:10.06 | wedhorn | ah, put you still don't get the packet info... |
| 03:10.59 | wedhorn | and you explicitly set "skinny set debug packet" (with no on) |
| 03:11.51 | snuff-work | http://paste2.org/p/1885075 |
| 03:12.04 | snuff-work | i think that looks right no? |
| 03:12.23 | wedhorn | yep, that looks right |
| 03:12.41 | snuff-work | yer my 1st paste i forgot to enable the 'core debug' |
| 03:12.50 | snuff-work | aka why it may have been filtered |
| 03:12.53 | JunK-Y | Corydon76-home: can i force the generation with a specific command? |
| 03:12.56 | Corydon76-home | JunK-Y: just delete the 2f.c file |
| 03:13.26 | Corydon76-home | JunK-Y: Oh, did you re-run configure after installing flex? |
| 03:13.27 | snuff-work | ahh |
| 03:13.32 | snuff-work | u use VERB |
| 03:13.34 | snuff-work | not debug |
| 03:13.48 | snuff-work | WIMPy: try with verbose of 5 |
| 03:13.52 | JunK-Y | flex was already installed.. no i didnt re-run configure |
| 03:13.52 | WIMPy | aye |
| 03:14.02 | snuff-work | that should give the info he wants |
| 03:14.04 | Corydon76-home | Ah, shouldn't matter, then |
| 03:14.13 | Corydon76-home | JunK-Y: do you have bison installed, too? |
| 03:14.55 | JunK-Y | yes, 2.4.1 |
| 03:15.13 | JunK-Y | chan->language is now gone in trunk, interesting |
| 03:16.14 | Corydon76-home | You have to use accessor functions now, I believe |
| 03:16.25 | Corydon76-home | It's part of a push to make ast_channel opaque |
| 03:16.37 | JunK-Y | ya, ast_channel_language |
| 03:17.13 | snuff-work | wedhorn: i think we need to alter the skinny debug stuff.. to make it use ast_debug.. rather than ast_verb.. |
| 03:18.29 | WIMPy | http://wimpy.yeti.dk/pastebin updated |
| 03:18.45 | wedhorn | snuff-work: the whole skinny debugging needs a redo, most the debugging is leftovers from trying to fix up bugs |
| 03:19.01 | JunK-Y | Corydon76-home: |
| 03:19.01 | JunK-Y | <PROTECTED> |
| 03:19.02 | JunK-Y | <PROTECTED> |
| 03:19.03 | JunK-Y | yay |
| 03:19.08 | Corydon76-home | Yay! |
| 03:19.41 | JunK-Y | i need to change the chan->language to the opaque stuff |
| 03:19.58 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:19.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:21.56 | wedhorn | WIMPy: yep, that's what I was after. I'm guessing it's a firmware issue. Looks like your device is not responding to the OPEN_RECEIVE_CHANNEL request |
| 03:22.06 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 03:23.21 | WIMPy | It says L2.J2. |
| 03:23.42 | WIMPy | But it works in the other direction. At least once. |
| 03:23.59 | wedhorn | okay, can you give me a dump of that |
| 03:24.12 | WIMPy | Sure. |
| 03:26.24 | wedhorn | my 30vip has P00203010003 (I think) |
| 03:27.43 | WIMPy | http://wimpy.yeti.dk/pastebin Two calls to the vip, the first with audio, the second without and with the vip stuck. |
| 03:28.07 | WIMPy | I've seen such a number somewhere, but where? |
| 03:32.58 | wedhorn | your firmware may be sensitive to the order of some packets. I'll try to do up a patch |
| 03:33.04 | otherwiseguy | waits to see if pabelanger kicks him |
| 03:34.08 | JunK-Y | Corydon76-home: thx for ur help, everything worked. |
| 03:34.09 | WIMPy | I guess yours is newer. |
| 03:34.24 | JunK-Y | is there any other generated files like this one? |
| 03:34.35 | WIMPy | But somehow I doubt a newer version can still be found. |
| 03:34.40 | Corydon76-home | Just stuff in utils/ |
| 03:34.46 | Corydon76-home | copied from main/ |
| 03:34.50 | otherwiseguy | JunK-Y: sorry to take your patch and put it up on reviewboard. Tried to get a hold of you via JIRA, but failed. Good call on the calendar changes. |
| 03:35.23 | otherwiseguy | (they assigned the issue to me to push through this sprint, and the sprint is over tomorrow) |
| 03:37.59 | wedhorn | WIMPy: try an earlyrtp=0 in skinny.conf. May make the first outbound call work. |
| 03:38.55 | WIMPy | Under [general]? |
| 03:39.07 | wedhorn | yeah, or the device |
| 03:39.22 | JunK-Y | Corydon76-home: i will make sure my next huge patch will take care of this |
| 03:39.47 | JunK-Y | otherwiseguy: ya, i saw this only yesterday night. |
| 03:40.00 | JunK-Y | next time, feel free to ping me here if im not replying |
| 03:40.08 | wedhorn | WIMPy: probably better to put it under the device |
| 03:40.09 | WIMPy | Jay! |
| 03:40.18 | otherwiseguy | k. I looked for you the day I put it up, but didn't see you online. |
| 03:40.26 | WIMPy | It has audio and it goes back to idle state. |
| 03:40.45 | WIMPy | But still only for one call. |
| 03:40.47 | otherwiseguy | I wanted to put it somewhere where you would have a chance to comment on any changes before it going in. |
| 03:41.06 | wedhorn | okay, now for part 2 |
| 03:41.13 | JunK-Y | ya, ive got a boy and im trying to combine everything and i barely can by drinking a lot of coffee! |
| 03:41.41 | wedhorn | at about line 5118 of chan_skinny: there is "case SUBSTATE_ONHOOK" |
| 03:41.44 | otherwiseguy | doesn't like changing and committing people's patches w/o giving them a chance to comment/catch my mistakes |
| 03:41.46 | JunK-Y | i wrote this patch when i was stucked at the airport after astricon 2010 (not 11!) |
| 03:42.19 | wedhorn | 11 lines down there is "transmit_callstate(d, l->instance, sub->callid, SKINNY_ONHOOK);" |
| 03:42.43 | wedhorn | move that line up so that it is the first under the if statement |
| 03:42.54 | wedhorn | see if that helps |
| 03:43.57 | JunK-Y | otherwiseguy: can you explain long term goal with the opaquify ast_channel? |
| 03:44.11 | JunK-Y | just hide the chan->whatever ? |
| 03:47.07 | otherwiseguy | JunK-Y: Sure. Basically, with people accessing the internals of the channels everywhere, anytime we want to make a change to the structure, we end up having to fix tons of files. It also makes it really hard to come up with ways that we could re-tool locking/reference counting of channels. One of the cool benefits of having an opaque channel is that we could easily kill masquerades by making the externally visible channel handl |
| 03:47.07 | otherwiseguy | a container that contains a pointer to an internal channel structure that could just be swapped out so that the pointer that modules have never changes. No more crazy copying stuff for masquerades. |
| 03:48.21 | otherwiseguy | So 1) It makes it easier to make changes, 2) It leads to much more maintainable code and fewer bugs, and 3) It makes things that are currently impossible, possible. |
| 03:48.46 | snuff-work | masq fixing.. sounds good :) |
| 03:48.49 | otherwiseguy | Hopefully Digium will give me some time this month to work on creating a wiki page about it. |
| 03:49.09 | otherwiseguy | I've kind of been doing this stuff in my free time, mostly. |
| 03:49.41 | JunK-Y | on what are ya working at digium? private stuff? |
| 03:50.10 | otherwiseguy | JunK-Y: Just run-of-the mill bugs. Making our way through JIRA, mostly. |
| 03:50.43 | otherwiseguy | It's the side projects that keep me from stabbing myself in the face after a long day of staring at chan_sip. |
| 03:52.11 | WIMPy | wedhorn: Had to do a little search until I fund a second case SUBSTATE_ONHOOK a few lines further down. But moving the transmit_callstat to the top makes it worse. |
| 03:52.32 | WIMPy | Not I cannot place a second call to the phone at all. |
| 03:52.50 | wedhorn | okay |
| 03:53.02 | JunK-Y | otherwiseguy: thx, you can copy & paste this explanation for the wiki :) |
| 03:55.03 | JunK-Y | by looking ur patch, theres a ton of place, where we see like: |
| 03:55.04 | JunK-Y | <PROTECTED> |
| 03:55.04 | JunK-Y | <PROTECTED> |
| 03:55.22 | JunK-Y | why we dont check this within ast_free directly? |
| 03:56.16 | JunK-Y | so if i do ast_free(my_own_ptr), the caller wont have to if (my_own_ptr) ast_free(my_own_ptr) and just call ast_free(my_own_ptr) directly |
| 04:02.08 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:02.08 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:07.50 | JunK-Y | humm, atoi assigned to an uint! |
| 04:16.32 | otherwiseguy | JunK-Y: technically, it is safe to call free(NULL); |
| 04:26.27 | JunK-Y | ya, but in valgrind, you will get: invalid free if you call free(foo);free(foo); |
| 04:28.56 | otherwiseguy | Well don't do that. :-) |
| 04:30.43 | JunK-Y | then my question, why do you check if(whatever) before calling ast_free^ |
| 04:32.28 | otherwiseguy | Most of the time, anymore, I don't. If I modify other code that does it, I will go ahead and do it again. Back when I did the calendar stuff, I really didn't think about it. So much other code did it, I probably looked at it and just did something similar. |
| 04:34.12 | JunK-Y | time to update the coding guidelines? :P |
| 04:34.49 | otherwiseguy | When you have a bunch of refcounted things where you actually need to do an unref if the value is set, it is different (as the ref code will complain if you pass a non astobj2 object, I think). I prefer having the refcounted stuff be strict. And if you have a mix of refcounted and non refcounted stuff, the if() ast_free stuff makes things look more consistent and perhaps might keep someone from making a refcount error. |
| 04:35.34 | otherwiseguy | Not something I feel particularly strongly about either way. |
| 04:37.38 | otherwiseguy | I'm going to investigate the gcc cleanup attribute which could make some of the cleanup blocks go away. |
| 04:40.20 | JunK-Y | i didnt know there was a cleanup attribute, hehe |
| 04:40.58 | otherwiseguy | It's gcc-specific, but we already rely on so much gcc-specific stuff for asterisk, it wouldn't be a problem to use it…it's been around since gcc 3.3 I think. |
| 04:43.28 | JunK-Y | ohh, like smart pointer in C++ |
| 04:46.56 | JunK-Y | that could be useful to avoid deadlocks, by ast_mutex_unlock after the scope. |
| 04:50.58 | Corydon76-home | There's already some issues in the teardown order on BSD |
| 04:51.31 | Corydon76-home | I need to spend some time on OSX tracking it down |
| 04:52.08 | Corydon76-home | I think with gcc 4.4 and higher we can specify initialization and teardown order, so it will be less of an issue |
| 04:58.53 | otherwiseguy | JunK-Y: yep, one of the reasons I was excited to learn about it. |
| 04:58.59 | otherwiseguy | I think…I shall now go to sleep. |
| 05:01.01 | JunK-Y | good night |
| 05:01.14 | JunK-Y | simpson time for me |
| 05:01.59 | otherwiseguy | g'night! |
| 07:18.29 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:00.05 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 08:27.40 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 08:51.11 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:5df7:8baa:ef7b:1ff7) |
| 10:12.11 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 10:12.12 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:51.44 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 13:01.06 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:01.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:11.37 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:11.37 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:17.54 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 13:26.17 | *** join/#asterisk-dev ccesario (~ccesario@189.29.54.144) |
| 13:33.49 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 13:40.13 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:45.26 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 14:05.27 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-fctcfhshpvjkinls) |
| 14:13.40 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 14:15.57 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-axlayxkgviicpkxv) |
| 14:15.57 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:37.20 | *** join/#asterisk-dev alexoc (~alexoc@201.82.173.134) |
| 14:46.50 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:46.50 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:14.32 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 15:14.38 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 15:16.08 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:16.08 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:18.19 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:18.19 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:33.10 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 15:39.53 | *** join/#asterisk-dev tamiel (~tamiel@85-171-171-179.rev.numericable.fr) |
| 16:14.07 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:43.46 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 16:43.46 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 17:26.26 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 17:50.08 | kpfleming | otherwiseguy: putnopvut: for astobj1, RDLOCK and WRLOCK are synonymous, since the macros were never changed to actually use rwlocks |
| 17:50.45 | otherwiseguy | yeah, it is just ugly using the name RDLOCK when you are writing. :-) |
| 17:50.49 | kpfleming | correct |
| 17:50.57 | putnopvut | kpfleming: yeah, I made note of that on my comment |
| 17:51.07 | kpfleming | oh, sorry, i must have read too fast |
| 17:51.21 | putnopvut | I didn't use those exact words, but I mentioned that RDLOCK is actually just a mutex. |
| 17:51.26 | otherwiseguy | void pet_puppy() { kill_puppy()}; |
| 17:51.34 | kpfleming | otherwiseguy: harsh |
| 17:51.44 | file | noooooooooooooooo |
| 17:51.45 | kpfleming | also, a misplaced semicolon |
| 17:51.51 | otherwiseguy | and (void) |
| 17:52.28 | Corydon76-home | IIRC, they were originally rwlocks, but they had to be made back into mutexes, because there were some cases that needed recursive locking |
| 17:52.47 | otherwiseguy | stabs recursive locks |
| 17:53.01 | file | otherwiseguy, recursively? |
| 17:53.22 | otherwiseguy | file: iteratively, indefinitely |
| 17:53.41 | Qwell | recursive locks are overrated. |
| 18:00.42 | otherwiseguy | putnopvut: for some reason I ended up making 3 separate replies to your review. Weird. In any case, I'm working on fixing the stuff except the unrefs. |
| 18:01.44 | russellb | unrefs file |
| 18:01.52 | file | destructs |
| 18:02.06 | russellb | looks around ... WHO'S NEXT |
| 18:02.32 | russellb | unrefs leifmadsen |
| 18:02.46 | leifmadsen | o.O |
| 18:02.53 | otherwiseguy | ninja refs leifmadsen |
| 18:03.00 | leifmadsen | LOCK |
| 18:09.28 | otherwiseguy | eh. on the dnsmgr stuff, even with the callback version we need to pass in the addr because we use it as a filter for the address family. But, leaving it in makes updating things easier anyway. |
| 18:28.37 | *** join/#asterisk-dev aimka (~aimka@unaffiliated/aimka) |
| 18:28.39 | *** join/#asterisk-dev moy (~moy@216.172.42.74) |
| 18:29.11 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 18:43.22 | anonymouz666 | what's the impact about the audit of ao2_iterator_init() for v1.8? this could prevent some misbehavior? |
| 18:57.27 | *** join/#asterisk-dev goddva (~glarsen@cm-84.209.37.238.getinternet.no) |
| 18:59.20 | Qwell | yes |
| 19:02.08 | seanbright | almost made it into the release |
| 19:02.12 | seanbright | was *this* close |
| 19:07.11 | Corydon76-home | kpfleming: I always enjoy pleasing the comment. |
| 19:12.45 | russellb | o.O |
| 19:17.39 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 19:20.08 | seanbright | will richard's ao2 fixes make it into 1.8.9.0 and 10.1.0? |
| 19:25.00 | mjordan | seanbright: no. |
| 19:25.04 | mjordan | :-) |
| 19:25.12 | seanbright | yeesh |
| 19:25.13 | seanbright | ok |
| 19:25.36 | *** join/#asterisk-dev Crowb4r (u1012@gateway/web/irccloud.com/x-bbfeksmvamabwcic) |
| 19:25.45 | mjordan | they will be in 1.8.10.0 and 10.2.0 |
| 19:25.52 | seanbright | gotcha |
| 19:28.35 | leifmadsen | actually 1.8.10.0-rc1 :) |
| 19:28.38 | leifmadsen | and 10.2.0-rc1 |
| 19:29.59 | leifmadsen | 1.8.9.0 was just a copy of rc1 if I'm paying attention enough |
| 19:33.30 | mjordan | 1.8.9.0 went up to -rc3 |
| 19:34.15 | leifmadsen | then I'm not paying attention enough |
| 19:34.48 | russellb | leifmadsen: slacker |
| 19:38.14 | *** join/#asterisk-dev Tim_Toady (~fuzzy@77.49.108.33.dsl.dyn.forthnet.gr) |
| 20:01.14 | putnopvut | seanbright: most of richard's fixes were container refleak fixes for long-lived containers like the channels container. They're not really that big. The thing is, he's doing the audit because he's going to be making some changes in trunk to support red-black trees in ao2 containers. The changes he's making require that these types of holes be patched because they'll lead to some bad memory leaks when he's through. |
| 20:02.28 | leifmadsen | ...lead to some bad memory leaks when he's through if he doesn't fix them up |
| 20:02.29 | leifmadsen | :) |
| 20:02.42 | russellb | what's driving the new data structure |
| 20:03.30 | putnopvut | An ordered container type. I have no idea what he actually wants to use it for specifically. He's working on it on his own time. |
| 20:04.05 | kpfleming | there are multiple places where an ordered container would be useful |
| 20:04.40 | putnopvut | Yep, I'm not sure if there's a specific place he wants to use it though is all I'm saying. |
| 20:04.54 | kpfleming | right |
| 20:05.00 | kpfleming | bets on chan_dahdi |
| 20:05.05 | putnopvut | Probably :) |
| 20:05.28 | putnopvut | I think this might be the step that would allow us to get rid of ASTOBJ altogether, if we so pleased. |
| 20:06.53 | kpfleming | we do, we do! |
| 20:06.54 | opticron | drools |
| 20:07.18 | russellb | he should make purple/pink trees instead |
| 20:07.56 | putnopvut | As long as they're glittery I don't care what colour they are. |
| 20:08.01 | putnopvut | oh god I typed "coulour" |
| 20:08.47 | kpfleming | you did? |
| 20:09.05 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:09.05 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:12.49 | wedhorn | WIMPy: may as well, while the old firmware may not work, shouldn't be able to core dump |
| 20:16.06 | WIMPy | http://wimpy.yeti.dk/pastebin |
| 20:19.29 | wedhorn | WIMPy: actually I know about that crash. If a device unregisters while a call exists, nasty things happen. |
| 20:20.04 | wedhorn | WIMPy: check your TFTP log, it asks for a filename shorter than the actual filename, so you need a link or rename |
| 20:24.28 | WIMPy | Hmm. It tries an unknown IP. Whereever that comes from. |
| 20:28.35 | WIMPy | Hmm. Tried to configure the network settings manually, but that doesn;t seem to make a difference. I guess I will just assign that IP to the server. |
| 20:30.10 | wedhorn | or you could set the tftp server in dhcp |
| 20:30.45 | wedhorn | actually, I don't know whether that would work for older firmware |
| 20:33.18 | WIMPy | Well, it does request the config from the right tftp server, but the firmware is requested from elsewhere. |
| 20:34.39 | wedhorn | That sounds strange. Does the config point somewhere else? |
| 20:34.54 | WIMPy | No. Only to itself. |
| 20:35.04 | WIMPy | Ok, It's programming now. |
| 20:36.04 | wedhorn | Suppose that's what happens when you're playing with software that EOL'd a decade ago ;) |
| 20:36.23 | WIMPy | Possibly |
| 20:37.04 | WIMPy | It works! |
| 20:37.18 | WIMPy | For multiple calls that is :-) |
| 20:37.25 | WIMPy | Thanks a lot! |
| 20:37.33 | tzanger | kpfleming: If I were to be able to add ARINC 746 support to libpri in an unencumbered way, would that be a welcome patch? |
| 20:37.40 | WIMPy | Now it can do more than just look important :-) |
| 20:38.45 | wedhorn | WIMPy: no probs, though I'm not sure everyone else shares your thoughts of the importance of a 30vip |
| 20:39.09 | WIMPy | I said LOOK important. |
| 20:39.49 | wedhorn | if you really want to look cool, I've a Selsius 30SP+ |
| 20:42.35 | WIMPy | Isn;t that the same thing? |
| 20:43.38 | wedhorn | At first glance, but it's got no power jack, and a 6 pin ethernet/power connector (and of course, no cisco logos) |
| 20:44.30 | WIMPy | The Lable on mine even says MODEL NUMBER: PHONE 12SP+/30VIP |
| 20:45.33 | wedhorn | yeah, but this says "Selsius Systems" at the top, and "30SP+" at the bottom |
| 20:48.23 | WIMPy | Cool. Transfer works. But accepting a second call results in garbeled audio. |
| 20:49.31 | wedhorn | the second call is simultaneous or afterwards? |
| 20:49.45 | WIMPy | Simultaneous. |
| 20:50.23 | WIMPy | I can place a second call from the phone wile another one is up and do a transfer. No getting back to the first call, however. |
| 20:50.52 | WIMPy | But if a second call comes in and I press the line button I seem to get a mix of both calls. |
| 20:51.04 | wedhorn | okay, I've got my 30VIP set to callwaiting=no, so I don't have multiple calls |
| 20:51.49 | WIMPy | Erm, now that you mention it, I've set both callwaiting=no and transfer=no. |
| 20:51.50 | wedhorn | ah yes the line button. Not really used on the new devices so it's probably been overlooked |
| 20:52.09 | WIMPy | But the second call makes the button blink. |
| 20:52.21 | WIMPy | And transfer works. |
| 20:52.22 | wedhorn | okay, so ignoring the config too, cool >:-| |
| 20:52.45 | WIMPy | I try with both set to yes. |
| 20:54.45 | WIMPy | The only difference is a beep for the waiting call. |
| 20:55.21 | WIMPy | But it leaves stuck channels. |
| 20:56.51 | wedhorn | yeah, I'll have to look at it. So individual calls work. Transfer not so much. How about using the line button when you're on a call? |
| 20:57.21 | WIMPy | No, transfer works. |
| 20:57.40 | WIMPy | Just activated a second line to try. |
| 20:59.02 | WIMPy | No, it doesn't matter if it's another line. |
| 20:59.34 | wedhorn | So answering a call on the second line will causes garbled audio? |
| 20:59.44 | WIMPy | yes |
| 21:00.00 | wedhorn | how about if you press hold before pressing the line button? |
| 21:01.09 | WIMPy | Hold has no effect |
| 21:02.23 | WIMPy | Eeeks. I can only accept a call for the line I used last. |
| 21:03.03 | wedhorn | How about if you press the line button? |
| 21:03.30 | WIMPy | Ok, without a waiting call, HOLD puts the call on hold. But pressing the other line button retrieves the call instead of starting a new call. |
| 21:04.48 | wedhorn | okay, seems like we need some cleaning up of the channel select function |
| 21:05.11 | WIMPy | If I used line 2 last and a call arrives on line 1, I get a dialtione when lifting the receiver. Pressing the line buttons doesn't make a difference any more. |
| 21:05.42 | WIMPy | Ok, so always accept calls by pressing the blinking button. That works. |
| 21:05.59 | WIMPy | This is really some interesting stuff. |
| 21:06.09 | WIMPy | Lots of weired behaviour. |
| 21:06.42 | wedhorn | well its been pretty much ignored for probably 2 or 3 years worth of coding chan_skinny |
| 21:07.16 | wedhorn | My tests on the 30vip were pretty much limited to make a call, receive a call, all on a single line setup |
| 21:07.23 | WIMPy | Well, I can see that noone is interested in that old thing. |
| 21:08.48 | wedhorn | As I said earlier, I only actually disconnected it from my network a couple weeks ago. Thought it was worth keeping chan_skinny at least sort of working. |
| 21:09.06 | wedhorn | The fixes should be fairly trivial |
| 21:11.10 | WIMPy | Sometimes there's a glitch starting a call resultion in a screen full of Prodding channel ... failed. |
| 21:11.22 | kpfleming | tzanger: i have no idea what ARINC 764 is |
| 21:11.25 | WIMPy | But it works again on the next try. |
| 21:11.30 | kpfleming | or 746 |
| 21:11.55 | wedhorn | WIMPy: I've never seen that |
| 21:15.28 | jsmith | kpfleming: If it makes you feel any better, I have no clue either :-( |
| 21:21.08 | wedhorn | WIMPy: after line 5269 (l->activesub = sub;) add "d->activeline=l;" and you'll be able to answer either line without using the line buttons |
| 21:24.20 | malcolmd | that's ARINC 746, i believe |
| 21:24.47 | jsmith | malcolmd: Still have no clue what it is -- can you give me the nickel tour? |
| 21:25.10 | malcolmd | wikipedia says: ARINC 746 is the standard for a cabin telecommunications unit, based on Q.931 and CEPT-E1. i'm not clear on what makes it "special" though |
| 21:25.14 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:25.14 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 21:27.35 | WIMPy | wedhorn: yes, that works. |
| 21:30.23 | wedhorn | most of it will be really small stuff like that. Just small oversights. |
| 21:30.55 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.63.44.50) |
| 21:33.11 | WIMPy | Well, if you know how the whole thing works... |
| 21:34.00 | wedhorn | yeah, sort of a prerequisite |
| 21:36.30 | WIMPy | The bad thing is that I suspect I might like SCCP if it was open. |
| 21:37.05 | wedhorn | the protocol or the channel driver? |
| 21:37.16 | WIMPy | The protocol. |
| 21:37.30 | WIMPy | Can't say much about chn_skinny. |
| 21:38.27 | wedhorn | yeah. bit of a bummer that it's not. But a fair bit of it is known, we just can't mod the firmware on the devices |
| 21:39.28 | WIMPy | Yeah, but "is known" is not something that I like to rely on. |
| 21:41.33 | wedhorn | granted, but a bit of firmware doesn't change itself, so once we work out the message, they become reliable |
| 21:42.04 | WIMPy | Yes, but you never know what happens on the next version. |
| 21:42.31 | wedhorn | the main issue is trying to maintain workability across various versions of the firmware, or more specifically, the physical devices (eg difference between a 30vip and a 7960) |
| 21:42.46 | wedhorn | But we can just ignore the next version |
| 21:44.18 | WIMPy | Sure, but that's not an ideal situation. |
| 21:46.02 | wedhorn | But it's the same issue with any sort of firmware unless you've got the code and can build your own firmware |
| 21:46.30 | WIMPy | Or you have a specification. |
| 21:48.42 | wedhorn | Yeah sure, name the bit of firmware that is fully compliant with a spec |
| 21:49.52 | WIMPy | Well, not every company prefers to document bugs instead of fixing them. |
| 21:49.53 | wedhorn | The issue I suppose is that the skinny spec (all the known stuff) is in people's heads. |
| 21:52.26 | wedhorn | Also, since v3 of ccm (protocol v0), there hasn't been a lot of change. protocol v17 added ip6 but generally there's backward compatibility |
| 21:53.10 | wedhorn | eg activate_callplane pops up the callplane on 79xx phones and is ignored by 30vip's |
| 21:53.46 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:53.46 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 21:56.50 | wedhorn | The biggest issue is actually trying to fit within the asterisk philosophy (ie cross device compatibility). A lot of the skinny protocol is ccm specific and isn't compatible with asterisk |
| 21:58.47 | WIMPy | Just like the POTS of the last 20 years, AKA ISDN. |
| 21:59.53 | wedhorn | yeah, quite probably (not familiar with it) |
| 22:04.49 | WIMPy | Err, s/POTS/PSTN/ off course. |
| 23:44.16 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.63.44.50) |
| 23:56.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |