IRC log for #asterisk-bugs on 20110913

02:09.05*** join/#asterisk-bugs malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
02:09.05*** mode/#asterisk-bugs [+o malcolmd] by ChanServ
06:07.58*** join/#asterisk-bugs irroot (~irroot@41.55.100.233)
06:21.25*** join/#asterisk-bugs singler (~singler@81-7-123-162.static.zebra.lt)
07:28.05*** join/#asterisk-bugs oej (~olle@ns.webway.se)
08:13.06*** join/#asterisk-bugs singler (~singler@81-7-123-162.static.zebra.lt)
08:57.10*** join/#asterisk-bugs tzafrir_laptop (~tzafrir@local.xorcom.com)
09:38.57*** join/#asterisk-bugs Corydon76-home (eight@c-69-137-80-31.hsd1.tn.comcast.net)
09:38.57*** join/#asterisk-bugs pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger)
09:38.57*** mode/#asterisk-bugs [+oo Corydon76-home pabelanger] by niven.freenode.net
09:53.56*** join/#asterisk-bugs chazzam (~chazz@173-24-236-90.client.mchsi.com)
11:06.29*** join/#asterisk-bugs singler (~singler@81-7-123-162.static.zebra.lt)
13:04.09*** join/#asterisk-bugs malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
13:04.09*** mode/#asterisk-bugs [+o malcolmd] by ChanServ
13:04.55*** join/#asterisk-bugs malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
13:04.55*** mode/#asterisk-bugs [+o malcolmd] by ChanServ
13:05.14*** join/#asterisk-bugs serafie (~erin@nat/digium/x-wyniseayjkkuapfe)
14:26.34*** join/#asterisk-bugs dwayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net)
14:27.05*** join/#asterisk-bugs Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net)
14:27.05*** mode/#asterisk-bugs [+o Deeewayne] by ChanServ
15:27.04*** join/#asterisk-bugs irroot (~irroot@197.173.85.208)
16:00.38*** join/#asterisk-bugs oej_ (~olle@2001:470:1f15:d79:7995:ffb7:a471:2466)
16:11.31mnicholsonCorydon76-home, ping
16:16.15Corydon76-homemnicholson: pong
16:16.53mnicholsonfor ASTERISK-17709, why did you opt not to use string fields for the app_tmp changes?
16:16.56DocAwesome[ASTERISK-17709] [Status: In Progress] [Assigned: mnicholson] [patch] appdata truncated - https://issues.asterisk.org/jira/browse/ASTERISK-17709
16:19.25*** join/#asterisk-bugs bbryant (~brett@c-174-56-132-225.hsd1.sc.comcast.net)
16:19.25*** mode/#asterisk-bugs [+o bbryant] by ChanServ
16:19.27Corydon76-homeBecause I view stringfields as primarily having a benefit when you don't necessarily know the sizes in advance
16:19.45Corydon76-homeand when the values can change during the life of the structure in which stringfields are located
16:20.03Corydon76-homeSo CPU efficiency, basically
16:21.19Corydon76-homeOh, and I see a bug in the patch.  The ast_string_field_free_memory() needs to come before the ast_free()
16:23.48mnicholsonin the if (fast) { ast_free(fast); } part round line 4006?
16:24.31mnicholsonalso in your pbx.c changes, you don't account for appdata being null, but the old code does
16:25.31Corydon76-homeAh, another bug
16:25.46*** join/#asterisk-bugs singler (~singler@78-60-139-121.static.zebra.lt)
16:26.15Corydon76-homeRight, the strlen will segfault if appdata is null
16:26.54mnicholsoni don't know if appdata is ever actually null, but the old code handled that
16:27.02leifmadsenpabelanger: ping!
16:27.26Corydon76-homeIt could be, if parentheses are not used to delimit no arguments
16:29.47Corydon76-homeOr in this case, this is called with outgoing, so if it's not specified in the outgoing callfile/AMI/whatever, it'd be NULL
16:30.44mnicholsonright
16:34.46leifmadsenASTERISK-183530
16:35.13leifmadsenASTERISK-18530
16:35.16DocAwesome[ASTERISK-18530] [Status: Triage] improper use of host LDAP attribute value as ToHost sip client value - https://issues.asterisk.org/jira/browse/ASTERISK-18530
16:36.05leifmadsenthere is no 'tohost' option to sip.conf right?  This guy is reporting something about it for his LDAP. I'm wondering if his actual error is that Asterisk is trying to write to the ToHost field in his LDAP, but I'm not sure his bug report is complete enough to know what his "problem" is
16:38.56Corydon76-homeNone that I know of
16:39.44mnicholsonCorydon76-home, i'll fix your patch and commit it
16:40.00mnicholsonCorydon76-home, thanks for posting it
16:40.16Corydon76-homemnicholson: YW.  Thanks for reviewing it
16:42.15Corydon76-homeleifmadsen: I think he probably wants the IP address in the INVITE, instead of the hostname that comes back from the remote peer
16:42.37leifmadsenCorydon76-home: ok.... I still don't follow
16:43.23Corydon76-homeleifmadsen: Basically, the answer to him is that if he doesn't like how SIP works, he's welcome to work with the IETF to get the specification amended, but it's not a bug in Asterisk
16:43.44Corydon76-homeOr ask him to reproduce the problem with a non-realtime peer
16:44.06pabelangerleifmadsen: pong
16:45.26irrootmnicholson thx for looking at app_queue patch found one problem that ive fixed
16:46.12irrootill be rolling it out into high vol ACD user and see how it goes
16:48.02leifmadsenCorydon76-home: I don't think that's what he's saying. From the first paragraph, it looks like he is saying Asterisk is retrieving data from ToHost instead of AstAccountIPAddress
16:48.20Corydon76-homeleifmadsen: from the internal field in chan_sip. yes
16:48.35leifmadsenwhat internal field/
16:48.57Corydon76-homeIt's stored in the dialog/pvt, but not in the realtime backend
16:49.35pabelangerleifmadsen: ASTERISK-18535 is a regression and needs to be a 1.8.7.0 blocker
16:49.38DocAwesome[ASTERISK-18535] [Status: Triage] Asterisk 1.8.7.0-rc1: configure error (libpri related) - https://issues.asterisk.org/jira/browse/ASTERISK-18535
16:49.43leifmadsen"When asterisk gets user information from LDAP it fills value of last host attribute value to ToHost and after 'sip reload' and 'sip show peer gawriloff load' it requests this host instead of AstAccountIPAddress."
16:50.05leifmadsenwhich would be stored at ipaddr
16:52.47leifmadsenI don't get how 'host' is getting written to the LDAP record when it is defined in res_ldap.conf as AstAccountHost, with a value of dynamic
16:53.51mnicholsonirroot, np
16:54.17Corydon76-homeI'm not seeing the tohost field getting stored at ipaddr, unless it's through some convoluted process
16:54.27irrootyou killed it in the one place but fixup om masq still farqued
16:54.52mnicholsonirroot, yeah I saw that in there, does your patch fix that?
16:55.46*** join/#asterisk-bugs Devon_ (~chatzilla@63.214.236.169)
16:56.30Corydon76-homeleifmadsen: I think asking him to reproduce the problem with a static config (not realtime) is reasonable, though.  At least it would take the LDAP terms out of the equation, and you can determine whether this is a real bug or just a misunderstanding of how SIP works... or even a realtime bug.
16:57.17irrootmnicholson it does the problem is when queues is locked and then a chan is locked it breaks it as in try_calling i went step further and looked at all the places its locked it was previously a module lock pre ao2 so locking for checking members and the like no longer appliciable
16:57.59mnicholsonirroot, ok good. I wasn't sure how to fix the masq thing, as I couldn't do the same thing I did for the other place update_queues is called
17:02.49Corydon76-homeleifmadsen: the tohost field is what is in the 'host' realtime field, if not 'dynamic'.
17:05.54leifmadsensomething is still funky then. He's got host: defined twice in his LDAP output, and then AstAccountHost: dynamic (and host=AstAccountHost in res_ldap.conf), so it looks like it's loading the value of 'host' instead of the value of AstAccountIPAddress, which should be getting loaded due to AstAccountHost being set to dynamic
17:12.00Corydon76-homeToHost shouldn't be getting set at all, if host=dynamic, though
17:12.27Corydon76-homeRealtime doesn't actually update that field at all
17:30.53leifmadsenASTERISK-18396
17:30.57DocAwesome[ASTERISK-18396] [Status: Triage] Variables Truncated When Using Realtime Dialplan - https://issues.asterisk.org/jira/browse/ASTERISK-18396
17:31.06leifmadsenCorydon76-home: curious if that is a field length/maxlen problem?
17:42.48irrootASTERISK-18487 may likely be related to ASTERISK-18101 as per customer feedback / the BT posted
17:42.51DocAwesome[ASTERISK-18101] [Status: Open] Asterisk 1.8 Deadlock in app_queue - https://issues.asterisk.org/jira/browse/ASTERISK-18101
17:42.52DocAwesome[ASTERISK-18487] [Status: Triage] [Assigned: jlegault] Daily deadlock issue - https://issues.asterisk.org/jira/browse/ASTERISK-18487
17:44.10*** join/#asterisk-bugs elguero (~miguel323@2001:470:1f06:12c4::2)
17:44.46leifmadsenirroot: linked
18:15.47irroothi quick procedural question 1.8.x is the default release and i understand blockers there now when there is a beta release how are blockers determined as almost always a problem in 1.8 will be in 10 but as its not in gen circulation are blockers related to it only ??
18:17.12leifmadsenirroot: it could be applied to both sure
18:20.21irrootASTERISK-18325 there are atleast 2 other duplicates of this problem
18:20.25DocAwesome[ASTERISK-18325] [Status: Open] "Asked to transmit frame type" slows down all the calls - https://issues.asterisk.org/jira/browse/ASTERISK-18325
18:20.38leifmadsenyes I know there are a lot of them out there ;(
18:20.49leifmadsenit's hard to find all the duplicates and relate them when there are so many open issues
18:21.04irrootim looking i recently posted a patch
18:21.11Corydon76-homeleifmadsen: regarding ASTERISK-18396, it's definitely a field length problem, but where is the operative question
18:21.14DocAwesome[ASTERISK-18396] [Status: Triage] Variables Truncated When Using Realtime Dialplan - https://issues.asterisk.org/jira/browse/ASTERISK-18396
18:21.22leifmadsenCorydon76-home: indeed :S
18:21.37leifmadsenCorydon76-home: I asked the reporter for more information to try and figure out if it's the DB, or what
18:22.12irrootASTERISK-14384
18:22.15DocAwesome[ASTERISK-14384] [Status: Closed] Early media causes "Asked to transmit frame type 64, while native formats is 0x8 (alaw)(8)......" - https://issues.asterisk.org/jira/browse/ASTERISK-14384
18:23.00irrootASTERISK-17502
18:23.03DocAwesome[ASTERISK-17502] [Status: Closed] Flooding with chan_sip.c:6047 sip_write: Asked to transmit frame type alaw, while native formats is 0x100 (g729) read/write = 0x - https://issues.asterisk.org/jira/browse/ASTERISK-17502
18:23.19leifmadsenirroot: the first one you posted, the reporter is more reporting that the huge amount of console output slows down asterisk and wants it moved to ERROR and only show up once
18:23.21irrootASTERISK-18063
18:23.25DocAwesome[ASTERISK-18063] [Status: Open] Flooding with [Jun 24 19:33:17] WARNING[6995]: chan_sip.c:6213 sip_write: Asked to transmit frame type g726, while native formats is 0x4 (ulaw) read/write = 0x4 (ulaw)/0x4 (ulaw) - https://issues.asterisk.org/jira/browse/ASTERISK-18063
18:23.42irrootthe last one has a patch i use to avoid this problem
18:23.57Corydon76-homeleifmadsen: is the limit 512 characters?  I think I see where the problem lies
18:23.59irrootin some cases [dahdi] it causes a hangup
18:25.00leifmadsenCorydon76-home: in his case the strings are about 240chars
18:25.10irrootthe problem is the same and in some cases the error is output without a noticiable issue
18:25.27leifmadsenCorydon76-home: I linked another issue that may be related (affects pbx_lua)
18:25.35leifmadsenhe reports a length limit of 248 chars
18:25.40irrootso the poster may see it as a log flood when it is actually a error
18:26.52Corydon76-homeYeah, I know what the problem is
18:27.06Corydon76-homeIn this case, the problem lies in pbx_realtime
18:27.11leifmadsennice
18:27.25Corydon76-homeIt's still using the old method of a fixed buffer for variable substitution
18:39.35Corydon76-homeBTW, do we care whether the terminal output for appdata is limited to 256 characters or not, as long as the actual variables are unlimited?
18:43.01Corydon76-homeThe difference between 248 and 256 is the difference between the added (nonprinting) color codes embedded in the line that goes to the console
18:46.09leifmadsenCould we make it so it was obvious that it was being truncated? (like adding some ... to the end?) -- otherwise, I don't think I care. Just want the functionality to work
18:57.16Corydon76-homeNot easily, no
19:02.05leifmadsenok cool
19:10.47leifmadsenoh snap, DocAwesome died....
19:10.59leifmadsenwonder if it'll come back with' 5 mins like it should.... :S
19:23.42Corydon76-homeleifmadsen: there you go.  Go test.  :-P
19:35.30*** join/#asterisk-bugs blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage)
19:35.30*** mode/#asterisk-bugs [+o blitzrage] by ChanServ
20:23.26*** join/#asterisk-bugs zerohalo (~zerohalo@173-13-92-27-NewEngland.hfc.comcastbusiness.net)
20:24.17*** join/#asterisk-bugs zerohalo (~zerohalo@173-13-92-27-NewEngland.hfc.comcastbusiness.net)
20:40.29*** join/#asterisk-bugs DocAwesome (~DocAwesom@asterisk/documenteur-extraordinaire/blitzrage)
20:40.29*** mode/#asterisk-bugs [+o DocAwesome] by ChanServ
21:08.36*** join/#asterisk-bugs malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
21:08.36*** mode/#asterisk-bugs [+o malcolmd] by ChanServ
21:38.57*** join/#asterisk-bugs tzafrir_laptop (~tzafrir@bzq-218-155-147.cablep.bezeqint.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.