| 00:04.19 | *** join/#asterisk-dev sysreq (n=sysreq@unaffiliated/sysreq) |
| 00:25.56 | *** part/#asterisk-dev korihor (n=korihor@201.210.239.172) |
| 01:10.32 | *** join/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 01:11.20 | *** part/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 01:12.02 | *** join/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 01:40.12 | *** join/#asterisk-dev mog (n=mog@c-68-62-172-152.hsd1.al.comcast.net) |
| 01:40.12 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 02:59.59 | *** join/#asterisk-dev outtolunc (n=me@c-67-188-204-139.hsd1.ca.comcast.net) |
| 03:23.24 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 03:23.24 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:41.41 | *** join/#asterisk-dev xpot (n=jim@67.222.236.132) |
| 04:06.59 | seanbright | file: did you find yourself looking at the word 'bridge' and thinking it was spelled wrong? |
| 04:07.05 | seanbright | or is that just me? |
| 04:07.41 | file | it got to that point, yes |
| 04:08.07 | seanbright | i'm halfway through bridging.c and it's already happened to me |
| 04:12.29 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 04:12.29 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:20.39 | file | seanbright: would you like a bridge with that? |
| 04:20.45 | file | waves to sruffell |
| 04:21.19 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 04:22.33 | seanbright | file: reviewed. wasn't even going to bother with my 1 comment, but i guess reviewboard is there for a reason. |
| 04:23.17 | file | thank you! |
| 04:23.34 | seanbright | yup |
| 04:23.59 | seanbright | keep in mind you could have a bunch of huge architectural problems in there, but i wouldn't notice them if you did :) |
| 04:24.10 | seanbright | so... ship it! heh |
| 04:24.23 | file | it is possible, but this has gone through enough rewrites I think it is safe |
| 04:24.30 | file | but! we shall see |
| 04:27.10 | seanbright | we should find a way to link api calls in reviewboard to the doxygen stuff |
| 04:27.31 | seanbright | so i could click on ast_stream_and_wait to go to it's documentation |
| 04:27.50 | seanbright | and by 'we' i mean 'someone who is not me' |
| 04:27.57 | file | naturally |
| 04:33.57 | seanbright | 'native bridging' is just SIP-SIP or IAX2-IAX2 right? |
| 04:34.09 | file | yeah |
| 04:34.39 | seanbright | what does it buy you? |
| 04:34.46 | seanbright | tech specific features? |
| 04:34.51 | file | it can be more efficient |
| 04:34.58 | file | in the case of RTP it can push the audio off the box :) |
| 04:35.05 | seanbright | right |
| 04:35.29 | seanbright | is that what packet2packet bridging is? |
| 04:35.39 | file | Packet2Packet exchanges the RTP packets within the RTP stack |
| 04:35.48 | file | so they do not traverse the bridge, which means less memory allocations |
| 04:35.58 | file | less CPU cycles required |
| 04:36.16 | seanbright | gotcha. and what uses RTP besides SIP? |
| 04:36.25 | file | Skinny, MGCP, H323 |
| 04:39.08 | seanbright | oh i see... found a -users message where you explained the difference between P2P and native |
| 04:39.43 | seanbright | does P2P still allow the audio stream to be manipulated/captured by asterisk? |
| 04:39.55 | file | no |
| 04:40.00 | file | that requires going through the core |
| 04:40.03 | seanbright | sorry for the nub questions, btw :) |
| 04:40.20 | file | well thought out questions get answers |
| 04:41.04 | seanbright | so when you have two channels that are P2P, and you start a monitor on one of the channels, we soft hangup and bring the audio into the core |
| 04:41.13 | file | correct |
| 04:41.26 | file | we break the native bridge. |
| 04:41.58 | seanbright | and it stays that way for the remainder of the bridge? |
| 04:42.38 | file | yes, although I suppose if you removed whatever caused the bridge to break... and got it to retry... it would native bridge |
| 04:42.55 | file | speaking from the perspective of the current bridging architecture. |
| 04:43.08 | seanbright | right. but for most use cases, it's probably not worth it. |
| 04:43.29 | file | shrugs |
| 04:43.36 | seanbright | well that's interesting. |
| 04:44.12 | seanbright | thanks for the edumacation :) |
| 04:44.19 | file | I have not quite hashed out mentally how I want to do native bridging within the new architecture |
| 04:45.53 | seanbright | well don't look at me! ;) |
| 04:46.48 | file | stares at seanbright |
| 04:48.31 | seanbright | eep |
| 04:53.51 | seanbright | so if you have 2 sip users/peers that are reinvitable, and there is nothing manipulating the audio, it would always be native, right? |
| 04:54.03 | seanbright | p2p would only be used when you couldn't reinvite |
| 04:54.27 | file | native if something doesn't need the audio, codecs are the same, and it is allowed |
| 04:54.38 | file | p2p if something doesn't need the audio, codecs are the same |
| 04:54.40 | file | core otherwise |
| 04:54.51 | seanbright | gotcha |
| 04:54.54 | file | in that order with core being chosen last |
| 04:55.11 | seanbright | "and it is allowed" other than reinvite (in the case of SIP) are there other conditions as well? |
| 04:55.17 | seanbright | i can go to the code for that part i assume. |
| 04:55.20 | file | nope |
| 04:55.57 | seanbright | how long have you been involved with asterisk? |
| 04:56.11 | file | awhile. |
| 04:56.17 | seanbright | that long? |
| 04:56.18 | seanbright | crazy |
| 04:56.22 | seanbright | :P |
| 04:57.39 | seanbright | what did you do before asterisk? |
| 04:57.48 | file | high school! |
| 04:58.19 | seanbright | ugh |
| 04:58.26 | seanbright | way to make me feel old |
| 04:58.28 | seanbright | -er |
| 04:58.49 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 05:28.51 | Corydon76-dig | Hrm. |
| 05:28.57 | Corydon76-dig | file: don't look at me! |
| 06:45.33 | Juggie | entirely off topic but if anyone is looking for a lcd tv |
| 06:45.47 | Juggie | costco.com is running a couple of really good deals, though i imagine boxing day is going to be better |
| 08:48.23 | *** join/#asterisk-dev brookshi1e (n=mbrooks@hijacked.us) |
| 09:19.52 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.7) |
| 10:15.50 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 10:44.19 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 10:44.19 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:17.48 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:27.40 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 12:34.54 | *** join/#asterisk-dev DarkRift (n=dark@bas1-sthubert21-1096591606.dsl.bell.ca) |
| 12:54.45 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 13:03.32 | *** join/#asterisk-dev sasargen (n=chatzill@174-152-32-136.pools.spcsdns.net) |
| 13:13.55 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 13:13.55 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:20.09 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.130.105) |
| 13:27.54 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:41.54 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:41.54 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:47.20 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:51.16 | seanbright | russellb: are you not part of the asterisk-dev reviewboard group? |
| 13:52.53 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 13:52.53 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 13:57.37 | russellb | I am |
| 13:57.48 | russellb | but on the dashboard, you can view just ones for you |
| 13:57.58 | russellb | so I like to add myself to ones that I want to make sure I watch closely |
| 13:58.07 | russellb | maybe I should use the star thingy for that ... |
| 14:24.16 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-ddb0112a348b0bba) |
| 14:24.16 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:28.16 | codefreeze-lap | lmadsen: jsmith: did you guys know that '-' and space in a pattern are ignored, at least as far as pattern sorting is concerned? |
| 14:28.21 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.6) |
| 14:28.31 | jsmith | codefreeze-lap: Actually, I did. |
| 14:28.40 | jsmith | codefreeze-lap: (well, at least as far as the - is concerned) |
| 14:28.58 | codefreeze-lap | jsmith: Does that make sense to you? |
| 14:29.04 | jsmith | codefreeze-lap: Unfortunately, support for hyphens in patterns hasn't always been robust, so I've taught people not to use them |
| 14:29.16 | jsmith | codefreeze-lap: Yeah... it does, actually |
| 14:29.20 | jsmith | codefreeze-lap: Imagine this: |
| 14:29.34 | jsmith | _9-1-NXX-NXX-XXXX |
| 14:29.44 | jsmith | Isn't that easier to read than _91NXXNXXXXXX |
| 14:29.55 | jsmith | (especially for making sure you have the proper number of Xs) |
| 14:30.51 | codefreeze-lap | ahhhhhhhh! |
| 14:31.24 | jsmith | codefreeze-lap: Oh? |
| 14:31.42 | codefreeze-lap | Well, 14076 |
| 14:32.17 | codefreeze-lap | I see the code, but I couldn't for the life of me understand why its there! Now I see. Ahhhhh.... |
| 14:33.07 | lmadsen | hmmm... but there are so many examples of s-NOANSWER, s-BUSY, etc... |
| 14:33.19 | lmadsen | what... |
| 14:33.37 | lmadsen | if we made it so you needed something around the - to tell asterisk that you really mean to use it? |
| 14:33.57 | lmadsen | s[-]NOANSWER is ugly though.... |
| 14:34.07 | mvanbaak | please dont do that |
| 14:34.13 | lmadsen | and could be confusing when used withs omething like _N[2-7]XX |
| 14:34.16 | russellb | why would that be needed? |
| 14:34.22 | codefreeze-lap | They'll work OK, because sBusy and S-Busy are part of a pattern that doesn't hinge on the position of the - |
| 14:34.35 | codefreeze-lap | and dashes in patterns are NOT ignored |
| 14:34.49 | jsmith | codefreeze-lap: Oh? |
| 14:35.07 | lmadsen | they are right now when you try to match on _s-. and _s. |
| 14:35.15 | jsmith | lmadsen: They shouldn't be |
| 14:35.30 | lmadsen | they are |
| 14:35.33 | lmadsen | I just tested yesterday |
| 14:35.35 | jsmith | lmadsen: They might be ignored for *pattern ordering*... but they shouldn't be completely ignored |
| 14:35.56 | lmadsen | ok... maybe that is how it worked... but _s. took precendent over _s-. |
| 14:35.59 | lmadsen | which is unexpected |
| 14:36.00 | codefreeze-lap | yes, _s-. and _s. are the same to the code |
| 14:36.25 | codefreeze-lap | no, the *first* one wins |
| 14:36.30 | lmadsen | yuck |
| 14:36.38 | lmadsen | so order *does* matter in some instances |
| 14:36.41 | lmadsen | now that's fun to teach |
| 14:36.43 | codefreeze-lap | the next one is a repeat and tossed out |
| 14:36.48 | lmadsen | even worse |
| 14:37.05 | lmadsen | that makes sense why I didn't see the 4 matches I created the other day |
| 14:37.06 | lmadsen | only the 3 |
| 14:37.14 | lmadsen | has this always been in the case? |
| 14:37.16 | lmadsen | even in 1.4? |
| 14:37.24 | jsmith | lmadsen: As far as I know |
| 14:37.45 | lmadsen | ok, so is the vote to change the behaviour, or just document it? |
| 14:37.48 | codefreeze-lap | yes, it's been there since day 1 (at least, when the 'new' matching rules were merged about 2.5 years ago |
| 14:38.01 | lmadsen | wow, surprised no one has run into this before |
| 14:38.31 | codefreeze-lap | In the code, it is pretty clearly documented, but it doesn't say *why*. |
| 14:38.42 | lmadsen | that doesn't help end-users |
| 14:39.05 | codefreeze-lap | Personally, I disagree with it, but I can see the value of ignoring them in stuff like NXX-XXX-XXXX or whatever |
| 14:39.34 | lmadsen | agreed... I can see it as a feature, but this all has to be clearly documented for end-users |
| 14:39.47 | lmadsen | this would be a great article for asteriskdocs.org |
| 14:39.50 | lmadsen | ducks :) |
| 14:40.34 | codefreeze-lap | watches lmadsen make mental note to stop expressing great new ideas that make him more work! |
| 14:40.38 | lmadsen | M14088 |
| 14:40.40 | MuffinMan | [acknowledged] [Asterisk] Channels/chan_sip/General 0014088: Problem with matching incoming calls on sip friend reported by jsmith (Karma: +30.25) http://bugs.digium.com/view.php?id=14088 |
| 14:40.47 | lmadsen | oops... wrong bug :) |
| 14:40.53 | codefreeze-lap | M14076 |
| 14:40.55 | MuffinMan | [acknowledged] [Asterisk] Core/PBX 0014076: Extensions configuration is not being sorted correctly reported by toc (Karma: neutral) http://bugs.digium.com/view.php?id=14076 |
| 14:42.37 | lmadsen | thx |
| 14:43.17 | lmadsen | ok, so... with that bug... do we document, or make a change to code? If this has been like this for quite some time, I guess just documenting the behaviour would make the most sense? |
| 14:43.26 | lmadsen | if that is the case, I'm willing to have that bug assigned to me |
| 14:43.56 | lmadsen | oops |
| 14:43.58 | lmadsen | wrong bug |
| 14:44.01 | codefreeze-lap | I'd personally love to get rid of these exceptions. But, most likely there's a ton of stuff that depends on this behavior |
| 14:44.09 | lmadsen | M14023 |
| 14:44.10 | MuffinMan | [feedback] [Asterisk] Channels/chan_dahdi 0014023: UK caller ID on X100P, not working reported by coops (Karma: neutral) http://bugs.digium.com/view.php?id=14023 |
| 14:44.10 | lmadsen | I meant that bug |
| 14:44.23 | lmadsen | codefreeze-lap: fair enough... I think we should just document the behaviour and close it |
| 14:44.37 | codefreeze-lap | Will do. |
| 14:44.42 | lmadsen | I can do that this afternoon. I can update extensions.conf.sample and something in doc/ |
| 14:46.50 | *** join/#asterisk-dev sysreq (n=sysreq@unaffiliated/sysreq) |
| 14:49.47 | *** join/#asterisk-dev BlargMaN00 (n=blarg@12.234.16.130) |
| 14:50.51 | lmadsen | ok, I have saved this conversation to smultron and will use it as the basis of some documentation when I get back from the gym |
| 15:03.55 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-d17fc5d2c76d8042) |
| 15:03.55 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:08.39 | *** join/#asterisk-dev tzafrir (n=tzafrir@local.xorcom.com) |
| 15:08.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:11.33 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:21.04 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.111) |
| 15:31.38 | *** join/#asterisk-dev bbryant (n=Brett_Br@adsl-068-016-200-248.sip.chs.bellsouth.net) |
| 15:31.38 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 15:34.52 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-ef3c751d3b1dadb0) |
| 15:34.52 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:41.53 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 15:44.18 | *** join/#asterisk-dev kerframil (n=kerframi@gentoo/user/kerframil) |
| 16:01.34 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-3524389fe33865b7) |
| 16:01.34 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:05.00 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 16:10.59 | *** join/#asterisk-dev linuxer_igor (n=linuxer_@mlsrj200152096p202.mls.com.br) |
| 16:12.57 | *** join/#asterisk-dev qdk (n=qdk@94.191.241.11.bredband.3.dk) |
| 16:16.49 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 16:45.31 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:46.17 | codefreeze-lap | jsmith: lmadsen: the code says, that you should not use _. as a pattern; that you might get unexpected results.... but it doesn't give any examples... lol... how about matching the 'h', 'i', etc extensions? |
| 16:49.18 | jsmith | codefreeze-lap: Well, because of the sort order in 1.2, '_.' would match even before an exact match |
| 16:49.38 | jsmith | codefreeze-lap: Not only that, it would match 'h', 'i', etc. as well, as I recall |
| 16:49.42 | Qwell | mmhmm |
| 16:49.44 | Qwell | and others |
| 16:50.37 | codefreeze-lap | I call getting the 'fax' extension when no fax is calling, 'unexpected'... lol |
| 16:51.39 | codefreeze-lap | but, I think having your exten fired up as the hangup is probably more probable... |
| 16:52.53 | jsmith | Yeah... fax should only be triggered by fax tones (or maybe by T.38 negotiation, based on a recent otherwiseguy patch?) |
| 17:23.05 | lmadsen | codefreeze-lap: you are correct (as is jsmith, which does not surprise me :)) basically sort order is something like: _. 1st, followed by most specific after that |
| 17:24.01 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.17) |
| 17:25.00 | codefreeze-lap | lmadsen: jsmith: more curious: although ' ' and '-' are ignored in scoring, they are NOT ignored in matching! Interesting: the current algorithm, if you define exten 8-9-1, will match 8-9-1, but NOT 891. |
| 17:26.05 | lmadsen | codefreeze-lap: oic... that makes sense then why this would work then: |
| 17:26.14 | lmadsen | exten => 202,1,Goto((519) 555-1212,1) |
| 17:26.14 | lmadsen | exten => _(NXX)[ ]NXX-XXXX,1,Verbose(2,Made it!) |
| 17:27.06 | lmadsen | hmmm... so basically _NXX-XXXX and _NXXXXXX are the same, but if you ONLY have _NXX-XXXX it will match on 591-5119 ? |
| 17:27.11 | lmadsen | but not 5915119 ? |
| 17:28.02 | codefreeze-lap | well, if 8-9-1 doesn't match 891, then why.... ignore... dashes in the scoring? what good does it do? Just confuse you when you can't define 8-9-1 and 891 in the same context? |
| 17:28.30 | lmadsen | I would agree with that... |
| 17:28.32 | jsmith | throws up his hands and says "I give up! It doesn't make sense!" |
| 17:28.41 | lmadsen | throws up |
| 17:28.43 | lmadsen | . |
| 17:29.05 | codefreeze-lap | old chinese proverb: is it better to give up than throw up? |
| 17:29.25 | lmadsen | not if you ate something poisonous |
| 17:29.32 | denon | heh, I was just thinking that too |
| 17:29.45 | denon | 'course, I'm just getting over a stomach flu, I'm biased |
| 17:30.06 | codefreeze-lap | well, then, it is better not ingest hands in first place, rather than throw them up in digust! |
| 17:31.09 | lmadsen | lol |
| 17:35.45 | codefreeze-lap | OK, so, if we can't define 8-9-1 and 891 in the same context, and current behavior says 8-9-1 doesn't match 891; then I say, get rid of the distinction. It isn't consistent as it is... |
| 17:36.14 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 17:37.00 | lmadsen | exten => 8-9-1 == exten => 891 in the same context right? This isn't just pattern matches where the hyphen is stripped? |
| 17:37.04 | lmadsen | it is all extensions? |
| 17:37.47 | lmadsen | has somewhere gotten part of this conversation confused ;) |
| 17:38.04 | lmadsen | hey! today is payday and I didn't even know it :) |
| 17:38.41 | codefreeze-lap | lmadsen: you cant define 8-9-1 and 891 in the same context, because the algorithm ignores the dashes... but, if you define 8-9-1, you will not match 891 |
| 17:38.57 | lmadsen | ok, then I was partially correct |
| 17:39.00 | lmadsen | thank you for clarifying |
| 17:39.16 | codefreeze-lap | and if you define 891, it will not match the dialstring "8-9-1" |
| 17:39.37 | lmadsen | so only when you define both, does the algorithm get "confused" and say, "this is a dupe"? |
| 17:40.10 | codefreeze-lap | yep, and kicks out any conflicts after the first gets put into the tree. |
| 17:40.12 | lmadsen | so for example... could we match on both of those separate if we put them in separate contexts, then include => them in a [master] context? |
| 17:40.33 | codefreeze-lap | I think so. |
| 17:40.51 | lmadsen | [master] |
| 17:40.51 | lmadsen | include => one |
| 17:40.51 | lmadsen | include => two |
| 17:40.51 | lmadsen | [one] |
| 17:40.51 | lmadsen | exten => 8-9-1... |
| 17:40.52 | lmadsen | [two] |
| 17:40.56 | lmadsen | exten => 891 |
| 17:41.09 | lmadsen | hmmm... that is a test for me to try |
| 17:41.31 | lmadsen | that is a highly confusing rule though :) |
| 17:41.39 | codefreeze-lap | You think anybody would do that? If I strip out that condition from the add_extension code, would anyone get bitten? |
| 17:42.41 | lmadsen | hmmm... anything is possible when it comes to dialplan matching. But you are talking about stripping it out so that even in matching, the 8-9-1 would actually be 891 ? |
| 17:42.49 | lmadsen | i.e. dashes are ALWAYS ignored? |
| 17:43.15 | lmadsen | I can see that biting a lot of people who have s-BUSY and s-NOANSWER, etc... |
| 17:43.16 | codefreeze-lap | no, it would just allow you to define 8-9-1 and 891 in the same exten |
| 17:43.20 | lmadsen | aha |
| 17:43.28 | lmadsen | yes, I would agree that would be a better route... |
| 17:43.39 | lmadsen | I don't know why anyone would be expecting dashes to be stripped? |
| 17:44.06 | lmadsen | unless they had independently found that was how the dialplan worked, then decided to start using it for something... |
| 17:44.58 | lmadsen | my gut instinct is that if you make it so 8-9-1 and 891 can be defined in the same context, it shouldn't hurt anyones dialplan, and if it does, it'll be a VERY VERY tiny percentage |
| 17:45.16 | codefreeze-lap | I guess the guys who were hoping that - wouldn't matter, went the master-one-two route; such a change as I propose would not hurt them. |
| 17:45.34 | lmadsen | aye |
| 17:45.56 | codefreeze-lap | and the rest of the world would just have the unexpected NOT happen. |
| 17:45.59 | lmadsen | so I guess if you make that change, I don't need to write the documentation anymore eh? |
| 17:46.09 | lmadsen | I'm in agreement |
| 17:46.14 | lmadsen | jsmith: can we get you onboard? |
| 17:46.39 | codefreeze-lap | I guess... I'll remove the test in the code, and the verbage around it. Is there verbage about it at all in the sample stuff? |
| 17:46.51 | jsmith | lmadsen: Naw... I haven't grokked the changes you're proposing yet |
| 17:47.13 | jsmith | lmadsen: Can someone send me an email (or even better, to the -dev list) with the proposed change(s)? |
| 17:47.17 | jsmith | goes back to teaching |
| 17:47.23 | lmadsen | that's not a bad idea |
| 17:47.33 | russellb | in fact, i would even call it good |
| 17:47.43 | lmadsen | maybe someone who knows why the way the code is the way it is can speak up :) |
| 17:47.49 | lmadsen | russellb: I wouldn't go THAT far |
| 17:47.51 | lmadsen | :D |
| 17:48.06 | lmadsen | codefreeze-lap: would you prefer I write it, or you? |
| 17:48.12 | codefreeze-lap | OK, sure, I'll send out something out as fast as my non-nimble fingers can type it up. |
| 17:48.19 | lmadsen | I guess that means you :) |
| 17:48.27 | lmadsen | thank you sir! |
| 17:48.37 | codefreeze-lap | Sorry, I had already typed all that in, and didn't want to revise it |
| 17:48.42 | lmadsen | heh |
| 17:49.06 | lmadsen | another question: is this considered a bug, or a feature enhancement? |
| 17:49.10 | lmadsen | i.e. does this go into 1.4? |
| 17:51.24 | lmadsen | codefreeze-lap watches lmadsen make mental note to stop expressing great new ideas that make him more work! |
| 17:51.29 | lmadsen | heh... I never saw that earlier |
| 17:51.46 | seanbright | hmmm, is there any way to generate a temporary variable name in a preprocessor macro? |
| 17:51.53 | seanbright | instead of using a fixed one |
| 17:52.16 | russellb | not sure what you mean |
| 17:52.30 | putnopvut | instead of having "typeof(x) __x__ |
| 17:52.32 | putnopvut | " |
| 17:52.43 | putnopvut | Have like "typeof(x) XghsWI" ? |
| 17:52.53 | putnopvut | Where the name was generated randomly? |
| 17:52.55 | seanbright | #define FOO do { char {$randomvarhere} = 'h'; ... } while(0); |
| 17:53.01 | seanbright | yes |
| 17:53.08 | russellb | sort of, but not really. |
| 17:53.44 | seanbright | well i am trying to revive the shadow warnings stuff, and it doesn't like stuff like S_OR(something, S_OR(else, foobar)) |
| 17:53.45 | russellb | you can do ... #define FOO(x) do { char __foo_##x ; } |
| 17:54.00 | seanbright | ohhh |
| 17:54.01 | russellb | where you use the argument name as part of the variable name |
| 17:54.33 | russellb | that makes it different, but not random :-) |
| 17:54.36 | seanbright | right. |
| 17:54.46 | seanbright | different should be sufficient |
| 17:54.56 | russellb | coolio |
| 17:55.31 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 17:55.43 | codefreeze-lap | lmadsen: speaking of not spotting something....looking at 14076; I put in my comment without updating the bug (who on earth would add anything?), so I just repeated what you said... duh |
| 17:56.06 | lmadsen | codefreeze-lap: I think we wrote the same thing at the same time |
| 17:56.40 | lmadsen | especially since our postings were only 3 mins apart |
| 18:02.29 | lmadsen | ugh... way too many email distractions, but at least I'm through them now |
| 18:05.02 | *** join/#asterisk-dev jsolis (n=jimmy@200.121.160.48) |
| 18:14.00 | *** join/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 18:14.34 | putnopvut | I'm trying to wrap my head around some code I haven't really examined much before, and there's something that just seems really wrong. |
| 18:14.58 | putnopvut | in the function ast_sip_ouraddrfor, there is a call to ast_apply_ha, with the second parameter being a pointer to an uninitialized struct sockaddr_in. |
| 18:15.24 | putnopvut | Reading the code, it really seems like the second parameter was meant to be initialized prior to that call. |
| 18:15.41 | putnopvut | oops, my mistake. |
| 18:15.48 | putnopvut | Glad I typed it out here. It is initialized. |
| 18:18.00 | putnopvut | But that code is still really weird to me, since the struct ast_ha localaddr only has "deny" rules, and so I don't see how ast_apply_ha with localaddr as a parameter could return AST_SENSE_ALLOW. |
| 18:25.34 | *** join/#asterisk-dev kerframil (n=kerframi@gentoo/user/kerframil) |
| 18:26.16 | putnopvut | I'm not sure whether I need to stop typing stuff in here or not. As soon as I type out how I don't understand something, it all of a sudden hits me how it works. But then again, I come off to the channel as being kind of slow :) |
| 18:26.46 | seanbright | if you're slow, then i'm completely retarded. |
| 18:27.17 | seanbright | <crickets> |
| 18:41.53 | Corydon76-dig | seanbright: way to kill the conversation, retard. j/k |
| 18:43.13 | Corydon76-dig | putnopvut: that happens to all of us. The process of trying to explain what you don't understand sometimes helps you to understand |
| 18:43.33 | codefreeze-lap | lmadsen: ugh. It's getting more complicated! 1.4 and trunk do NOT act the same as far as 8-9-1 vs 891 is concerned. Interesting! you CAN define 8-9-1 and 891 in 1.4 in the same context (even tho the code is there to equate them); and there's code to equate them in the matching... so, I define both 8-9-1 and 891, and if I dial 8-9-1 I get exten 8-9-1, and if I dial 891, I get exten 891.... arrrrrrrrrrrgggggg! |
| 18:43.50 | file | so... regression? |
| 18:44.08 | Corydon76-dig | dials ---------- |
| 18:45.16 | codefreeze-lap | file: dunno yet. it seems like the rule to equate them should make it so you can't enter them both in the same exten, and dialing 8-9-1 and 891 should have gotten the same exten... something inconsistent about *that*. |
| 18:51.07 | putnopvut | acl and host access functions in Asterisk are weird. That is all. |
| 18:51.42 | lmadsen | codefreeze-lap: gah! |
| 18:55.13 | codefreeze-lap | Hmmm. What am I complaining about? With the proposed changes, I match 1.4 behavior exactly! Let me check to see what 1.4 does if you only define one or the other... |
| 18:55.35 | lmadsen | codefreeze-lap: aye... it does seem to be a regression if it works in 1.4... |
| 18:57.25 | codefreeze-lap | aha! in 1.4, if I define only 891, then dialing 8-9-1 fails, no extension found |
| 18:58.03 | codefreeze-lap | So, the matching is NOT dash-agnostic |
| 18:58.32 | codefreeze-lap | well, dash-indifferent, might be better |
| 18:59.39 | codefreeze-lap | So, my proposal will make trunk compatible with 1.4 |
| 19:03.39 | codefreeze-lap | LOL, the same code is in ext-cmp1 in 1.4 and trunk. Just works in trunk, is all. I don't know if I want to take the time to figure out why it doesn't in 1.4, either. |
| 19:06.32 | codefreeze-lap | lmadsen: file: russellb: whaddya'll think, do I still need to write a letter? The proposed tweak in trunk/1.6.x will just make things behave as 1.4 did. |
| 19:07.02 | file | so it was an introduced regression that you are now fixing... sounds fine to me |
| 19:09.57 | codefreeze-lap | lmadsen: so, I'll remove all the stuff/comments about ' ' and '-' in the code, (pbx.c), and you make sure that the docs don't say anything either? (which may be null anyway) |
| 19:12.29 | codefreeze-lap | lmadsen: oh, heck, I'll do both halves; I'll make sure no mention is in the sample dialplans. |
| 19:13.34 | lmadsen | lol |
| 19:13.45 | lmadsen | I don't think there will be anything in the extensions.conf.sample in re: to that |
| 19:19.45 | mvanbaak | mornin all |
| 19:20.11 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-479c3fa192a35841) |
| 19:20.11 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 19:20.41 | lmadsen | morning :) |
| 19:22.05 | mvanbaak | russellb: did you check chan_skinny wrt the channel variables ? |
| 19:22.30 | mvanbaak | <--- hates to do double work |
| 19:22.33 | codefreeze-lap | lmadsen: correct. nothing. |
| 19:22.56 | file | mvanbaak: I doubt it would have been applicable |
| 19:23.49 | mvanbaak | file: ah, then there's no problem |
| 19:24.21 | mvanbaak | like I said right before I flew out to get the train I based the skinny and dahdi on the sip implementation |
| 19:25.06 | file | the issue with the sip one is that it was possible for the variables to get added to the same private structure multiple times, causing a memory leak in each case if they were previously there |
| 19:26.17 | mvanbaak | I checked chan_skinny, and it's not an issue there ;) |
| 19:26.58 | mvanbaak | we only attach them to lines there when we reread the config file |
| 19:34.06 | jsmith-teaching | Hey, quick question... what does [Dec 16 14:31:35] ERROR[4445] astobj2.c: bad magic number 0x0 for 0xb7c78ae8 mean? |
| 19:38.17 | seanbright | means memory corruption |
| 19:38.46 | seanbright | or passing a non-ao2 object to one of the ao2 functions |
| 19:39.02 | jsmith-teaching | seanbright: Ah, gotcha... which means that this thing segfaulting immediately after that message was probably related |
| 19:39.25 | Qwell | that seems rather likely |
| 19:49.56 | russellb | mvanbaak: i did not check, so thanks for cechking :-) |
| 19:50.08 | russellb | jsmith-teaching: indeed. that's a bad message to get. |
| 19:53.42 | wedhorn | mvanbaak: ping |
| 20:09.49 | mvanbaak | wedhorn: pong |
| 20:10.02 | mvanbaak | russellb: no problemo dude |
| 20:11.04 | wedhorn | quick q, currently skinny creates an ast_channel structure when the device goes off hook, but doesn't use it until we send it to pbx_run (ie until we actually make the call). |
| 20:11.16 | codefreeze-lap | chan_vpb gives a failed assertion on loading, out of a vpb lib.... on my trunk, 64 bit, machine. |
| 20:11.28 | wedhorn | Do you see any reason not to delay the creation of the channel until we actually use it? |
| 20:13.14 | mvanbaak | wedhorn: I think we should not create it until we use it |
| 20:13.37 | wedhorn | makes clean up easier. |
| 20:13.44 | mvanbaak | btw, chan_skinny in 1.6.0 svn is broken big time |
| 20:14.05 | mvanbaak | when you have a call, take it, and hangup asterisk coredumps right after the hangup |
| 20:14.20 | russellb | that doesn't sound preferable. |
| 20:14.26 | wedhorn | ouch |
| 20:14.40 | mvanbaak | indeed |
| 20:15.01 | wedhorn | mvanbaak: related to above, how early should earlyrtp be? |
| 20:15.21 | mvanbaak | just found out today because I decided I was without phonesystem long enough so connected my skinny phones to my production box (1.6 svn) |
| 20:15.39 | wedhorn | I had a patch that actually had the dialtone being played by asterisk, rather than the device |
| 20:15.47 | mvanbaak | before I was running trunk, but my home system died |
| 20:15.48 | wedhorn | but qwell didn't like it |
| 20:16.17 | mvanbaak | I'll have a look at it later, I have to go over to the neighbour because 'we dont have internet right now) |
| 20:16.23 | mvanbaak | be back in 10 minutes |
| 20:16.38 | jsmith-teaching | russellb: We've seen that "bad magic number" message twice this class on 1.6.1-beta3 :-( |
| 20:17.51 | russellb | hrm! |
| 20:17.59 | russellb | are you in huntsville? |
| 20:18.00 | putnopvut | jsmith-teaching: what were you doing when you saw it? |
| 20:18.06 | lmadsen | russellb: he is in Baltimore |
| 20:18.07 | putnopvut | he's in baltimore |
| 20:18.09 | russellb | ah. |
| 20:18.11 | russellb | well then. |
| 20:18.19 | russellb | i'd be happy to look at backtraces and such .. |
| 20:18.21 | lmadsen | wonders if it still happens in the 1.6.1 branch? |
| 20:18.23 | putnopvut | seanbright: go help jsmith-teaching out! |
| 20:18.27 | putnopvut | j/k |
| 20:18.43 | russellb | you're a brave man to run beta code in training :-) |
| 20:19.05 | jsmith-teaching | russellb: I don't even have a backtrace... and yes, I'm *stupid* for running a beta in a classroom env, but I thought it might be helpful to give 1.6.1 a good shakedown |
| 20:19.26 | jsmith-teaching | will have them compile with DONT_OPTIMIZE next time |
| 20:19.26 | russellb | it's very helpful, i'm just very sorry that it's not working .. |
| 20:19.31 | jsmith-teaching | If you were in the mood, you could look at 14088 for me |
| 20:19.40 | russellb | M14088 |
| 20:19.41 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/General 0014088: Problem with matching incoming calls on sip friend reported by jsmith (Karma: +30.25) http://bugs.digium.com/view.php?id=14088 |
| 20:19.43 | russellb | there, I looked at it |
| 20:19.45 | russellb | zing |
| 20:19.53 | jsmith-teaching | slaps his knee |
| 20:21.57 | lmadsen | is about to re-test it |
| 20:22.08 | lmadsen | otherwiseguy said he doesn't get the issue on 1.6.1 branch checkout |
| 20:22.10 | lmadsen | I'm going to verify |
| 20:22.17 | lmadsen | but that he got the issue on 1.6.1-beta3 |
| 20:22.31 | Corydon76-dig | Or Bal'mer, as they say there. |
| 20:22.59 | Corydon76-dig | and the state is Merlin |
| 20:23.26 | lmadsen | does it have a funny hat? |
| 20:23.50 | Corydon76-dig | jsmith-teaching: You eat any arsters while there? |
| 20:24.01 | putnopvut | arsters? MD is all about crabs! |
| 20:24.29 | jsmith-teaching | Corydon76-dig: Naw... but I'm sure gonna eat a lot of crabs |
| 20:24.37 | Corydon76-dig | putnopvut: only for turists |
| 20:24.43 | jsmith-teaching | Corydon76-dig: (even though all the crabs here will be from Alaska this time of year) |
| 20:24.49 | putnopvut | Corydon76-dig: no way man. |
| 20:25.02 | Corydon76-dig | putnopvut: it's arster season in Merlin |
| 20:25.35 | jsmith-teaching | Corydon76-dig: I've never been a fan of paying that much money to watch a glob of snot slide down my throat |
| 20:25.48 | putnopvut | jsmith-teaching: you don't have to watch. |
| 20:26.01 | jsmith-teaching | s/watch/feel/ |
| 20:26.21 | Corydon76-dig | If you shuck 'em yerself, it's cheaper |
| 20:26.26 | Corydon76-dig | and bloodier |
| 20:26.54 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 20:27.00 | Corydon76-dig | Shucking is the reason I have thick skin on the sides of my forefingers |
| 20:27.54 | Corydon76-dig | When your hands are so cold, you don't realize you stabbed yourself with a shucking knife until half an hour later... |
| 20:31.23 | lmadsen | sounds like... fun |
| 20:33.04 | lmadsen | [Dec 16 11:32:52] WARNING[8255]: res_config_odbc.c:882 require_odbc: Realtime table sipfriends@asterisk requires column 'defaultuser', but that column does not exist! <-- now THAT is a useful warning! |
| 20:33.09 | lmadsen | thanks for whoever put that in! |
| 20:34.45 | Corydon76-dig | lmadsen: Heh |
| 20:35.07 | lmadsen | heh... I assumed it was you :) |
| 20:36.10 | Juggie | you mean you dont like error messages like 'we shoudnt be here, how did this code get run' |
| 20:36.22 | lmadsen | ideally not :) |
| 20:36.26 | lmadsen | although they are fun |
| 20:37.05 | jsmith-teaching | lmadsen: Realtime table sipfriends@asterisk requires column 'defaultuser', but that column does not exist! Would you like me to add it? Y/N: |
| 20:37.15 | lmadsen | hahaha |
| 20:37.16 | Corydon76-dig | lmadsen: Well, I needed a message that would be clear to someone as to what they ought to do |
| 20:37.18 | lmadsen | hawt :) |
| 20:37.29 | lmadsen | Corydon76-dig: I don't even know that we got those msg's at all before |
| 20:37.41 | lmadsen | I think a lot of it was you just had to "know" what you needed |
| 20:37.48 | Corydon76-dig | jsmith-teaching: You DO realize that the mysql and postgres backends do exactly that, right? |
| 20:38.01 | lmadsen | I'm totally in favour of anything that can make it easier to debug |
| 20:38.18 | jsmith-teaching | Corydon76-dig: Absolutely! That's why I mentioned it :-p |
| 20:39.12 | jsmith-teaching | compiles the latest from the 1.6.1 branch for testing on but 14088 |
| 20:39.15 | jsmith-teaching | s/but/bug/ |
| 20:39.25 | lmadsen | jsmith-teaching: 1.6.1 branch does not show the issue you report |
| 20:39.32 | lmadsen | I'm trying 1.6.1-beta3 right now to verify the bug existed there |
| 20:39.39 | lmadsen | waits for it to compile... |
| 20:39.52 | jsmith-teaching | lmadsen: Sure... but the calls don't match on the friend *at all* in the latest 1.6.1 (as of yesterday) |
| 20:40.01 | lmadsen | really? that seems untrue to me... |
| 20:40.07 | jsmith-teaching | lmadsen: That's why I'm re-compiling today to see if anything else has changed int he meantime |
| 20:40.08 | lmadsen | it matches fine for me using your configs |
| 20:40.18 | lmadsen | sure, give it a shot |
| 20:40.31 | lmadsen | unless you missed a step last night because you were too tired after a day of teaching? |
| 20:41.36 | jsmith-teaching | Naw... chan_sip.c had changed between yesterday and today |
| 20:42.00 | russellb | mvanbaak: trunk is failing to build for me now after those sysinfo changes |
| 20:42.01 | lmadsen | wonders what could have been changed since last night to fix the issue... |
| 20:42.03 | russellb | (linux) |
| 20:43.53 | jsmith-teaching | lmadsen: and it's definitely working now! |
| 20:44.12 | lmadsen | what revision were you using last night? |
| 20:44.40 | jsmith-teaching | SVN-branch-1.6.1-r164527 |
| 20:44.51 | jsmith-teaching | The working one is SVN-branch-1.6.1-r164805 |
| 20:44.58 | lmadsen | interesting |
| 20:48.00 | *** join/#asterisk-dev eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 20:48.00 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 21:03.31 | lmadsen | jsmith-teaching: fwiw, I can't reproduce the issue on 164527 |
| 21:07.02 | jsmith-teaching | lmadsen: Did you do it on a fresh restart of Asterisk? |
| 21:07.09 | lmadsen | yes I did |
| 21:07.14 | jsmith-teaching | lmadsen: Hmmmmn... |
| 21:07.19 | lmadsen | and de-registered the peer before restarting it |
| 21:07.37 | jsmith-teaching | lmadsen: I just did a "database deltree SIP" and then "stop now" |
| 21:07.56 | lmadsen | hmmm... failed for me on beta3 even without a database deltree SIP |
| 21:08.02 | lmadsen | oh well... at least its not an issue now :) |
| 21:09.06 | tzafrir | sruffell, any news on 13483 (dahdi_dynamic_ethmf) ? |
| 21:09.37 | tzafrir | Note that the patch there includes independent fixes to dahdi_dynamic |
| 21:10.33 | *** join/#asterisk-dev telecos (n=sergio@6.166.219.87.dynamic.jazztel.es) |
| 21:14.39 | sruffell | tzafrir: haven't looked at it...but I can this week. |
| 21:14.57 | sruffell | (I'm always a bit loathe to commit things I can't personally test) |
| 21:25.38 | codefreeze-lap | russellb: you hate the KEEPALIVE return codes with a passion, I see. the masq_park branch.... fixes that once and for all..... and maybe, with your other fix (remembering channel vs peer state), the hangup stuff can be resolved... |
| 21:27.05 | russellb | codefreeze-lap: I saw it on reviewboard, but thought you had some issues you were working on |
| 21:27.14 | russellb | if it's ready for review, just say the word, and I"ll take a look |
| 21:29.00 | codefreeze-lap | Well, the only issue was the hangups not running at the right time, due to: a) the masquerade forked the pbx owner to the old channel; b) hangup by the new thread, managed by the parking man. thread.... |
| 21:30.12 | codefreeze-lap | And, of course, the hangup exten running in the parkinglot thread will have to suppress it being done for the other fork of the masq |
| 21:30.48 | codefreeze-lap | To get thoughts on this issue, is why I wanted to post that on reviewboard. |
| 21:31.11 | codefreeze-lap | But I never quite got it so I could publish it... the diffs gave errors... |
| 21:32.50 | codefreeze-lap | russellb: but, even if we ignore this little difficulty, applying the masq_park changes will get rid of the KEEPALIVE stuff and parking, and the crashes that can happen there. |
| 21:34.51 | file | raises eyebrow |
| 21:36.14 | russellb | well we can't put it in if there are regressions .. |
| 21:39.56 | snuff-work | mm russellb.. with the issue u closed about iax not showing 'trunks'.. did you also add to the cli/ami when you query for detail info to see if a iax has trunking? |
| 21:40.17 | russellb | i'm not sure what you're asking |
| 21:40.24 | snuff-work | M13629 |
| 21:40.26 | MuffinMan | [closed] [Asterisk] Channels/chan_iax2 0013629: IAX2 peer does not show trunk reported by pananix (Karma: +1.50) http://bugs.digium.com/view.php?id=13629 |
| 21:40.31 | russellb | trunking was broken |
| 21:40.33 | russellb | i fixed it. |
| 21:40.34 | russellb | :) |
| 21:40.41 | snuff-work | i added 2 patches.. not to 'fix trunking' |
| 21:41.22 | snuff-work | but so u could actually see if an iax link was a trunk |
| 21:41.28 | russellb | i totally missed those patches |
| 21:41.32 | russellb | i'm sorry |
| 21:41.41 | codefreeze-lap | russellb: It's already not running the h-extens at the right time; so it's kinda a 'trade one regression for another' sorta issue. |
| 21:41.42 | snuff-work | mm its ok.. just noticed it was closed off |
| 21:41.58 | russellb | snuff-work: sorry .. want to submit those as their own issue? |
| 21:42.00 | russellb | then i can look |
| 21:42.14 | snuff-work | k i will get around to it next day or 2 |
| 21:45.40 | codefreeze-lap | russellb: and... committing it would keep people from fixing the crashes and probs piecemeal, like they have... by throwing in either KEEPALIVE fixes or substituting in more masq_park calls.. |
| 21:46.27 | russellb | it's a really big change to throw in _right_ before 1.4.23 .. |
| 21:47.11 | russellb | I guess I can review the situation tomorrow morning when my brain is more functional |
| 21:47.16 | codefreeze-lap | Oh, that's the issue; I'm sure it could wait for the next round, then... |
| 21:47.35 | file | what is this about the 'h' extension with it |
| 21:47.52 | russellb | yeah, i don't quite understand the issues, that's what i was going to review it tomorrow morning |
| 21:48.04 | russellb | but also, aside from that, it's a pretty invasive patch for the timing |
| 21:48.08 | russellb | i'd like to wait if it makes sense |
| 21:48.23 | codefreeze-lap | file: A calls B; B parks A; A hangs up while parked. H-exten? |
| 21:49.04 | codefreeze-lap | russellb: sure, no prob, just letting you know it's around. |
| 21:49.09 | file | so you are treating that filed issue as a bug? |
| 21:49.16 | russellb | file: which one |
| 21:49.24 | russellb | my brain is shutting down on me |
| 21:50.01 | file | M13820 |
| 21:50.03 | MuffinMan | [assigned] [Asterisk] Resources/res_features 0013820: Executing 'h' extension if parked channel hangs up reported by mdu113 (Karma: +5.50) http://bugs.digium.com/view.php?id=13820 |
| 21:50.39 | codefreeze-lap | file: I think that's the one. it's not a bug? |
| 21:51.06 | russellb | well, i can see how some people might expect it to ... but I doubt it has ever worked that way |
| 21:51.13 | file | highly doubt it |
| 21:51.54 | russellb | yeah, that's just how it works |
| 21:51.59 | codefreeze-lap | oh, well, yes, it's never worked that way, true. The real q is: how should it behave... |
| 21:52.02 | russellb | i don't think I would consider that a candidate for 1.4 |
| 21:52.12 | russellb | since it's a significant change in behavior |
| 21:52.17 | *** join/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 21:52.29 | codefreeze-lap | Hmmmm. very interesting! |
| 21:52.34 | file | agreed |
| 21:52.38 | russellb | we can also query the -dev list on it, but yeah |
| 21:52.50 | russellb | the results he sees are exactly what I would expect |
| 21:52.58 | russellb | and changing that behavior is something that we can consider, but as a new feature |
| 21:54.11 | codefreeze-lap | OK, I can live with that! |
| 21:54.17 | russellb | :-) |
| 21:54.56 | russellb | do you want to chat on the phone tomorrow about all of this? |
| 21:55.14 | russellb | we can even drag file in |
| 21:55.17 | russellb | file: :-p |
| 21:55.23 | codefreeze-lap | sure... you pick the time |
| 21:55.29 | file | russellb: :) |
| 21:57.27 | russellb | 'tis on the calendar |
| 21:58.09 | file | oh my! |
| 21:58.53 | russellb | hehe |
| 22:00.25 | codefreeze-lap | ok, noon my time it is |
| 22:02.09 | russellb | can be moved if you want |
| 22:12.24 | jsmith-teaching | russellb: Feel like looking at a backtrace on a machine with lots of "bad magic number" problems? |
| 22:12.48 | jsmith-teaching | russellb: (or should I just chalk this up to bad hardware and move the poor guy to a different PC?) |
| 22:15.47 | *** join/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 22:20.02 | russellb | sure, I'll take a look. |
| 22:20.13 | jsmith-teaching | russellb: OK, let me pastebin it somewhere. |
| 22:20.41 | putnopvut | If it's queue-related, I'll also take a look. I've been fixing some refcounting problems in app_queue lately. I'll need to see if it's something I've already fixed. |
| 22:20.57 | putnopvut | Most of what I've been fixing has been the result of trying to use the "queue show" command in odd circumstances though. |
| 22:21.09 | jsmith-teaching | It's segfaulting in chan_sip.c |
| 22:21.15 | putnopvut | oh, gross. |
| 22:22.47 | jsmith-teaching | russellb: http://asterisk.pastebin.com/m7f2485ce |
| 22:24.10 | russellb | oh dear. |
| 22:24.52 | russellb | looks like it's trying to transmit on an invalid sip_pvt.. |
| 22:24.53 | putnopvut | jsmith-teaching: workaround might be to turn qualify off temporarily. |
| 22:25.46 | jsmith-teaching | russellb: The funny thing is... what triggers it is calling app_meetme |
| 22:26.01 | Corydon76-dig | codefreeze-lap: what does utils/extconf.c do? |
| 22:27.13 | jsmith-teaching | russellb: I can setup a reverse SSH tunnel if you want to take a closer look |
| 22:27.30 | jsmith-teaching | russellb: Otherwise, I'm gonna run memtest86+ on this box and see if it shows bad memory |
| 22:28.27 | russellb | i'm not sure ... that's not going to be a quick issue |
| 22:28.40 | russellb | it may have bad memory, but it's probably just a valid bug |
| 22:28.58 | russellb | i probably can't fix it quickly |
| 22:30.08 | eliel | Corydon76-dig: look inside the file, there is a comment explaining it. |
| 22:30.48 | Corydon76-dig | eliel: the question is whether I need to change a routine within it or not |
| 22:31.44 | Corydon76-dig | I'm guessing "no" |
| 22:32.38 | eliel | i think it must be in sync with the "real" code (? is that your question?) |
| 22:39.07 | eliel | (? no) |
| 22:48.34 | Corydon76-dig | russellb: ping |
| 22:48.54 | russellb | pong |
| 22:49.18 | Corydon76-dig | Had a thought. In addition to CHANGES and UPGRADE.txt, what about an API-CHANGES ? |
| 22:49.36 | russellb | perhaps |
| 22:49.40 | Corydon76-dig | "Do this if you're upgrading your third party application, to maintain compatibility" |
| 22:49.43 | russellb | thought for 1.4 to 1.6.0, we have a document for that |
| 22:49.46 | russellb | in doc/ |
| 22:49.57 | russellb | so perhaps we should just make new versions of documents like that |
| 22:50.12 | Corydon76-dig | Ah, api-1.6.0-changes.odt |
| 22:50.19 | russellb | or create a new one for 1.6.X-changes |
| 22:50.27 | russellb | that we append to for all changes within 1.6.X |
| 22:50.27 | eliel | we are not supposed to maintain backward compatibility also in the api? |
| 22:50.41 | russellb | we will try :-) |
| 22:50.47 | russellb | but we don't guarantee it |
| 22:50.52 | russellb | and we will try even harder for ABI |
| 22:51.06 | Corydon76-dig | eliel: for example, I just added ast_destroy_timing. If you use ast_build_timing in the past, you should start using ast_destroy_timing, as well |
| 22:51.25 | Corydon76-dig | Otherwise, memory leakage |
| 22:51.53 | eliel | Corydon76-dig: so, you must start using it :) |
| 22:52.06 | eliel | +1 |
| 22:53.00 | eliel | why not a DEV-CHANGES |
| 22:53.22 | eliel | and put everything there |
| 22:54.12 | eliel | and pointing new api functions like threadstorage, xmldoc, etc |
| 22:54.37 | eliel | so a developer will go there to find new dev-stuff |
| 23:21.44 | denon | so, I hate to even ask it .. but any of you have much hands-on with Avaya IP Office? |
| 23:23.34 | Corydon76-dig | denon: do you have a free copy that runs on Linux? |
| 23:23.51 | denon | heh heh, no, I doubt it |
| 23:23.58 | denon | I just will likely have to tie asterisk into it |
| 23:24.21 | denon | well, I guess it's free to me, they already own it |
| 23:24.35 | denon | and I could virtualize it and run that on linux if you want :) |
| 23:55.00 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 23:55.00 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |