| 00:50.29 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 01:59.01 | *** join/#asterisk-bugs Deeewayne (i=dwayne@76.29.245.9) |
| 01:59.01 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 02:58.45 | *** join/#asterisk-bugs bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 02:58.45 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 04:06.34 | *** join/#asterisk-bugs mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 04:53.33 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 06:10.01 | *** join/#asterisk-bugs implicit (n=bayan@unaffiliated/implicit) |
| 06:10.01 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 06:46.45 | *** join/#asterisk-bugs bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 06:46.45 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 06:57.07 | *** join/#asterisk-bugs oej (n=olle@90-84-254-204.ip.sipit.net) |
| 07:02.31 | *** join/#asterisk-bugs implicit- (n=bayan@unaffiliated/implicit) |
| 07:02.31 | *** mode/#asterisk-bugs [+o implicit-] by ChanServ |
| 07:44.38 | *** join/#asterisk-bugs implicit (n=bayan@unaffiliated/implicit) |
| 07:44.38 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 08:16.04 | *** join/#asterisk-bugs implicit (n=bayan@unaffiliated/implicit) |
| 08:16.04 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 09:05.18 | *** join/#asterisk-bugs Karlitoo (n=serserve@213.137.110.67) |
| 09:06.40 | Karlitoo | hi all, I'm trying to login to Asterisk Configuration Engine but it doesn't let me log in with the username and password from the manager.conf file |
| 09:07.30 | *** part/#asterisk-bugs Karlitoo (n=serserve@213.137.110.67) |
| 11:33.57 | *** join/#asterisk-bugs implicit (n=bayan@unaffiliated/implicit) |
| 11:33.57 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 12:20.46 | *** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 12:20.46 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 12:21.07 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:54.14 | *** join/#asterisk-bugs bweschke (n=BJ_Wesch@74.94.3.214) |
| 13:21.51 | *** part/#asterisk-bugs Deeewayne (i=dwayne@76.29.245.9) |
| 13:26.30 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:26.31 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 13:30.29 | *** join/#asterisk-bugs juanjoc (n=juanjoc@OL4-215.fibertel.com.ar) |
| 14:37.55 | *** join/#asterisk-bugs De_Mon (i=de_mon@fl-67-77-166-5.dyn.embarqhsd.net) |
| 14:39.45 | *** join/#asterisk-bugs De_Mon (i=de_mon@fl-67-77-166-5.dyn.embarqhsd.net) |
| 14:55.32 | *** join/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-94cd14167ef67375) |
| 14:55.32 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 15:03.04 | *** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-aa9a23c34f59a604) |
| 15:03.04 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 15:12.57 | *** join/#asterisk-bugs codefreeze-lap (n=murf@72.21.67.40) |
| 15:34.33 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 15:34.39 | lmadsen | uhhhhhhhhhh.... interesting |
| 15:34.39 | lmadsen | chan_agent.c: In function ???agent_read???: |
| 15:34.39 | lmadsen | chan_agent.c:590: internal compiler error: in gen_reg_rtx, at emit-rtl.c:807 |
| 15:34.50 | lmadsen | gcc crashed when compiling in my virtual machine |
| 15:34.57 | Qwell | svn rm channels/chan_agent.c |
| 15:34.59 | Qwell | fixed |
| 15:35.04 | lmadsen | :) |
| 15:35.21 | Qwell | gcc crashing is never good |
| 15:35.26 | lmadsen | I would think not |
| 15:36.25 | lmadsen | wtf... now getting a bunch of these with ./configure |
| 15:36.27 | lmadsen | configure: WARNING: linux/videodev.h: present but cannot be compiled |
| 15:36.29 | lmadsen | configure: WARNING: linux/videodev.h: check for missing prerequisite headers? |
| 15:36.31 | lmadsen | this system is... messed up I guess |
| 15:36.36 | lmadsen | maybe I'll reboot it and see if it keeps doing it... |
| 16:42.10 | *** join/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 16:42.10 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 16:44.37 | putnopvut | M13703 |
| 16:44.40 | MuffinMan | [assigned] [Asterisk] Applications/app_queue 0013703: Abort in free in queue show <name> command reported by davidw (Karma: +1.50) http://bugs.digium.com/view.php?id=13703 |
| 16:45.29 | putnopvut | The reporter here has found an interesting problem, which is that queue names are hashed in a case-sensitive way, but since we directly try to find a queue based on user input (which may be case insensitive) from CLI and manager commands, it results in bad hashing. |
| 16:45.53 | Qwell | well...don't do that then? |
| 16:46.07 | putnopvut | So I'm wondering if it would be considered a "bad" thing to change queue names to be case-insensitive across the board, meaning that queue names which are the same except for case would be considered the same queue. |
| 16:46.41 | putnopvut | The other alternative that I can see, is to not use hashing when reading input from the user. |
| 16:46.43 | Qwell | typing in all-caps on the CLI is kinda dumb IMO |
| 16:47.02 | putnopvut | what does typing in all-caps have to do with this? |
| 16:47.25 | Qwell | QUEUE SHOW SOMERANDOMQUEUE |
| 16:47.33 | Qwell | seems silly |
| 16:48.51 | jsmith | likes the idea of case-insensitive queue names |
| 16:48.54 | Qwell | maybe I'm misunderstanding the issue |
| 16:53.52 | bweschke | putnopvut: +1 for case insensitive but I think you should handle it on th e backend |
| 16:54.29 | putnopvut | bweschke: what do you mean by "handle it on the backend?" |
| 16:54.58 | bweschke | putnopvut: when you get a queuename whethere from the cli, ami, .conf or whatever always send it to all upper or all lower |
| 16:54.59 | bweschke | ? |
| 16:55.14 | putnopvut | bweschke: yes, that was essentially the plan I had in mind. |
| 16:55.27 | bweschke | ya - I think that makes perfect sense |
| 17:09.33 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 17:43.52 | *** join/#asterisk-bugs implicit (n=bayan@unaffiliated/implicit) |
| 17:43.52 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 18:09.31 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 18:10.47 | *** join/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 18:10.47 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 18:14.50 | *** join/#asterisk-bugs Corydon76-dig (i=twelve@pdpc/supporter/bronze/Corydon76-home) |
| 18:14.50 | *** mode/#asterisk-bugs [+o Corydon76-dig] by ChanServ |
| 19:08.47 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 20:09.17 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 21:09.47 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 22:04.50 | *** part/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 22:58.44 | *** join/#asterisk-bugs tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 23:02.01 | *** join/#asterisk-bugs Skavin (i=kevins@202-180-69-27.me.tranzpeer.net) |
| 23:04.26 | Skavin | I have a question re chan_sip.c specificly sip_new anyone here at the moment? |
| 23:08.17 | Skavin | I will just comment and somone may come back |
| 23:08.58 | Skavin | teh name of a channel created by sip_new is of the format SIP/%s-%08x |
| 23:09.53 | Skavin | %s being the user name of the registered user as passd by title oe a valure created by sip_new from the fromdomain |
| 23:10.39 | Skavin | the title created from the fromdomain is teh text after any : |
| 23:12.30 | Skavin | so an invite from a trusted host that invites with a from of <123456@host.at.my.domain:5060> will have a channelid of the form of SIP/5060-..... |
| 23:13.57 | putnopvut | Skavin: yeah, it looks like you're correct. Have you seen any evidence of this occurring? |
| 23:14.19 | Skavin | yea I get this from a voip card on an Excel |
| 23:14.38 | Skavin | I have hacked it to use (title?title:ast_inet_ntoa(i->sa.sin_addr)) |
| 23:14.59 | Skavin | so I get SIP/ip-.... |
| 23:15.40 | Skavin | then I can do diffrent things in my dial plan depending on the source of the connection |
| 23:15.49 | *** join/#asterisk-bugs angler (n=angler@pdpc/sponsor/digium/angler) |
| 23:16.12 | putnopvut | Skavin: if I had to guess, I'd say that what was intended was to strip the port off the host and just use the domain name/IP address. |
| 23:16.21 | putnopvut | But I didn't write that so I can't be certain :) |
| 23:16.43 | putnopvut | But the opposite is what's happening, meaning that just the port is being used for the channel name, which I think is less than ideal. |
| 23:16.43 | Skavin | yea looks like it but strips whong part |
| 23:16.50 | *** join/#asterisk-bugs angler (n=angler@pdpc/sponsor/digium/angler) |
| 23:17.00 | Skavin | this is my fill quick hack |
| 23:17.03 | Skavin | tmp = ast_channel_alloc(1, state, i->cid_num, i->cid_name, i->accountcode, i->exten, i->context, i->amaflags, "SIP/%s-%08x", (title?title:ast_inet_ntoa(i->sa.sin_addr)), (int)(long) i); |
| 23:17.16 | Skavin | and remove the if |
| 23:17.40 | putnopvut | I can do an svn blame to see if there's some sort of commit message that explains the logic there. |
| 23:18.00 | Skavin | I assume i->sa.sin_addr is the udp source ip but could be wrong |
| 23:19.01 | putnopvut | Skavin: that's correct. i->sa is the source address, and i->recv is the IP address from which we received the SIP datagram, I believe. |
| 23:20.35 | putnopvut | I'm still doing the svn blame...it takes a while with chan_sip.c :) |
| 23:22.17 | Skavin | just remembered that rayj has the same issue from the Nextone SBC |
| 23:23.20 | Skavin | that is not a problem just geting a valid place where extensions.conf can see the sip peer its talking to would be good |
| 23:24.49 | putnopvut | Yeah, it appears that logic was added to solve a completely different issue which was reported, so unfortunately there's no real explanation in the svn log about why that code is like it is. I can ping codefreeze-lap about it and see if he remembers the logic he used there. |
| 23:25.44 | putnopvut | codefreeze-lap: ping. Do you happen to remember issue 7506? It's kind of old. But you added some logic to sip_new that Skavin is talking about here. I'm curious to know if you meant to isolate the port as the channel name or if you were trying to capture some other piece of information instead. |
| 23:27.17 | codefreeze-lap | putnopvut: The only thing that is both old and sip-pvt I can think of of, is forcing the channels to have a cdr at create time. To do that, you need the channel name (for the channel field). |
| 23:28.00 | putnopvut | okay, that's unrelated to what I'm talking about, as far as i know. |
| 23:28.38 | codefreeze-lap | Let me look |
| 23:29.16 | putnopvut | codefreeze-lap: the reason I'm pinging you is just because svn blame told me you were the last to alter the lines of code in question :) If you just moved the lines up or something, then oops. |
| 23:31.49 | codefreeze-lap | OK, what version ? 1.4? |
| 23:32.22 | putnopvut | codefreeze-lap: yes. |
| 23:32.38 | putnopvut | Specifically, it's the lines leading up to the ast_channel_alloc call in sip_new. |
| 23:32.59 | putnopvut | the lines which handle the logic behind setting the my_name variable. |
| 23:33.54 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 23:37.14 | codefreeze-lap | Right. See the call to ast_channel_alloc? That's what I had to change. You have to know what you're going to call the channel before you can allocate it. |
| 23:37.35 | codefreeze-lap | So I moved that code up |
| 23:38.31 | putnopvut | Okay, so then that code has been around for a while, then....hrmm, I want to change it, but I always feel uneasy changing code that old. |
| 23:38.36 | Skavin | yea but you are caling it the SIP/portnumber-xxxxx in the case that the from is of the form <12345@domain:port> |
| 23:40.04 | codefreeze-lap | Ha, I moved that code 2 years ago. Who knows how old it was then... might have been fairly fresh then... |
| 23:40.05 | Skavin | most sip implementations I have run into dont use :port |
| 23:41.03 | Skavin | I have just found the excel implementation and our upgraded nextone sometimes does it |
| 23:41.05 | codefreeze-lap | Skavin: it looks pretty funny domain, a smiley with a tongue sticking out, and 'ort', is what I see |
| 23:41.21 | Skavin | lol |
| 23:42.09 | putnopvut | silly smilies. |
| 23:42.13 | codefreeze-lap | you must be saying '.' and 'p' and its getting turned into a smiley! |
| 23:42.25 | putnopvut | close, it's a : and a P. |
| 23:42.55 | codefreeze-lap | what happens if you use a small p as in :p |
| 23:43.02 | codefreeze-lap | and a cap, :P |
| 23:43.11 | codefreeze-lap | looks the same to me either way |
| 23:43.13 | putnopvut | Same, I assume. |
| 23:43.45 | putnopvut | Anyway, I agree that the hostname/IP address makes much better sense for identifying the channel than the port. |
| 23:43.48 | Skavin | yea dont know how or if I can change formatting new to this irc client and have not used IRC since the 90s |
| 23:44.08 | putnopvut | So I think I'll go out on a limb and change the logic there. |
| 23:44.21 | putnopvut | If it turns out to be a bad idea, then it can be easily reverted later, I guess. |
| 23:44.41 | Skavin | I think the real ip source would be best as this is not able to be mangled or spoofed |
| 23:44.41 | codefreeze-lap | putnopvut: careful. You are jumping around in a minefield...! |
| 23:45.59 | putnopvut | Skavin: that's a different matter altogether, because while you avoid mangled/spoofed IPs in your channel names, you may also have privacy concerns that are addressed by the fromdomain. |
| 23:53.45 | Skavin | it realy depends what you are using channel name for and if it is presented to any external systems |
| 23:56.53 | Skavin | What I am realy after is a variabe exposed to extensions.conf with the source ip that the sip packets are comming from |
| 23:58.03 | Skavin | and in our network channel is the only place we have it and it was there 100% of the time for our trusted peers |
| 23:58.35 | Skavin | so we could use that to allocate max calls etc based on ip |
| 23:59.42 | Skavin | now we have a box that does not proved its IP in the from but domain but worse than that we get the port in the channel not even the domain |