| 00:01.36 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-124-177-30-127.lns2.dav.bigpond.net.au) |
| 00:16.22 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:16.23 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:47.06 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 02:52.36 | *** join/#asterisk-dev snuff-work (~aaa@120.17.4.104) |
| 02:52.36 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 04:16.59 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-124-177-30-127.lns2.dav.bigpond.net.au) |
| 04:56.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 04:56.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:50.47 | *** join/#asterisk-dev |Cybex| (~John@atwork-21.r-212.178.82.atwork.nl) |
| 07:02.51 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 07:02.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:09.08 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:09.09 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:17.57 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 07:20.42 | *** join/#asterisk-dev sgimeno (~chatzilla@226.Red-80-33-64.staticIP.rima-tde.net) |
| 08:05.58 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 08:05.58 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:08.51 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:14.49 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:17.59 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:17.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:34.10 | oej | Morning folks |
| 09:50.56 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 10:23.57 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 10:23.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:15.02 | tzafrir_laptop | oej, but what do you think about character filterring at the channel driver level? |
| 11:15.27 | oej | It's easier to have one generic function than implement this in all the channel drivers... |
| 11:16.08 | tzafrir_laptop | Here's a stupid test case: |
| 11:16.53 | tzafrir_laptop | would there be any legitimate reason for me to use a "weird" extension from the manager interface through Originate? |
| 11:28.08 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:28.08 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:38.29 | *** join/#asterisk-dev pentanol (~pentanol@77.35.48.247) |
| 11:38.42 | pentanol | hi, anyone alive here? |
| 11:39.36 | pentanol | I need help with linking chan_sip.c with shared library, I just can't fount linking this source in any Makefile |
| 12:03.49 | tzafrir_laptop | pentanol, what library? Is it already used in Asterisk? |
| 12:04.06 | pentanol | no |
| 12:04.20 | pentanol | but, not, it used in cdr_radius |
| 12:05.57 | tzafrir_laptop | if it is already used, just add it to the moduleinfo section of chan_sip.c |
| 12:06.16 | pentanol | I've patched chan_sip, well it makes, but unfortunately received this chan_sip.so: undefined symbol: rc_conf_str |
| 12:06.20 | pentanol | yes |
| 12:06.25 | pentanol | I did it in this way |
| 12:06.44 | pentanol | WARNING[15951] loader.c: Error loading module 'chan_sip.so': /usr/local/asterisk-1.6.1.14/lib/asterisk/modules/chan_sip.so: undefined symbol: rc_conf_str |
| 12:06.59 | pentanol | I obtain it while loading asterisk |
| 12:07.23 | tzafrir_laptop | Does it show as a dependency of chan_sip in menuselect.makedeps ? |
| 12:08.36 | pentanol | no, I didn't this |
| 12:11.00 | pentanol | actually it shows dependensy radius lib with cdr_radius, and it exist there, i.e. I may setting it and building |
| 12:16.21 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 12:16.22 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 12:59.52 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 12:59.52 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 13:41.20 | pentanol | tzafrir_laptop any ideas? |
| 13:41.55 | pentanol | I found this ./makeopts:RADIUS_LIB= -lradiusclient-ng |
| 13:42.08 | pentanol | but anyway it won't work |
| 13:42.35 | tzafrir_laptop | pentanol, so the moduleinfo is wrongly cached somewhere? |
| 13:44.07 | pentanol | definitely not, I tries on different mahines |
| 13:44.13 | pentanol | machines* |
| 13:49.07 | kpfleming | have you modified chan_sip.c so that the build system knows it needs the RADIUS library? |
| 13:53.04 | pentanol | kpfleming of cource I've installer this library |
| 13:53.15 | pentanol | and I've got this... ./makeopts:RADIUS_LIB= -lradiusclient-ng |
| 13:53.24 | pentanol | after ./configure --prefix=/usr/local |
| 13:54.03 | pentanol | with cdr_radius it looks like works, but chan_sip, it doesn't |
| 13:55.30 | pentanol | also I can't fount somethinf sip related in Makefiles... grep -i sip channe*/Makefile Makefile |
| 13:56.07 | pentanol | or grep -i sip */Makefile* Makefile* |
| 13:58.32 | kpfleming | you did not answer my question at all |
| 13:58.45 | kpfleming | i asked if you modified chan_sip to tell the build system that it uses that library |
| 13:58.57 | kpfleming | the makefiles do not contain this information, it's in the module itself |
| 13:59.08 | kpfleming | so you are wasting your time looking at the makefiles |
| 13:59.46 | pentanol | agh, yep it's there ALL_C_MODS+=$(foreach p,$(MODULE_PREFIX),$(patsubst %.c,%,$(wildcard $(p)_*.c))) |
| 14:01.28 | pentanol | hm, where I may link this library? |
| 14:02.06 | pentanol | where linked chan_sip? |
| 14:02.32 | Corydon76-dig | You have to detect it in the configure script, then modify the top of chan_sip to tell it that radius is a dependency |
| 14:03.11 | kpfleming | pentanol: if you expect people to help you, you need to pay attention to the questions you are asked and answer them |
| 14:03.35 | kpfleming | the configure script already detects the library, and modifying chan_sip to be linked to it is a simple one line addition to the MODULEINFO block at the top of chan_sip.c |
| 14:04.02 | kpfleming | and you've been asked about that three times and not answered, which does not lead to people wanting to help you |
| 14:04.52 | pentanol | there exist <depend>chan_local</depend> |
| 14:05.01 | pentanol | it must be depend>chan_local, radius</depend> |
| 14:05.08 | pentanol | or depend>radius</depend> |
| 14:07.15 | kpfleming | the later |
| 14:07.52 | kpfleming | Corydon76-dig: would you mind adding a JIRA issue for the next sprint for someone to document the moduleinfo/linking/etc. stuff so we have a place to point people to? it seems this sort of question pops up about every week, and we rehash the same discussion every time |
| 14:08.25 | Corydon76-dig | kpfleming: depends. There are two different libraries that people generally use for radius, and if he's using the one we don't support, he'll need to detect it in the configure script |
| 14:08.30 | Corydon76-dig | Yes, I'll add an issue |
| 14:13.24 | Corydon76-dig | SWP-902 |
| 14:13.30 | kpfleming | no, i didn't mean radius specifically. i meant the process itself. |
| 14:15.01 | Corydon76-dig | I know |
| 14:15.23 | Corydon76-dig | Two different things I was responding to |
| 14:17.00 | oej | Oh no, there's a lock when we send RTCP reports in standard Asterisk 1.4 |
| 14:17.17 | oej | I'm listening to music on hold and there's a pause in the audio everytime Asterisk sends RTCP report... |
| 14:17.35 | oej | Must be some locking issue |
| 14:19.10 | oej | This is bad |
| 14:19.14 | Corydon76-dig | oej: Maybe. Are you using a Grandstream? /me ducks |
| 14:19.21 | oej | :-) |
| 14:19.34 | oej | I have a HP DL-380 quad core server, so that's not the problem |
| 14:19.44 | oej | I've tested with various sip softphones |
| 14:19.58 | oej | And clearly, we don't generate the music when sending RTCP reports, which is really, really bad. |
| 14:20.14 | oej | It's signals something even worse, a LOCKING issue somewhere |
| 14:21.45 | oej | I do not, do not, do not, do not, dig into this issue. I want to forget all about it. |
| 14:21.51 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:22.19 | oej | tries to forget that I heard glitches and saw what happened in wireshark. |
| 14:23.16 | Corydon76-dig | Is the channel in autoservice? |
| 14:26.15 | oej | I don't really know the definition of autoservice, but it's on musiconhold, which I think is autoservice. |
| 14:27.15 | Corydon76-dig | No, that's a generator |
| 14:27.43 | Corydon76-dig | autoservice is a separate thread that ensures the channel gets serviced when you're doing something that may take some time |
| 14:28.00 | Corydon76-dig | ast_autoservice_start() and ast_autoservice_stop() |
| 14:28.15 | russellb | which won't help if something is blocking holding a channel lock |
| 14:28.34 | russellb | analysis needs to be done on the RTCP code path to know where the delay occurs, and what locks are held at that time |
| 14:28.56 | russellb | otherwise we're playing blind darts |
| 14:29.09 | Corydon76-dig | Blind lawn darts? |
| 14:29.14 | russellb | heh, sure |
| 14:30.02 | Corydon76-dig | russellb: did you take a look at the road outside? |
| 14:30.17 | russellb | I drove in it for about 45 minutes |
| 14:30.23 | Corydon76-dig | ouch |
| 14:30.38 | russellb | before the sun had come up much, so _nothing_ was melted yet |
| 14:30.42 | russellb | it was thrilling. |
| 14:30.44 | Corydon76-dig | Utterly nasty |
| 14:30.54 | file | I call that fun. |
| 14:31.05 | russellb | you would, you crazy northerner |
| 14:31.12 | Corydon76-dig | file: that's because you're driving on _snow_, not ice |
| 14:31.19 | file | snow AND ice |
| 14:31.26 | file | or just ice. |
| 14:31.27 | file | it depends! |
| 14:31.30 | Corydon76-dig | Yes, well, here it's only ice |
| 14:31.43 | oej | We have it all, snow, ice, salt... |
| 14:31.45 | Corydon76-dig | Snow at least provides some measure of traction |
| 14:32.00 | oej | I agree with russell, we do have to dig down deep in the rtcp code path |
| 14:32.09 | Corydon76-dig | oej: it was raining last night, so the road crews couldn't put down a preemptive layer of salt |
| 14:32.24 | oej | It's triggered by a scheduler, but I don't really know in which thread. |
| 14:32.39 | oej | It's not in the chan_sip monitor thread. I think it would work better there or in a new thread |
| 14:32.55 | russellb | where is the line of code that calls ast_sched_add() ? |
| 14:33.04 | Corydon76-dig | Well, if it's a scheduler, it should be |
| 14:33.04 | oej | Or maybe it is... Hmm. |
| 14:33.08 | russellb | that will tell you which scheduler context (from which we can infer which thread) |
| 14:33.19 | oej | the context is rtp->sched |
| 14:33.32 | Corydon76-dig | Then that's the same as the monitor sched |
| 14:33.41 | oej | This is 1.4 |
| 14:33.49 | Corydon76-dig | Yep |
| 14:34.01 | Corydon76-dig | sched is passed in at creation of the rtp structure |
| 14:34.57 | oej | It is scheduled by whoever calls rtp_write |
| 14:35.24 | Corydon76-dig | shouldn't matter |
| 14:35.25 | russellb | There are no locks in those scheduler callbacks |
| 14:35.30 | russellb | which is actually a bit disturbing |
| 14:35.53 | russellb | Assuming that no other threads are going to touch the rtp structure outside of the SIP monitor thread is quite a poor assumption ... |
| 14:36.07 | oej | The scheduler is picked in ast_Rtp_new_with_bindaddr, so yes, it's the monitor. |
| 14:36.20 | oej | Yes, it is |
| 14:36.43 | russellb | so, the only lock held at that point is the monlock in chan_sip |
| 14:36.47 | oej | I checked with two servers and I can repeat. Just call in to musiconhold() and have RTCP reports often |
| 14:37.24 | russellb | innnnnnteresting |
| 14:37.35 | Corydon76-dig | oej: then I'd go with the autoservice, again. |
| 14:37.39 | oej | But it seems like seconds, and writing an RTCP report should not take seconds |
| 14:37.45 | russellb | Corydon76-dig: where? |
| 14:37.59 | russellb | Corydon76-dig: the channel thread is not off doing something |
| 14:38.08 | Corydon76-dig | Hmmm |
| 14:38.17 | russellb | oej: have you added any additional locking in your changes? |
| 14:38.30 | oej | This is a plain 1.4 - no changes |
| 14:38.34 | russellb | ok |
| 14:38.40 | oej | I was worried about my changes, so I switched back |
| 14:39.36 | oej | I thought I was safe, because I haven't added any new stuff in the basic RTCP functionality - the scheduled items are running as before. But locking hit again anyway ;-) |
| 14:39.50 | russellb | If it really is seconds, you could compile with DEBUG_THREADS, and during the temporary pause, run "core show locks" and see what you get |
| 14:40.05 | russellb | it might help provide insight, might not |
| 14:40.22 | oej | I'll give it a try |
| 14:40.23 | russellb | or make it core dump while it's stuck |
| 14:40.52 | Corydon76-dig | ast_cli_command(somefd, "core show locks"); |
| 14:49.20 | oej | Phone conference about SIPit - back later. THanks for your help. |
| 14:49.30 | russellb | np. |
| 14:55.21 | atis_work | Darn priorities, going back in queue :) |
| 15:02.56 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 15:02.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:05.42 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:05.43 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:30.56 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:30.56 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:31.13 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:31.13 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:45.45 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:45.45 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:56.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:59.46 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:59.46 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:16.06 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 16:16.57 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:21.19 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 16:21.38 | *** join/#asterisk-dev xpot-mobile (~xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 16:37.50 | *** join/#asterisk-dev korihor (~korihor@190.205.251.97) |
| 16:53.27 | *** join/#asterisk-dev jtodd (rbl2y3ye5k@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 16:53.27 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 17:16.00 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 17:24.47 | Corydon76-dig | I really must be getting old. I just had to go look up how to make a T1 crossover cable again |
| 17:28.09 | jsmith | www.asteriskdocs.org/cables/ |
| 17:28.24 | Corydon76-dig | jsmith: I googled it, and the cable is already done |
| 17:28.29 | jsmith | Swap 1+2 and 4+5, if I remember correct |
| 17:28.41 | Qwell | jsmith: That image needs that info |
| 17:28.43 | Corydon76-dig | Couldn't remember if it was 1 to 4 or 1 to 5 (the former) |
| 17:28.50 | Qwell | the 1>4, 2>5 or whatever |
| 17:29.03 | Qwell | that's how I remember ethernet crossover, and it makes things easy |
| 17:29.22 | Corydon76-dig | I remembered the pin outs, just not which to swap |
| 17:30.06 | Corydon76-dig | Also had to go search the tool shelves for my crimpers |
| 17:30.22 | Corydon76-dig | I don't crimp cables as often as I used to |
| 17:30.25 | kpfleming | i've never found that the polarity actually matters. the signals are differential anyway. |
| 17:31.48 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 17:31.48 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 17:32.17 | *** join/#asterisk-dev benngard (~benngard@90-230-92-67-no148.tbcn.telia.com) |
| 17:59.22 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 17:59.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:06.45 | benngard | hmm, weired stuff happens in trunk when u use tcpenable=yes and transport=tcp,udp in sip.conf together with qualify=yes |
| 18:08.26 | benngard | u can tons of "ast_tcptls_client_start: Unable to connect SIP socket to" when u restart * |
| 18:08.32 | benngard | can get* |
| 18:09.22 | benngard | and if i understand everything correct, all deviceses arr off until the try to register again |
| 18:21.36 | benngard | think i am talking in some kind of vacum here |
| 18:22.24 | benngard | anyway it is transport=tcp,udp that mess up a restart |
| 18:22.36 | seanbright | https://issues.asterisk.org/ |
| 18:24.01 | benngard | oki, thought that i could "talk" to some1 before i post so i didnt fu* up by myself |
| 18:24.45 | seanbright | well those with the domain knowledge aren't here or are otherwise occupied |
| 18:25.06 | seanbright | so you can try #asterisk if you feel it a configuration problem |
| 18:25.14 | seanbright | or issues.asterisk.org if you think it's a bug |
| 18:25.34 | benngard | i am to 99% sure it is a bug |
| 18:25.47 | seanbright | then issues.asterisk.org |
| 18:25.52 | benngard | oki |
| 19:17.23 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:43.08 | oej | Can't compile 1.4 with debug_threads on Linux... Ouch. |
| 19:43.38 | oej | benngard: a lot of the tcp code in chan_sip is a bug. I would avoid it. |
| 19:45.15 | oej | russellb: Still around? |
| 19:45.52 | oej | I guess there are holidays in the US... |
| 19:46.01 | oej | Hmm |
| 19:46.15 | Corydon76-dig | He's sick today |
| 19:46.20 | kpfleming | yes, but we are not on holiday today |
| 19:46.30 | Corydon76-dig | aka worshipping the ceramic goddess |
| 19:46.56 | oej | He was online earlier. I hope it's nothing serious. |
| 19:47.07 | Corydon76-dig | stomach bug, probably |
| 19:47.13 | oej | He recommended me to turn on DEBUG_THREADS to find an issue in 1.4 |
| 19:47.26 | oej | And it doesn't even compile on Linux with debug threads turned on... |
| 19:47.37 | Corydon76-dig | Where does it fail? |
| 19:47.48 | oej | I just opened an issue in the bug tracker |
| 19:48.04 | oej | M 16828 |
| 19:48.10 | oej | M16828 |
| 19:48.13 | MuffinMan | [new] [Asterisk] Utilities/aelparse 0016828: DEBUG_THREADS - Compile errors on OS/X and Centos Linux reported by oej https://issues.asterisk.org/view.php?id=16828 |
| 19:48.17 | seanbright | two different bugs |
| 19:48.25 | oej | ;-) |
| 19:48.36 | seanbright | one assumes that pthread_mutex_t is a simple type |
| 19:48.42 | kpfleming | did we make the utils stuff selectable in 1.4, or just in trunk? |
| 19:48.48 | seanbright | trunk |
| 19:48.51 | kpfleming | darn |
| 19:48.51 | oej | seanbright: Yes, that's the one on OS/X |
| 19:49.07 | seanbright | right, like i said, 2 bugs |
| 19:49.08 | Corydon76-dig | oej: compiles okay on Ubuntu |
| 19:50.02 | oej | Recompiling |
| 19:50.15 | oej | I would love to have utils stuff selectable in 1.4 |
| 19:50.40 | oej | Now I see. I had an old app_minivm on the linux system. |
| 19:50.49 | oej | at least a bad one |
| 19:51.03 | oej | Me bad. |
| 19:51.08 | oej | So the os/x bug remains |
| 19:51.18 | Corydon76-dig | I'm not terribly surprised that 1.4 won't compile on OS X |
| 19:52.09 | Corydon76-dig | It was always a secondary target, until 1.6 was released |
| 19:52.29 | oej | It has always compiled though |
| 19:52.30 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 19:53.24 | oej | Ok, now I can focus on the RTP/RTCP stuff that disturbed me earlier |
| 19:53.26 | Corydon76-dig | with DEBUG_THREADS, though? |
| 19:54.06 | oej | I don't think I have tried OS/X with DEBUG_THREADS earlier, so that might not have worked before... |
| 19:54.20 | oej | That assignment tells me that no one has dared trying it |
| 19:56.30 | Corydon76-dig | Do you actually run OS X in production? |
| 19:56.39 | *** join/#asterisk-dev ayrjola (~ayrjola@a88-115-162-170.elisa-laajakaista.fi) |
| 20:03.14 | oej | No, but I have one customer that does run the PBX on a mac mini |
| 20:03.33 | oej | Can't repeat that rtcp thing on Centos. Weird. |
| 20:03.45 | oej | Will try again tomorrow on the SUSE box |
| 20:08.19 | niekvlessert | btw i do a lot of stuff on macs, if you want me to try something, please don't hesitate to tell me |
| 20:12.56 | Corydon76-dig | niekvlessert: We can try on Macs just fine. Fixing it on Macs is another problem entirely. |
| 20:14.41 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 20:16.59 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:53.53 | *** join/#asterisk-dev philipp64 (~chatzilla@63.224.43.239) |
| 21:39.00 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:39.01 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:44.45 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 21:56.22 | *** join/#asterisk-dev Amorsen (~Amorsen@94.127.50.7) |
| 22:03.36 | *** join/#asterisk-dev outtolunc (~me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 22:45.16 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-124-177-30-127.lns2.dav.bigpond.net.au) |
| 23:20.15 | niekvlessert | ast_register_application_xml seems to exist in 1.4.22, not in 1.4.29. I want to apply a patch which needs it. Anyone? |
| 23:20.30 | russellb | it does not exist in any version of 1.4 |
| 23:20.51 | Kobaz | the xml stuff is only in 1.6.2 |
| 23:21.24 | niekvlessert | great answer, helped me a lot, just thought of the why :) |
| 23:21.24 | *** join/#asterisk-dev pentanol (~Unknown@91.195.60.231) |
| 23:21.33 | niekvlessert | ... it's not working |
| 23:22.39 | Kobaz | you can create one |
| 23:22.40 | Kobaz | er |
| 23:23.17 | niekvlessert | well I'm not yet up to that. I tried fixing a patch which didn't work... |
| 23:26.17 | niekvlessert | I now patched the connectedline stuff in 1.4.29 & sipremoveheader |
| 23:26.23 | niekvlessert | jay |
| 23:45.24 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:45.24 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:45.47 | Corydon76-dig | wonders where kpfleming disappeared to |
| 23:46.18 | Corydon76-dig | just fixed the Makefile bug Kevin was complaining about the other day |
| 23:49.11 | *** join/#asterisk-dev plundra (404@article.se) |