| 00:08.17 | *** join/#asterisk-dev Corydon76-vcch (n=tilghman@pdpc/supporter/bronze/Corydon76-home) |
| 00:08.17 | *** mode/#asterisk-dev [+o Corydon76-vcch] by ChanServ |
| 00:35.02 | denon | so what's the status on this IBM NEBS blade server/HA stuff .. |
| 00:35.06 | denon | people actively using it? |
| 00:40.32 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 00:58.10 | *** join/#asterisk-dev RoyK_ (n=roy@ip-24-16-149-91.dialup.ice.no) |
| 01:02.15 | *** join/#asterisk-dev Greek-Boy (n=email@41.221.58.4) |
| 01:14.40 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 01:27.38 | g0mb0 | anybody here from Digium? |
| 01:28.34 | file | perhaps, what do you need? |
| 01:31.29 | g0mb0 | http://bugs.digium.com/view.php?id=11976 |
| 01:31.39 | g0mb0 | waiting them to accept it |
| 01:31.51 | g0mb0 | already signed agreement |
| 01:32.07 | file | it has been rejected for some reason |
| 01:33.32 | file | if you submitted it again it'll be looked at tomorrow |
| 01:33.54 | g0mb0 | oh, men |
| 01:37.23 | file | you just submitted another bug for the same thing? |
| 01:38.46 | g0mb0 | http://bugs.digium.com/view.php?id=11998 |
| 01:38.48 | g0mb0 | done again |
| 01:39.09 | Qwell | g0mb0: which codec negotiation patch are you referring to? |
| 01:39.12 | file | you could have just attached your patches to the original issue once your license was accepted |
| 01:39.32 | g0mb0 | oh, ok, didn't quite get it, sorry |
| 01:39.42 | g0mb0 | anyway I submitted again |
| 01:39.47 | file | I'll just close 11976 |
| 01:40.11 | g0mb0 | ok |
| 01:40.27 | file | all done. |
| 01:40.27 | g0mb0 | but, one patch is LICENSE PENDING |
| 01:40.36 | g0mb0 | don't get that one |
| 01:40.49 | g0mb0 | should I sign agreement for every patch I send |
| 01:40.51 | g0mb0 | ? |
| 01:40.53 | file | no |
| 01:40.54 | Qwell | no, just once |
| 01:41.00 | file | you sign it once and it applies to all patches |
| 01:41.04 | Qwell | g0mb0: what does this fix, exactly? |
| 01:41.06 | file | since your license has not yet been accepted it isp ending |
| 01:41.09 | file | pending rather |
| 01:41.16 | g0mb0 | http://bugs.digium.com/view.php?id=11998 |
| 01:41.32 | g0mb0 | I guess just makes it compile :) |
| 01:41.43 | Qwell | yes, I see that, but what makes it not compile? what patch? |
| 01:42.22 | g0mb0 | well, without my patches, when codec negotiation patch applied to asterisk |
| 01:42.30 | g0mb0 | asterisk-addons doesn't compile |
| 01:42.59 | g0mb0 | sorry my English is crap |
| 01:43.50 | Qwell | which codec negotiation patch? |
| 01:46.34 | g0mb0 | http://bugs.digium.com/file_download.php?file_id=10594&type=bug |
| 01:46.40 | g0mb0 | I guess this one |
| 01:46.52 | Qwell | that issue was closed. it will not be committed. |
| 01:48.30 | g0mb0 | yeah, it seems like it is closed |
| 01:48.34 | tzafrir | g0mb0, your patches are needed to make it build, or "just" to make it work right? |
| 01:49.18 | Qwell | g0mb0: you should post your patches here - http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch |
| 01:49.33 | g0mb0 | it definitely builds and I'm testing its work |
| 01:49.43 | g0mb0 | ok |
| 01:52.26 | g0mb0 | anyway thanks all |
| 02:01.35 | g0mb0 | actually that issue was closed just yesterday, interesting :) |
| 02:02.16 | g0mb0 | after more than 2 years |
| 02:06.55 | g0mb0 | one quuestion |
| 02:21.09 | *** join/#asterisk-dev RoyK^ (n=roy@ip-24-16-149-91.dialup.ice.no) |
| 02:47.06 | *** join/#asterisk-dev RoyK_ (n=roy@ip-24-16-149-91.dialup.ice.no) |
| 02:47.14 | *** join/#asterisk-dev jameswf-home (n=james@ip72-204-221-181.ph.ph.cox.net) |
| 02:51.53 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 03:16.07 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 03:16.32 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 03:51.04 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 03:56.03 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 03:56.26 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 03:59.43 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.20.243.195.user.ajato.com.br) |
| 04:24.21 | *** join/#asterisk-dev putnopvut (n=putnopvu@user-24-214-112-81.knology.net) |
| 04:24.21 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 04:39.53 | *** join/#asterisk-dev mosty (n=mostyn@60-241-198-194.static.tpgi.com.au) |
| 05:27.30 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:27.30 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 06:45.16 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 07:00.51 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:17.07 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-124343.home.otenet.gr) |
| 07:17.39 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 07:17.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:18.30 | oej | Morning |
| 07:27.25 | mvanbaak | mornin |
| 07:46.12 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 08:11.52 | sergee | hi there |
| 08:23.01 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 08:24.12 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 08:24.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:00.03 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:38.11 | g0mb0 | hi sergee, did you have chance to look at my problem posted yesterday? |
| 09:42.41 | sergee | g0mb0: unfortunately no, i will have some time for it in the middle of the next week, it would be nice if we'll keep in touch, because i don't have GNU GK at my site |
| 09:42.52 | g0mb0 | ok |
| 10:05.21 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:07.42 | *** join/#asterisk-dev Greek-Boy (n=email@41.221.58.4) |
| 10:10.10 | *** join/#asterisk-dev skipper2 (n=DK@chello084113018116.7.12.vie.surfer.at) |
| 10:11.16 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:04.41 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:01.02 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.127.250) |
| 12:24.13 | *** join/#asterisk-dev ccesario (n=ccesario@ns1.unialco.com.br) |
| 12:26.15 | *** join/#asterisk-dev fadey (n=fadey@239.Red-80-36-91.staticIP.rima-tde.net) |
| 12:36.32 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:00.37 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 13:16.49 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 14:07.18 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:07.18 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:27.24 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:27.24 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:33.59 | *** join/#asterisk-dev ManxPower (n=manxpowe@117.sub-75-202-35.myvzw.com) |
| 14:41.56 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 14:44.24 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 15:08.57 | *** join/#asterisk-dev elguero (n=elguero@h-68-167-124-171.cmbrmaor.covad.net) |
| 15:15.58 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:25.53 | steliosk | Hi all ! |
| 15:27.32 | steliosk | I need to set up a test environment for testing zaptel and an e1 card on a big endian platform |
| 15:27.51 | jameswf | ~rulost |
| 15:27.52 | jbot | #asterisk-dev is for exchanges related to the development of asterisk. If you need help please try posting your question in #asterisk |
| 15:28.16 | steliosk | i though of setting up a second * box (x86) to emulate the netowrk |
| 15:29.32 | steliosk | jameswf : well its semi-dev ;) i working on a powerpc platform porting * and zaptel and need to test some stuff |
| 15:34.39 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:34.39 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:35.21 | Corydon76-dig | Yeah, just reverse the pri_net/pri_cpe on the other side, and it'll work fine |
| 15:35.23 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 15:35.23 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 15:35.59 | Corydon76-dig | PowerPC/Linux, correct? |
| 15:39.37 | steliosk | Corydon76-dig : yes. Its a custom board based on a Xilinx fpga and a custom e1 card and i want to test the drivers etc |
| 15:45.32 | *** join/#asterisk-dev agallo (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 15:59.29 | *** join/#asterisk-dev seanbright (n=elixer@65.207.74.18) |
| 16:03.05 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 16:06.19 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 16:21.59 | ZaVoid | hey russellb what happen if the read() application was changed to work on the begin frames of DTMF detection for rfc2833? |
| 16:23.15 | russellb | how about we just figure out and fix any case where the END doesn't arrive? |
| 16:23.19 | russellb | that's just plain broken |
| 16:23.32 | russellb | i mean, if you want to do that in your own copy as a workaround, that's fine |
| 16:23.34 | russellb | it's trivial |
| 16:24.37 | russellb | and by trivial, i mean not trivial |
| 16:24.44 | russellb | geez, this goes like 10 functions deep to read a digit |
| 16:24.53 | file | russellb: yes, yes it does |
| 16:25.13 | russellb | ok, and ... yeah |
| 16:25.18 | russellb | it's not trivial at all |
| 16:25.19 | russellb | NEVERMIND |
| 16:26.44 | ZaVoid | its broken but its the real world |
| 16:26.57 | ZaVoid | my carrier doesn't send the END.. they refuse to acknoweldge that and won't fix it |
| 16:27.03 | ZaVoid | so i need a work around to make it work |
| 16:27.12 | lmadsen | get a new carrier :D |
| 16:27.16 | ZaVoid | and this carrier has the best rates to many UAE destination |
| 16:27.20 | ZaVoid | again lmadsen welcome to real world :) |
| 16:27.38 | ZaVoid | 1/2 a penny rate difference is worth it for us to have someone code a one-off so it works |
| 16:27.44 | lmadsen | ZaVoid: I don't live in the real world; I work with Asterisk! :) |
| 16:27.54 | ZaVoid | lol yeah it happens haha |
| 16:28.05 | russellb | ZaVoid: have you provided them debug output to show it? |
| 16:28.09 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 16:28.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:28.09 | ZaVoid | yes russellb |
| 16:28.12 | lmadsen | I just write dialplans, I let other people deal with that stuff :) |
| 16:28.15 | ZaVoid | they simply don't care |
| 16:28.20 | ZaVoid | hey oej |
| 16:28.21 | Corydon76-dig | Just remember, if you code a workaround, the terrorists win |
| 16:28.25 | lmadsen | lol |
| 16:28.27 | ZaVoid | want some custom development work? |
| 16:28.46 | ZaVoid | in soviet russia dtmf begin frames own you! |
| 16:28.56 | russellb | hm, i have an idea ... |
| 16:29.00 | oej | Russian DTMF scares me |
| 16:29.19 | russellb | actually, i don't. |
| 16:29.31 | ZaVoid | so oej could you make a custom READ() app that (or modify existing) to reconize DTMF on the BEGIN frame if an end frame never comes? |
| 16:30.07 | oej | Sounds like a file thing, but I guess that's doable |
| 16:30.32 | ZaVoid | however its doable |
| 16:30.38 | russellb | the thing is, it's not generally applicable |
| 16:30.43 | russellb | it's a workaround for a broken carrier |
| 16:31.00 | russellb | so i can't think of something we could do that could be merged ... |
| 16:31.08 | oej | It is a very good example of something that is not generic or could be merged, I agree |
| 16:31.11 | russellb | so it's definitely custom work |
| 16:31.20 | ZaVoid | yah i thought about that too russellb |
| 16:31.23 | ZaVoid | what about somthing like this? |
| 16:31.29 | ZaVoid | readbrokendtmf() |
| 16:31.32 | ZaVoid | branch read.. lol |
| 16:31.33 | russellb | ha |
| 16:31.41 | oej | could be zavoidread() |
| 16:31.43 | ZaVoid | from a carrier perspective i've seen this happen a lot now |
| 16:31.58 | ZaVoid | ooo keep my name off breaking rfc standards please |
| 16:32.02 | ZaVoid | i did enuff of that back with h323 |
| 16:32.06 | file | I'm pretty sure rfc2833compensate should compensate for that.. |
| 16:32.12 | ZaVoid | it doesn't file |
| 16:32.29 | ZaVoid | in fact when i turned that on i got nothing in my debug |
| 16:32.31 | russellb | file: that just drops the begin, and compensates on the end ... |
| 16:32.32 | russellb | right? |
| 16:32.35 | *** join/#asterisk-dev kpfleming (n=kpflemin@216.207.245.1) |
| 16:32.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:32.36 | file | russellb: no |
| 16:32.37 | russellb | doesn't apply here |
| 16:32.40 | russellb | oic |
| 16:33.14 | file | it doesn't have any notion of begin or end |
| 16:33.52 | ZaVoid | i can pay either of you for a solution to :) |
| 16:34.04 | ZaVoid | russellb gets paid in lap dance vouchers though |
| 16:34.06 | russellb | file and I can't do it unless it's generally applicable |
| 16:34.15 | russellb | and can't take your money :) |
| 16:34.21 | ZaVoid | right |
| 16:34.25 | ZaVoid | so call it carrierread() |
| 16:34.37 | ZaVoid | so here's the situation where it happens ok? |
| 16:34.54 | ZaVoid | I'm dialing through another sip carrier.. that connects to any number of termination they have to a 3rd world country celluar network |
| 16:35.09 | ZaVoid | i don't know if you guys deal wiht international voip much but nothing ever works right in the 3rd world lol |
| 16:35.17 | ZaVoid | call it looseread() lol |
| 16:35.21 | russellb | haha, we only deal with it in debug output |
| 16:35.26 | russellb | we don't actually ... use this stuff |
| 16:35.28 | russellb | that's what you are for |
| 16:35.36 | ZaVoid | yeah tell me about it |
| 16:35.47 | ZaVoid | hell i'll get my company to sign new support contracts with digium too |
| 16:36.02 | ZaVoid | i still gotta show you those network diagrams for the asterisk farm we got |
| 16:36.51 | russellb | unless file comes back after contemplating with a good idea, i think getting oej to hack up a fix for you is your best bet |
| 16:37.29 | ZaVoid | yeah but then thats not standard |
| 16:37.41 | ZaVoid | i mean think of t this way |
| 16:37.53 | russellb | so you have a carrier sending rfc2833 begins and no ends |
| 16:37.55 | russellb | seriously? |
| 16:37.59 | ZaVoid | you guys been in telecom long? standards are nice... but real world appilications need some variance(options) etc etc |
| 16:38.06 | ZaVoid | yah russ you wanna see the debugs? |
| 16:38.10 | russellb | no, i believe you |
| 16:38.12 | ZaVoid | and its MCI |
| 16:38.17 | russellb | file: how about this ... |
| 16:38.18 | ZaVoid | you ever work with those bastards? |
| 16:38.22 | file | well wait... |
| 16:38.27 | file | how do you know they aren't sending ends? |
| 16:38.28 | Corydon76-dig | ZaVoid: you mean Verizon Business |
| 16:38.33 | ZaVoid | yes Corydon76-dig |
| 16:38.47 | ZaVoid | i still call vsnl teleglobe or itxc too though |
| 16:38.54 | russellb | file: rfc2833beginonly=yes or something ... causes behavior to turn begins into ends and drop any ends received |
| 16:38.57 | ZaVoid | its fun keeping up with acquistions |
| 16:39.12 | russellb | file: that wouldn't break anything even if you did receive an end, and would let compensation do it's thing to turn it into begin and end |
| 16:39.46 | Corydon76-dig | russellb: that would be totally incompatible with 1.2, though... as a note... |
| 16:39.52 | russellb | no it wouldn't |
| 16:39.56 | Corydon76-dig | 1.2 sends each begin 3 times |
| 16:39.59 | ZaVoid | some logs: http://www.woot.us/dtmf.html |
| 16:40.06 | russellb | right, that would be handled |
| 16:40.09 | ZaVoid | thisis for 1.4 |
| 16:40.10 | russellb | they have the same sequence numbers |
| 16:40.18 | russellb | or whatever it is |
| 16:40.23 | russellb | that's acutally pretty common |
| 16:40.28 | Corydon76-dig | That's true |
| 16:40.42 | russellb | that's such a dirty hack for lossy networks, heh |
| 16:40.56 | ZaVoid | yes but most international networks are extremely lossy |
| 16:41.03 | file | that debug doesn't really show whether we are really not getting the end |
| 16:41.12 | ZaVoid | most of our biggest customers have about 5-10% packetloss from mideast at most times and huge latency and jitter |
| 16:41.16 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 16:41.17 | russellb | ZaVoid: you and your ... reality |
| 16:41.24 | ZaVoid | well i said i could do a tethereal trace before |
| 16:41.30 | Corydon76-dig | ZaVoid: how's your connectivity to cuba? |
| 16:41.46 | ZaVoid | yeah russellb my reality has pissed off a lof people at vocaltec, lucent, nextone and sansay let me tell you haha |
| 16:41.52 | ZaVoid | cuba route? |
| 16:42.03 | ZaVoid | cuba's always a route of opportunity.. its up.. then it dies |
| 16:42.11 | ZaVoid | i know two of my customers have routes right now though |
| 16:42.37 | Corydon76-dig | Something like 70% of all calls attempted to Cuba fail |
| 16:42.54 | ZaVoid | probably more |
| 16:43.05 | ZaVoid | your talking ASR or abr? |
| 16:43.15 | Corydon76-dig | ASR, I think |
| 16:43.23 | file | ZaVoid: an rtp debug would be fine... |
| 16:43.39 | ZaVoid | you guys just don't like tetheral eh? |
| 16:43.47 | ZaVoid | ok let me get my tester back online |
| 16:44.07 | ZaVoid | wait didn't i show you one of those? |
| 16:44.26 | file | I don't remember |
| 16:44.38 | russellb | we look at too many things a day :) |
| 16:45.33 | file | codefreeze: as we have learned with chan_iax2... if something was not designed to be multithreaded in the first place it's ugly. |
| 16:45.35 | ZaVoid | yeah i hear ya same here |
| 16:45.39 | ZaVoid | let me make a new one |
| 16:47.47 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 16:47.55 | ZaVoid | oo woot-off today |
| 16:50.49 | ZaVoid | ok getting my tester to do it now |
| 16:53.53 | De_Mon | I don't see any discussion in the CLI audit ticket about using <module> hangup for iax,sip,local,etc.. |
| 16:54.24 | De_Mon | what that ever considered and decided against? |
| 16:55.13 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 16:55.21 | De_Mon | console hangup I never forget, but to hangup anything else, i've really got to think about it |
| 17:00.34 | ZaVoid | file: http://www.woot.us/logss/rtp.html |
| 17:01.13 | ZaVoid | that should do it for ya |
| 17:01.46 | ZaVoid | let me know when you grab it so i ca pull it offline |
| 17:02.15 | file | I don't see any RFC2833 packets |
| 17:03.52 | ZaVoid | [2008-02-15 17:03:05] DTMF[20774] channel.c: DTMF begin passthrough '3' on Local/971504755841@anicallback-leg1-03e1,1 |
| 17:03.55 | ZaVoid | from the dtmf logger |
| 17:04.24 | ZaVoid | every peer is set to dtmfmode=rfc2833 |
| 17:05.02 | file | there is no RFC2833 packets :D only audio |
| 17:05.20 | ZaVoid | meh |
| 17:05.31 | ZaVoid | so the carrier isn't even sending via rfc2833 your saying? |
| 17:05.50 | ZaVoid | what in the rtp debug tells you its rfc2833 so i can look myself |
| 17:06.36 | file | it'll say "Got RTP RFC2833 from" then the address and some details about the packet |
| 17:07.02 | ZaVoid | ok |
| 17:09.16 | ZaVoid | crap |
| 17:09.17 | ZaVoid | Got RTP RFC2833 from 64.156.174.71:18688 (type 101, seq 000905, ts 139760, len 000004, mark 0, event 00000001, end 0, duration 01680) |
| 17:09.18 | ZaVoid | i see |
| 17:09.24 | ZaVoid | ok back on the phone i guess... |
| 17:09.44 | ZaVoid | so what happens in theory if i have rfc2833 set and they don't send rf2833 other then ti works inband i guess 20% of the time |
| 17:10.27 | file | can't tell you what happens without seeing other logs and such... |
| 17:10.38 | ZaVoid | yeap |
| 17:10.53 | ZaVoid | but i emant from a dev perspective.. if i have rf2833 set.. that will allow inband as well i guess? |
| 17:11.06 | ZaVoid | it can't stop inband persay.. so it'll process if it hears em |
| 17:11.20 | file | I do not believe so, I think only auto enables both rfc2833 and inband |
| 17:13.30 | *** join/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 17:13.30 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 17:13.57 | file | hey BJ! |
| 17:15.52 | lmadsen | omg bweschke !!! |
| 17:16.05 | bweschke | hi! |
| 17:16.07 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 17:16.07 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:16.16 | bweschke | how are ya guys?! |
| 17:16.36 | bweschke | nice! |
| 17:16.45 | lmadsen | I'm not dead! |
| 17:16.50 | lmadsen | take that as you will |
| 17:17.40 | bweschke | lmadsen: Mmmmmmmmk |
| 17:18.21 | file | lmadsen: well... you don't think you are dead |
| 17:18.34 | lmadsen | that is true, I have no proof that I am really alive |
| 17:18.38 | lmadsen | all I know is that I'm sentient |
| 17:21.17 | putnopvut | "all I know is that I'm sentient" is a verbose way of saying "I think, therefore I am" |
| 17:24.18 | ZaVoid | so file while i'm in the process of ripping this carrier a new one... is it possible i am still missing the ENDs from an inband reading of the DTMF and that causing the problem as well? because i still see begin only.. then ignores |
| 17:27.27 | file | I believe the inband only gives end frames right now... so I don't know why you would get a begin with it... so either your route was different previously and you actually were getting RFC2833, or something else happened... |
| 17:32.41 | ZaVoid | yeah during those logs i wasn't doing rtp debug so hard to say.. |
| 17:32.50 | ZaVoid | it was definitely same carrier |
| 17:36.27 | codefreeze | file: as to multi-threading, I can easily imagine that! |
| 17:37.15 | codefreeze | file: was chan_iax designed for multi-threading from the beginning? |
| 17:37.19 | file | no |
| 17:37.38 | codefreeze | file: what was the ugliest part? |
| 17:37.49 | file | locking. |
| 17:38.32 | russellb | the locking rules did not account for that |
| 17:38.40 | russellb | and nor do they in chan_sip |
| 17:38.51 | russellb | it would most likely be just as much of a nightmare there |
| 17:38.57 | russellb | i _really_ would rather not go down that road |
| 17:39.02 | russellb | i don't think it's worth it |
| 17:39.07 | russellb | unless we were starting over anyway |
| 17:39.29 | codefreeze | I see a lot of loops of lock-unlock loops 'to avoid deadlock'... |
| 17:40.04 | russellb | yes, it's tricky |
| 17:40.18 | russellb | one of the cardinal rules with locking is that you must preserve consistent locking order |
| 17:40.31 | kpfleming | well, one area that would be easier is the lack of media handling, so at least there's no locking/threading issues to deal with there |
| 17:40.34 | russellb | as not doing so is what causes deadlocks |
| 17:40.45 | file | kpfleming: that is true |
| 17:40.53 | russellb | that's true ... |
| 17:41.17 | russellb | codefreeze: all of the avoiding deadlock crap is just to rearrange locks so that you get them in the right order |
| 17:41.20 | file | common calling would probably be okay... but get into stuff like transfers and it might become a nightmare... or more of one |
| 17:41.46 | russellb | but it also complicates the code, as the object you have can change while you don't have the lock on it ... |
| 17:41.52 | russellb | it's ... interesting |
| 17:44.00 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 17:44.31 | codefreeze | Well, the last week or so of trying to get rid of destruction problems in sip, will make me a little quicker at spotting the same probs in IAX... I can't help to think that speeding up the find_call there will free up a lot of cpu cycles for simultaneous calls.... |
| 17:45.00 | russellb | find_call is gross |
| 17:45.02 | russellb | :) |
| 17:46.04 | codefreeze | Well, I can't make it prettier, but I can make it faster. And if I can clear up the stupid destroy probs, we can find out how much faster. |
| 17:46.31 | Corydon76-dig | codefreeze: oh, are you already working on the destruction problems in 11960? |
| 17:46.43 | russellb | codefreeze: so are your chan_sip changes "done" ? |
| 17:46.52 | russellb | or what's left on your list for that? |
| 17:49.08 | codefreeze | russellb: well, I want to run a few more tests, comparing behavior with trunk. Here, if I call from my polycom to a zap analog phone, when I hang up the zap phone, my polycom seems to think we are still talking. Asterisk hung everything up and ran the hangup extension stuff in the dialplan. I need to see if trunk behaves the same... if not, I have some more work to do. |
| 17:50.02 | russellb | ok, sounds good |
| 17:50.22 | russellb | it certainly shouldn't behave that way ... i wouldn't expect that trunk does |
| 17:50.23 | russellb | but who knows |
| 17:50.25 | russellb | good to test |
| 17:50.48 | codefreeze | Otherwise, so far, it looks like I closed all the mem leaks, and stopped all the crashes from multiple destruction calls on the same obj. |
| 17:51.19 | russellb | good stuff :) |
| 17:51.52 | codefreeze | I threw a ton of advise on ref count tracing into astobj2.h, and documented what I think needed to be documented... |
| 17:52.22 | russellb | file, kpfleming: loader expected behavior question ... if a module returns AST_MODULE_LOAD_DECLINE, would you want that module's reload() function to get called on a reload? (it does happen, btw, but my feeling is that it should not) |
| 17:52.55 | codefreeze | I don't know if Luigi will appreciate the stuff I added to astobj2 for tracing, tho. |
| 17:53.20 | putnopvut | russellb: since the typical reload command doesn't actually unload and load the module, I agree that it should not. |
| 17:54.31 | russellb | codefreeze: we'll see ... i still need to look at how that part works in more detail |
| 17:54.32 | *** join/#asterisk-dev BBHoss (n=hoss@c-71-207-173-38.hsd1.al.comcast.net) |
| 17:54.35 | file | I agree... in fact depending on the module's usage of DECLINE it could cause issues |
| 17:54.48 | russellb | right ... chan_console cleans up after itself in that case |
| 17:54.53 | russellb | which is the cause of the crash in 11953 |
| 17:54.55 | russellb | M11953 |
| 17:54.56 | MuffinMan | [assigned] [Asterisk] . I did not set the category correctly. 0011953: segfault on module reload chan_console.so reported by junky http://bugs.digium.com/view.php?id=11953 |
| 18:08.27 | codefreeze | M11960 |
| 18:08.29 | MuffinMan | [new] [Asterisk] Channels/chan_sip/Interoperability 0011960: Call from '' to extension '7104' rejected because extension not found reported by norman http://bugs.digium.com/view.php?id=11960 |
| 18:09.20 | codefreeze | 11960 |
| 18:09.21 | Corydon76-dig | codefreeze: I'm still working on trying to track that down |
| 18:09.40 | codefreeze | ok |
| 18:11.04 | codefreeze | a loose pointer left laying around, maybe in a scheduled callback? |
| 18:11.41 | Corydon76-dig | No, even worse |
| 18:11.56 | Corydon76-dig | The monitor is destroying the call while the bridge is still active |
| 18:15.15 | codefreeze | someone must have filed down the trigger on the hangup... |
| 18:17.13 | *** join/#asterisk-dev jackm1944 (n=IceChat7@CPE000f664f0f37-CM0014045a95ea.cpe.net.cable.rogers.com) |
| 18:20.28 | ZaVoid | bah i'm getting MCI to fix it |
| 18:21.36 | russellb | :) |
| 18:26.11 | jackm1944 | does anybody know anything about fastsms agi file? |
| 18:27.09 | russellb | is that a part of asterisk? |
| 18:27.20 | russellb | oh, agi file ... um, no |
| 18:27.30 | russellb | and #asterisk is your only bet for finding someone on IRC ... |
| 18:27.46 | russellb | file: you're going to love this loader fix |
| 18:28.05 | file | uh oh |
| 18:28.05 | jackm1944 | it is an asterisk addon found it at voip-info.org |
| 18:28.27 | jackm1944 | it is working but giving the following error message: 510 Invalid or unknown command |
| 18:28.52 | russellb | ok, well, please try #asterisk ... it's not really appropriate for this channel, sorry |
| 18:28.53 | jackm1944 | I am using /www.bayhamsystems.com to send sms |
| 18:29.00 | mvanbaak | me too |
| 18:29.02 | mvanbaak | it rox |
| 18:29.04 | *** join/#asterisk-dev agx (n=badpengu@81-174-44-186.dynamic.ngi.it) |
| 18:29.10 | mvanbaak | but not a -dev question ;) |
| 18:29.15 | jackm1944 | i did russellb but nobody answered that is why i asked here but thank you |
| 18:29.57 | russellb | sorry we can't help you |
| 18:30.05 | Corydon76-dig | If nobody answers in there, then asking in here is about as nonsensical as asking on knowledgebase.microsoft.com |
| 18:30.32 | russellb | Corydon76-dig: that's a stretch :) |
| 18:30.54 | russellb | at least it's asterisk related ... heh |
| 18:30.54 | jackm1944 | even I see your name at the #asterisk, so you know I asked the same question over there too |
| 18:31.11 | russellb | yeah, but i don't read everything in there ... i'm in a ton of channels |
| 18:31.15 | russellb | and i'm trying to work, too :) |
| 18:31.35 | jackm1944 | ok, just frustrated with this error message |
| 18:31.45 | russellb | i'm sorry ... maybe try to contact whoever wrote it |
| 18:31.51 | jackm1944 | o |
| 18:31.52 | jackm1944 | o |
| 18:31.53 | jackm1944 | ok |
| 18:31.56 | agx | jackm1944: you can try with the mailing list.. usually better answers then #asterisk |
| 18:32.07 | jackm1944 | ok thanks |
| 18:34.58 | Corydon76-dig | russellb: it's still computer related, though. ;-) |
| 18:35.07 | russellb | heh, i guess |
| 18:35.26 | file | russellb: HA |
| 18:35.29 | Corydon76-dig | We could have sent him to his local soup kitchen |
| 18:35.36 | russellb | file: :-D |
| 18:38.00 | Corydon76-dig | Lovely... A customer in Memphis blames the Asterisk reseller because their telco got struck by lightning last Tuesday and they're still not 100% back up |
| 18:38.16 | russellb | sad |
| 18:39.15 | file | Corydon76-dig: and their reasoning? |
| 18:40.49 | Corydon76-dig | file: they have no idea whose fault it is, they just want it fixed |
| 18:41.11 | Corydon76-dig | Apparently they're not familiar with the term Act of God |
| 18:42.00 | file | excellent |
| 18:42.09 | jameswf | Jesus saves..... he uses windows |
| 18:42.11 | Corydon76-dig | They're fortunate that their building didn't get blown away by the same storm that took out the telco |
| 18:42.46 | Corydon76-dig | Hence why I've been out of pocket for the past 10 days |
| 18:56.21 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 18:56.21 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 19:22.26 | codefreeze | russellb: phew... got around to installing latest trunk, and trying it out. No diff in behavior between my branch & trunk for polycom phone.... |
| 19:23.53 | russellb | codefreeze: that's good and bad at the same time, i guess :) |
| 19:23.56 | jsmith | Speaking of polycom... |
| 19:23.58 | russellb | but yeah, i'm glad it wasn't your code |
| 19:24.34 | codefreeze | jsmith: just ONE? ;) |
| 19:24.50 | jsmith | codefreeze: Just one related specifically to Polycom phones |
| 19:25.37 | file | jsmith: is it that auth one? |
| 19:25.43 | jsmith | file: Bingo! |
| 19:25.49 | jsmith | Somebody give file a prize! |
| 19:27.17 | *** join/#asterisk-dev ManxPower (n=manxpowe@117.sub-75-202-35.myvzw.com) |
| 19:28.30 | ZaVoid | my 501 sux |
| 19:28.42 | ZaVoid | terrible device |
| 19:28.54 | ZaVoid | why should it take 6 minutes to add a another line in and have it configure via a reboot? |
| 19:29.37 | mvanbaak | that's polycom |
| 19:30.26 | ZaVoid | rediculous |
| 19:30.45 | ZaVoid | can you imageine 6 minute reload type to change a peer in sip.conf(not including debuging to get it working i mean) |
| 19:32.01 | jsmith | That's Polycom phones for ya... |
| 19:32.09 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 19:32.22 | ZaVoid | thats a terrible way to look at things though lol |
| 19:32.29 | ZaVoid | my grandsteam reboots in 30s econds |
| 19:32.36 | ZaVoid | granted the whole rebooting concept is silly |
| 19:32.37 | jsmith | My Linksys boots in 5 |
| 19:33.01 | jsmith | And I can change information on many screens before having to reload |
| 19:33.03 | ZaVoid | yeah but your stick with 1 g729 line in that case jsmith |
| 19:33.09 | ZaVoid | stuck |
| 19:33.32 | ZaVoid | my softlclient doesn't have to reboot my mac.. makes me happy |
| 19:33.35 | jsmith | Actually, I think my 962 will do at least two |
| 19:33.41 | ZaVoid | oh thought you meant pap2 |
| 19:33.44 | ZaVoid | well never mind then ;) |
| 19:33.53 | jsmith | ZaVoid: Not like your grandstream can handle more than one g.729a call anyway |
| 19:34.03 | ZaVoid | it can't? |
| 19:34.10 | ZaVoid | actually never tried 2 lines at same time |
| 19:34.16 | ZaVoid | wouldn't surprise me though lol |
| 19:34.16 | jsmith | ZaVoid: Nope |
| 19:34.30 | ZaVoid | not shocking i guess |
| 19:34.44 | ZaVoid | sjphone wtih g.729 is nice though |
| 19:35.56 | ZaVoid | any of you use sjphone for testing? |
| 19:37.02 | kpfleming | russellb: ping |
| 19:37.12 | russellb | pong |
| 19:37.35 | kpfleming | so the original intent of DECLINE was to say 'hey, i cant do that right now, but try again later' |
| 19:37.51 | kpfleming | so in that case, a reload would be expected to work if the condition that caused the decline in the first place has been rectified |
| 19:38.18 | file | we need to do an audit then of modules, to make sure they behave correctly under those circumstances |
| 19:38.33 | russellb | well ... i think that's fine |
| 19:38.49 | russellb | assuming the trigger for rectifying the situation is done by another call to "module load" |
| 19:39.06 | russellb | making reload() handle the case where the module may or may not be initialized would be a major PITA |
| 19:39.28 | kpfleming | will 'module load' work correctly without unloading the module by hand first? |
| 19:40.14 | russellb | looks like it does |
| 19:40.26 | *** part/#asterisk-dev agx (n=badpengu@81-174-44-186.dynamic.ngi.it) |
| 19:40.41 | russellb | so if it was DECLINE at first, but you fixed your config or whatever, run module load again, it's fine |
| 19:40.48 | kpfleming | ok |
| 19:41.05 | kpfleming | then i agree with having 'module reload' do nothing for modules that declined... or even better, report an error |
| 19:41.28 | russellb | yeah, the only error it reports now in that case is deceiving |
| 19:41.31 | russellb | it says the module wasn't found |
| 19:41.43 | russellb | i'll improve that now |
| 19:45.04 | ZaVoid | russellb: what would be great for error reporting is if my dialplan crashes and burns the reason why it crashed it burned on the console or logged... |
| 19:45.21 | ZaVoid | :) |
| 19:45.39 | ZaVoid | maybe i should rephrase that? |
| 19:45.51 | russellb | probably |
| 19:45.54 | ZaVoid | like if it dies because of a syntax error.. give some indication to that |
| 19:46.03 | Corydon76-dig | It already does |
| 19:46.13 | tzafrir_home | any problem if I change the permissions of zaptel module parameters to be 644 rather than 600? |
| 19:46.20 | ZaVoid | it doesnt that've seen |
| 19:46.21 | ZaVoid | for exam ple |
| 19:46.24 | ZaVoid | exten => 8300,1,Macro(checkbalanceee) |
| 19:46.32 | ZaVoid | but i have no macro checkbalanceeee |
| 19:46.47 | ZaVoid | it just dies.. should say dead because no macro with name XXXXX exists or somthing |
| 19:47.14 | tzafrir_home | I also wonder which parameters should not be modified at runtime, and hence should be 444 |
| 19:47.30 | Corydon76-dig | ZaVoid: it prints a WARNING that says "No such context '...' for macro '...'" |
| 19:47.52 | ZaVoid | never seen that |
| 19:47.58 | ZaVoid | let me reprodue |
| 19:48.08 | Corydon76-dig | ZaVoid: do you have warning in logger.conf for console? |
| 19:48.19 | ZaVoid | now that Corydon76-dig is a GREAT question |
| 19:48.44 | ZaVoid | err |
| 19:48.46 | Corydon76-dig | See if you turned OFF the messages, they won't be there, but errors, warnings, and notices are all on by default |
| 19:48.46 | ZaVoid | shit |
| 19:48.49 | ZaVoid | [logfiles] |
| 19:48.49 | ZaVoid | debug => debug,dtmf |
| 19:48.49 | ZaVoid | ;console => notice,warning,error,debug |
| 19:48.56 | ZaVoid | that semi-colon would be bad huh? |
| 19:49.01 | Corydon76-dig | Yes |
| 19:49.22 | ZaVoid | ok i owe you an extra drink at astricon Corydon76-dig |
| 19:49.46 | Corydon76-dig | Heh... I might even be there this year |
| 19:49.55 | ZaVoid | damn pesky semicolons |
| 19:50.00 | ZaVoid | wtf is that doing there anyway? |
| 19:52.40 | *** join/#asterisk-dev AdamWest (n=Leif@CPE001d7e2f9574-CM0012c9db3d2e.cpe.net.cable.rogers.com) |
| 19:53.04 | ZaVoid | [2008-02-15 19:52:24] WARNING[21671]: app_macro.c:212 _macro_exec: No such context 'macro-cccccccccheckbalance-lastcall-en' for macro 'cccccccccheckbalance-lastcall-en' |
| 19:53.06 | ZaVoid | wow |
| 19:56.04 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:56.04 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 20:16.45 | Qwell | russellb: how does that reload thing affect "reload rtp" or things like that? |
| 20:16.51 | Qwell | non-modules |
| 20:23.02 | russellb | it doesn't affect it at all |
| 20:23.29 | russellb | built-in things don't have this "i didn't initialize properly, but that's ok, move on anyway" option :) |
| 20:23.45 | Qwell | ahh, right |
| 20:25.23 | *** join/#asterisk-dev lirakis (i=lirakis@pr0tected.us) |
| 20:26.18 | lirakis | can any one speak to the accuraccy of the L() parameter for dial() ? I am passing it 45000 and consistently am getting ANSWERTIME's of 48 seconds |
| 20:29.04 | putnopvut | lirakis: there's actually a bug report open about that right now...let me find the number. |
| 20:29.43 | lirakis | ahh |
| 20:29.44 | putnopvut | M11973 |
| 20:29.46 | MuffinMan | [new] [Asterisk] Channels/General 0011973: The L(XXX) option does not work when the call is bridged. reported by falves11 http://bugs.digium.com/view.php?id=11973 |
| 20:29.50 | lirakis | well that would explain some thing |
| 20:29.59 | putnopvut | That one is reported against trunk actually. Which version of Asterisk do you use? |
| 20:30.27 | lirakis | putnopvut: errr uhh... he he.. this is old .. 1.2.18 |
| 20:31.16 | putnopvut | Ah...well I can't really speak for that one. |
| 20:31.20 | lirakis | putnopvut: this is just a clunker dev box though |
| 20:31.40 | lirakis | putnopvut: i just ordered up the hardware for deployment today... |
| 20:31.47 | seanbright | lirakis: 1.2 isn't supported anymore except for security problems, so you're not likely to get a fix unless you code it up yourself |
| 20:31.50 | lirakis | putnopvut: is it a known issue in 1.4 genrally |
| 20:32.05 | lirakis | seanbright: no i know... im just doing some testing |
| 20:32.26 | seanbright | lirakis: just fyi'ing :) |
| 20:32.32 | putnopvut | I haven't heard anything about it for 1.4, and I also don't know if better than that resolution can be done. I'm not sure how that's implemented. |
| 20:32.52 | lirakis | putnopvut: hmm okay.. |
| 20:33.18 | putnopvut | I mean, better than that resolution should be possible, but I'd have to look at the implementation to see why it's not working exactly correctly. |
| 20:33.27 | lirakis | putnopvut: for my purposes... it seems to be pretty consistent that i get about 2 seconds more ANSWERTIME than i specify should be allowed |
| 20:35.42 | Corydon76-dig | The limit is for the bridge itself, if the call is answered before then, there would be a discrepancy |
| 20:36.16 | Corydon76-dig | If you call Answer before then, you can limit the call by using AbsoluteTimeout |
| 20:36.42 | Corydon76-dig | Also note that if you keep the call going in the "h" extension, that may also extend the duration of the call |
| 20:37.11 | lirakis | Corydon76-dig: ... i do use the h extension to call an AGI script |
| 20:37.34 | lirakis | Corydon76-dig: is there a better metric ? billsec ? that indicates the actual talk time? |
| 20:37.47 | Corydon76-dig | Nope |
| 20:38.04 | Corydon76-dig | billsec indicates the time from answer to end |
| 20:38.20 | lirakis | Corydon76-dig: and thats for the call itself.. including h time .. |
| 20:38.24 | lirakis | Corydon76-dig: hmm |
| 20:38.32 | Corydon76-dig | If you use cdr_adaptive_odbc, you could simulate it with another field |
| 20:38.55 | Corydon76-dig | Just set the time that the call ends as the first step in the h extension |
| 20:38.55 | lirakis | Corydon76-dig: not 1.4 .. ill take a look when i setup this new server |
| 20:39.04 | ZaVoid | russellb: is there any way in the sip channel to basically ignore or override a realtime look up first on an incoming invite? |
| 20:39.10 | Corydon76-dig | Oh, then you're screwed |
| 20:39.12 | lirakis | Okay thanks to every one |
| 20:39.18 | lirakis | Corydon76-dig: ;) |
| 20:39.20 | russellb | ZaVoid: no |
| 20:39.26 | ZaVoid | that would be a great feature/enhancement |
| 20:39.39 | ZaVoid | right now i have to modify my invites on boxes to add say 9999 to the from: field |
| 20:39.50 | ZaVoid | so i ca ensure it drops in the right context |
| 20:40.14 | ZaVoid | prefixing is just kludgy |
| 20:40.30 | Corydon76-dig | If it was good enough for H.323 providers... |
| 20:41.24 | lirakis | Corydon76-dig: .. soo .. just to clarify .. the L() option WILL hangup the call at the specified time? |
| 20:41.56 | lirakis | Corydon76-dig: if what you've said is the case (which i fully believe it to be) ... L() is working fine and my answer time is what is inaccurate |
| 20:42.16 | Corydon76-dig | lirakis: no, the L option merely ends the bridge |
| 20:43.08 | lirakis | Corydon76-dig: okay.. well from "my perspective" ... that is effective enough for me.. because .. ending the bridge .. will end the time the carrier is going to bill me |
| 20:43.22 | Corydon76-dig | Correct |
| 20:43.31 | lirakis | Corydon76-dig: good .. perfect :) |
| 20:43.57 | lirakis | Corydon76-dig: then i will log the ANSWERTIME for a "just in case" record, and otherwise use the param i pass to L as the effective talk time |
| 20:44.05 | Corydon76-dig | unless the customer is calling in across another provider |
| 20:44.24 | lirakis | Corydon76-dig: good thing to investigate.. ill take a look at that scenario |
| 20:44.30 | Corydon76-dig | lirakis: uh, only if it's less than AnswerTime |
| 20:44.51 | lirakis | Corydon76-dig: right .. L is always less than ANSWERTIME .. |
| 20:45.05 | Corydon76-dig | lirakis: if someone hangs up early, then the L parameter didn't activate |
| 20:45.23 | Corydon76-dig | otherwise you bill your customer for the entire time they have left, not the time they used |
| 20:45.33 | lirakis | Corydon76-dig: gotcha |
| 20:45.39 | lirakis | Corydon76-dig: your a smart one ;) |
| 20:51.25 | ZaVoid | i'd love to see ${CAUSECODE} return the actual SIP Cause code from Dial or another variable from Dial to do that |
| 20:53.48 | ZaVoid | you the whole realworld again ;) |
| 20:54.00 | ZaVoid | err you know... damn i can't type |
| 20:56.06 | Corydon76-dig | Asterisk is Not A SIP Proxy |
| 20:56.18 | ZaVoid | i understand that Corydon76-dig but it gets sip responses |
| 20:56.35 | ZaVoid | why not provide those in variable.. its pretty much a must for any true CDRS |
| 20:56.58 | Corydon76-dig | Because we chose Q.931 result codes as our universals |
| 20:57.02 | ZaVoid | hell sjphone is a UA and i can get the SIP responses faulure codes out of that |
| 20:57.20 | Corydon76-dig | Those result codes all map from SIP response code |
| 20:57.37 | ZaVoid | so you build a next gen pbx/telecom device and choose old isdn q.931 as response codes? |
| 20:57.44 | ZaVoid | or you could provide both depending on the channel |
| 20:57.50 | Corydon76-dig | Yes, but sjphone is a SIP phone, not a B2BUA |
| 20:58.03 | ZaVoid | wait where does it provide q.931 respponses? |
| 20:58.16 | ZaVoid | ${HANGUPCAUSE} ? |
| 20:58.16 | Corydon76-dig | CAUSECODE |
| 20:58.22 | Corydon76-dig | That, too |
| 20:58.25 | ZaVoid | caousecode has like 5 variables |
| 20:58.32 | ZaVoid | full q.931 is from like 1 to 127 |
| 20:58.41 | Corydon76-dig | Correct |
| 20:59.08 | ZaVoid | i've nver seen $CAUSECODe return a numerical value like that |
| 20:59.30 | Corydon76-dig | or HANGUPCAUSE |
| 21:00.26 | ZaVoid | yeah but sip doesn't match up one to one to q.931 at all |
| 21:00.42 | Corydon76-dig | We did the mapping ourselves |
| 21:01.05 | ZaVoid | yeah so does every vendor.. i have map file on nextones i change per customer requests but i get the cause code |
| 21:01.17 | ZaVoid | how hard could it be to return the sip code in a variable when your getting it already? |
| 21:01.36 | ZaVoid | now thats somthing i'd be definitely willing to sponsor |
| 21:01.42 | Corydon76-dig | Have fun |
| 21:02.24 | Corydon76-dig | See hangup_sip2cause in chan_sip |
| 21:04.07 | Corydon76-dig | If you wanted to propose a finer grained mapping, that would probably be accepted, too |
| 21:08.21 | ZaVoid | well i don't want q.931 |
| 21:08.35 | ZaVoid | what good is q.931 if i have a SIP UA to asterisk to SIP UA |
| 21:08.54 | ZaVoid | thats like saying your going to use the french manual for an american car |
| 21:09.24 | ZaVoid | anyone following me or think i'm totally nuts here? |
| 21:12.20 | Corydon76-dig | It's the Asterisk cause code, too |
| 21:13.06 | Corydon76-dig | Like I said, if you want to change the cause codes in chan_sip, so there's a 1:1 correspondence between those two sets, that would enable you to do what you want |
| 21:13.27 | ZaVoid | ok but your still withholding information that get from a UA for no good reason... |
| 21:13.34 | Corydon76-dig | Right now, more than a few of the SIP codes map back to a single code |
| 21:13.40 | ZaVoid | which is silly |
| 21:13.45 | Corydon76-dig | Because it's protocol specific |
| 21:14.02 | ZaVoid | right but map it to whatever you want thats fine..but also give it in its raw state as well.. |
| 21:14.33 | ZaVoid | my Sansay SPX's and VSX's and Nextone MSW's give me 3 cause codes.. SIP.ISDN(q931) and platform specific |
| 21:14.43 | ZaVoid | i can choose to use whichever i want to or map etc etc |
| 21:16.11 | ZaVoid | so what i'm basically saying is froma design perspective why would you want to withhold/destroy what is considered valuable information by any adminstrator of the system for troubleshooting debugging/rerouting based on cause code etc etc |
| 21:33.33 | ZaVoid | ::crickets:: ::crickets:: |
| 21:46.18 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 22:28.39 | jpeeler | is there ever a reason not to do strncpy(dest, src, sizeof(dest) - 1)? |
| 22:29.17 | putnopvut | jpeeler: sometimes if the size of src is known, just using strcpy can be all right. |
| 22:29.21 | russellb | if dest is a char *, then it's not valid |
| 22:29.38 | russellb | sizeof() only works if it's a statically defined buffer |
| 22:29.56 | jpeeler | well you mean use strlen instead |
| 22:30.12 | putnopvut | jpeeler: no, that won't work. |
| 22:30.29 | russellb | you have to have some other way to know the buffer size |
| 22:30.37 | russellb | generally, this is when the buffer is passed as an argument to the function |
| 22:30.45 | russellb | and in that case, the length _better_ be another argument |
| 22:31.12 | putnopvut | Or the length may be some #defined macro somewhere that was used to size the buffer to begin with, in which case you use that macro. |
| 22:31.17 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 22:39.19 | jpeeler | russellb: should every instance after using strncpy in zaptel explicitly null terminate the destination buffer? |
| 22:41.46 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584095.dsl.bell.ca) |
| 22:42.37 | russellb | jpeeler: tricky question. |
| 22:42.40 | russellb | yes and no. |
| 22:43.05 | russellb | no, if you know that the buffer was originally initialized to all 0's |
| 22:43.11 | russellb | yes, if you don't |
| 22:43.26 | russellb | usually most allocations are zero'd out when first done |
| 22:43.53 | jpeeler | so i need to go through the code and determine the buffer status at allocation |
| 22:45.20 | mvanbaak | can svnmerge timeout ? |
| 22:47.16 | russellb | mvanbaak: if svn can timeout ... |
| 22:47.59 | russellb | jpeeler: um, yeah, i guess so |
| 22:54.48 | mvanbaak | russellb: svnmerge has been running for over 2 hours now |
| 22:54.51 | mvanbaak | funny |
| 22:54.52 | mvanbaak | :) |
| 22:55.11 | mvanbaak | 15 minutes to merge 40,000 revisions of code |
| 22:55.24 | mvanbaak | rest is on the last step, generate svnmerge-commit-message.txt |
| 22:57.15 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 23:08.34 | russellb | mvanbaak: heh, across the ocean, yeah, i guess i'm not surprised |
| 23:08.46 | russellb | mvanbaak: when i'm trying to do something like that, i do it in small chunks at a time |
| 23:09.07 | russellb | that way, less conflicts to deal with .. |
| 23:09.18 | mvanbaak | russellb: only 4 files with conflicts |
| 23:09.24 | mvanbaak | not that bad this time |
| 23:09.39 | mvanbaak | I just thought: 'fuck it, lets give it a try' |
| 23:09.50 | mvanbaak | to see how bad it is |
| 23:11.39 | russellb | heh |
| 23:12.30 | mvanbaak | it turns out to be not that bad |
| 23:13.15 | mvanbaak | I'll update it, make it compile and stuff, fix some stuff that oej did with normal 'static char' to be in the AST_STRINGFIELD scope and talk to him thursday |
| 23:13.35 | mvanbaak | I'll take my thinkpad with me to show him I fixed it on linux, bsd and solaris |
| 23:14.14 | mvanbaak | I think it will be ready in like a week or two at max |
| 23:15.02 | mvanbaak | I'll need testers for the zap, uni<something>, mgcp and console channels |
| 23:15.25 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 23:17.30 | mvanbaak | hoooooooooooooooly crap |
| 23:17.54 | mvanbaak | this yearly pop concert here in .nl just released some of the bands that will be there |
| 23:18.28 | mvanbaak | METALLICA, INCUBUS, FOO FIGHTERS, KAISER CHIEFS * EDITORS * KT TUNSTALL * MOKE |
| 23:18.31 | mvanbaak | THE VERVE * NOVASTAR * BAD RELIGION |
| 23:18.45 | mvanbaak | GROOVE ARMADA * JUSTICE* RAGE AGAINST THE MACHINE |
| 23:18.45 | mvanbaak | QUEENS OF THE STONE AGE * RACOON |
| 23:18.45 | mvanbaak | GAVIN DEGRAW * FICTION PLANE |
| 23:18.45 | mvanbaak | COUNTING CROWS * SERJ TANKIAN |
| 23:18.45 | mvanbaak | THE HIVES * CAVALERA CONSPIRACY |
| 23:18.47 | mvanbaak | THE WOMBATS * ROISIN MURPHY |
| 23:18.50 | mvanbaak | SAYBIA * PETE MURRAY * KATE NASH |
| 23:18.52 | mvanbaak | PATRICK WATSON |
| 23:18.55 | mvanbaak | oops |
| 23:18.57 | mvanbaak | sorry |
| 23:20.15 | *** join/#asterisk-dev RoyK (n=roy@ip-208-10-149-91.dialup.ice.no) |
| 23:21.26 | jsmith-away | Wow... that sounds like quite the concert |
| 23:21.33 | jsmith-away | But you're missing Abba and Roxette |
| 23:21.35 | mvanbaak | 3 days |
| 23:21.44 | mvanbaak | 130 euro for a 3day ticket |
| 23:22.10 | mvanbaak | including camp ground and stuff |
| 23:22.44 | mvanbaak | woooooooooooooooooooooooooow |
| 23:22.48 | mvanbaak | svnmerge is done ! |
| 23:22.55 | mvanbaak | 2 hours and 58 minutes |
| 23:23.56 | putnopvut | geez... |
| 23:24.04 | putnopvut | Hopefully you had a movie to watch or something. |
| 23:32.00 | mvanbaak | -rw-r--r-- 1 michiel michiel 8.6M 2008-02-16 00:32 multipark_oej_mvanbaak.diff.txt |
| 23:32.38 | mvanbaak | I upgraded oej's branch to svn trunk |
| 23:32.58 | mvanbaak | and this is the output of: svn diff > ../multipark_oej_mvanbaak.diff.txt |
| 23:44.50 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 23:45.32 | Mavvie | 9236 8644http://lca2008.linux.org.au/programme/presentations <- very interesting talk of David Rowe about embedded Asterisk. (ogg recording available) |
| 23:50.51 | Mavvie | to bad they don't have a 2 PRI one available for just putting in between old PABXs and the PSTN. |
| 23:59.04 | mvanbaak | the new soekris 5501 can handle that |
| 23:59.19 | mvanbaak | just make sure you dont have to do media transcoding |
| 23:59.26 | mvanbaak | then it can handle it without trouble |
| 23:59.44 | mvanbaak | <--- uses 5501 as PRI gateways |