| 00:32.56 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:32.56 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 00:58.31 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:58.31 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 01:37.21 | *** join/#asterisk-bugs elguero (n=elguero@ns1.nashuacs.com) |
| 02:01.11 | *** join/#asterisk-bugs tuxd00d (n=tuxd00d@128.187.132.25) |
| 04:08.26 | *** join/#asterisk-bugs fakhir_ (n=fakhir@unaffiliated/fakhir) |
| 05:38.08 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:38.08 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 05:51.34 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:51.34 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 06:35.22 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 07:40.44 | *** join/#asterisk-bugs jsmith-teaching (n=jsmith@208.113.13.58) |
| 07:40.44 | *** mode/#asterisk-bugs [+o jsmith-teaching] by ChanServ |
| 11:23.00 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:23.00 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 12:07.13 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:28.43 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 13:28.43 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 13:57.22 | *** join/#asterisk-bugs codefreeze (n=steve_mu@216.166.159.235) |
| 13:57.22 | *** mode/#asterisk-bugs [+o codefreeze] by ChanServ |
| 14:10.55 | putnopvut | M12392 |
| 14:10.56 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0012392: asterisk handles 488 responses after initial invite incorrectly reported by fnordian http://bugs.digium.com/view.php?id=12392 |
| 14:11.16 | file | I thought you would ask about that |
| 14:11.24 | putnopvut | This seems like a simple-enough patch, but I'm not willing to commit it just yet because I don't understand the purpose of the SIP_ALREADYGONE flag. |
| 14:11.37 | putnopvut | file: get out of my head!! |
| 14:12.49 | file | is this the initial invite, or a reinvite? |
| 14:13.24 | putnopvut | I believe it is the initial invite. |
| 14:13.51 | putnopvut | because the case for which the patch is written will be reached if "reinvite" is 0. |
| 14:14.10 | putnopvut | Or actually, I guess it could be 1... |
| 14:14.14 | file | it could be 1. |
| 14:14.17 | putnopvut | odd logic used in the 488. |
| 14:15.04 | file | so if it's not a reinvite, you don't want to send a BYE - if it is, you do |
| 14:15.28 | putnopvut | Makes sense. |
| 14:15.44 | putnopvut | In other words, if it's outside of a dialog, there's no dialog to end. |
| 14:15.48 | file | nods |
| 14:16.16 | putnopvut | So the patch should be modified to have if (!reinvite) prior to the line added by the reporter. |
| 14:16.21 | file | nods |
| 14:17.04 | putnopvut | So the ALREADY_GONE flag is a means of saying not to send a BYE? Is that its sole purpose? It's not 100% clear just from a quick glance at the code. |
| 14:17.51 | file | it means the dialog has already been ended in the eye of the other side, and we don't need to tell them to end it |
| 14:18.09 | putnopvut | Ah, all right. |
| 14:18.43 | putnopvut | I guess it's also a way of saying that there is no dialog established. |
| 14:43.27 | file | putnopvut: good good |
| 14:43.29 | file | putnopvut: anything else? |
| 14:44.00 | putnopvut | file: yes, I'll probably be asking you about several other bugs as I come across them. |
| 14:44.19 | putnopvut | Mainly, the questions will be chan_sip-related as opposed to sip protocol-related. |
| 15:16.02 | file | Corydon76-dig: I believe the guy who you responded to about SIGHUP with his AGI... just posted a bug |
| 15:16.03 | file | M12395 |
| 15:16.05 | MuffinMan | [new] [Asterisk] . I did not set the category correctly. 0012395: Can´t trap SIGHUP signal in eagi script reported by equissoftware http://bugs.digium.com/view.php?id=12395 |
| 15:20.28 | Corydon76-dig | file: yeah, it's not an Asterisk bug |
| 15:20.45 | Corydon76-dig | I can trap it just fine in Perl |
| 15:34.01 | Juggie | eagi supports ignoring sighup? |
| 15:34.09 | Juggie | i dont know if that was ever intended. |
| 16:01.26 | *** join/#asterisk-bugs DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 16:18.23 | Corydon76-dig | Juggie: not ignoring so much as catching |
| 16:18.44 | Corydon76-dig | EAGI still cuts you off from further interaction |
| 16:44.17 | *** part/#asterisk-bugs jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 16:51.56 | *** join/#asterisk-bugs jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 17:14.32 | Juggie | right, but if the channel is hung up you dont really have eagi anymore then you have a deadagi. |
| 17:18.50 | *** part/#asterisk-bugs jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 17:46.58 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 18:03.48 | *** join/#asterisk-bugs jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 18:12.12 | *** part/#asterisk-bugs jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 19:49.27 | putnopvut | M12391 |
| 19:49.28 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0012391: route information is lost for incoming calls before sending BYE reported by benjaminbohlmann http://bugs.digium.com/view.php?id=12391 |
| 19:49.52 | putnopvut | After looking in RFC 3261 and reading the reporter's analysis, I agree with what he's doing here. |
| 20:00.17 | file | old old code... |
| 20:00.19 | file | M1491 |
| 20:00.21 | MuffinMan | [closed] [Asterisk] Core/General 0001491: Record-Route not being properly handled reported by gdalgliesh http://bugs.digium.com/view.php?id=1491 |
| 20:05.22 | putnopvut | Yes, I did an svn blame and saw it was from revision 2700 or so. |
| 20:31.10 | putnopvut | I guess what I was looking for here was confirmation on this. It makes sense to me to create the route set on the first invite, whether it is the request itself or the response (we appear to only set the persistant_route [sic] variable if we receive an INVITE response). |
| 20:37.29 | file | putnopvut: make it so. |
| 20:37.41 | putnopvut | It shall be done. |
| 20:55.53 | *** join/#asterisk-bugs NirS (n=NirS@87.68.3.201.cable.012.net.il) |
| 20:55.57 | NirS | hey all |
| 20:56.23 | NirS | I need some assistance with something that I think may be a bug, or maybe I'm not understanding how chan_local is supposed to work |
| 20:56.25 | NirS | can someone assist ? |
| 21:00.09 | putnopvut | NirS: what seems to be the problem? |
| 21:00.20 | NirS | well, here's the deal |
| 21:00.35 | *** join/#asterisk-bugs jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 21:00.36 | NirS | <PROTECTED> |
| 21:00.47 | NirS | Once the local channel had answered, I'm performing a Dial from that context to an outbound number |
| 21:00.54 | NirS | Once the call is connected to the outbound number, I'm seperating seperating the channels, disconnecting the local channel, and having the physical (SIP/IAX2) channel redirect into a new context |
| 21:01.01 | NirS | within the new context, I'm dialing a new number, with the L parameter defined in the dial command |
| 21:01.10 | NirS | <PROTECTED> |
| 21:01.18 | NirS | it doesn't sound off the warning sounds, although, these were defined |
| 21:01.56 | putnopvut | holy crap that's complicated. |
| 21:02.43 | mvanbaak | it sure is |
| 21:03.03 | putnopvut | I would expect the sounds to be played to the caller. There's no telling which step amongst those is the broken link in all this. |
| 21:03.06 | mvanbaak | why not use the L in the exten you originate to |
| 21:04.09 | NirS | I did that too, doesn't help |
| 21:04.28 | NirS | it would appear that no matter where the L is located, it doesn't play the sounds back |
| 21:10.37 | putnopvut | NirS: does this also happen on a simple call to a phone directly connected? |
| 21:11.23 | NirS | no |
| 21:11.27 | NirS | just in this scenario |
| 21:12.02 | NirS | what are the chances that the channel variables are not copied using the local channel proxy ? |
| 21:12.05 | NirS | and that it break ? |
| 21:12.08 | NirS | breaks that is |
| 21:12.42 | putnopvut | You're setting the sounds as channel variables? |
| 21:13.02 | putnopvut | Did you try prepending __ to the beginning of the channel variables? |
| 21:14.41 | NirS | yes |
| 21:14.51 | NirS | not the sounds |
| 21:15.08 | NirS | the CALL_LIMIT variables, used by the L parameter of dial |
| 21:21.59 | putnopvut | NirS: I guess the short answer to this is that you most likely have found a bug, so you should file a bug report. Make sure to be very detailed with the explanation of the call flow since this is pretty complicated. |
| 21:22.38 | NirS | ok, I'll do my best |
| 21:22.45 | putnopvut | NirS: great, thanks! |
| 21:22.47 | NirS | what catergory should I put this on? |
| 21:22.51 | NirS | chan_local ? |
| 21:23.15 | putnopvut | NirS: good question. Yeah, that sounds right. It can be recategorized later if it turns out to be a problem elsewhere. |
| 21:23.30 | NirS | ok |
| 21:37.01 | NirS | ok, in the tracker: 12399 |
| 21:38.11 | NirS | btw, is it my imagination, or has app_voicemail undergone some massive updates lately ? |
| 21:38.20 | NirS | my hebrew patch no longer works on it properly |
| 21:39.14 | putnopvut | I wouldn't say it's been through any massive updates lately. There have been a few new features added in the last few days though. |
| 21:40.23 | NirS | well, these new features throw my patch into the shit ! |
| 21:40.31 | NirS | I now need to do some massive re-writes |
| 21:40.43 | NirS | well, corydon didn't accept my previous patch, maybe this one will make it |
| 21:47.54 | mvanbaak | NirS: that happens from time to time |
| 21:48.37 | mvanbaak | NirS: I maintain a branch to make multiple parking contexts in the default callparking stuff. the changes in trunk made me redo the patch twice already |
| 21:49.06 | NirS | bummer |
| 21:58.47 | mvanbaak | that's what it takes in OS |
| 21:59.04 | mvanbaak | if your patch is not in the mainline dev trees, you have to fix it from time to time |
| 22:06.17 | NirS | yes I know |
| 22:06.39 | NirS | the thing is, that this patch isn't just a simple feature patch |
| 22:06.48 | NirS | it's adding a completely new language support to Asterisk |
| 22:07.19 | NirS | the hebrew support is Asterisk sucks big time, actually, it is so bad that from a linguistic point of view, it is unuseable |
| 22:07.46 | NirS | Multiple people in Israel are selling binary compiled versions of Asterisk with hebrew support, totally violating the GPL code |
| 22:08.14 | NirS | I'm the israeli user group founder and maintainer, and it drives me crazy when people do that |
| 22:11.23 | NirS | ever encountered this compilation error: |
| 22:11.23 | NirS | checking for C compiler default output file name... b.out |
| 22:11.23 | NirS | checking whether the C compiler works... configure: error: cannot run C compiled programs. |
| 22:15.14 | mvanbaak | hhmm, they left |
| 22:15.22 | mvanbaak | they should install build-essential |
| 22:15.44 | *** join/#asterisk-bugs NirS (n=NirS@87.68.3.201.cable.012.net.il) |
| 22:16.05 | NirS | anyone has an idea what this means ? |
| 22:16.06 | NirS | <PROTECTED> |
| 22:16.14 | NirS | checking whether the C compiler works... configure: error: cannot run C compiled programs. |
| 22:16.37 | NirS | I compiled Asterisk on this machine just fine a few days ago |
| 22:28.00 | NirS | never mind that |