| 02:09.18 | *** join/#asterisk-dev marv (~Tim@c-68-62-174-138.hsd1.al.comcast.net) |
| 02:10.29 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 02:10.29 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 03:19.08 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 04:39.14 | *** join/#asterisk-dev pyite (~dschreibe@unaffiliated/pyite) |
| 04:50.09 | *** join/#asterisk-dev pyite (~dschreibe@unaffiliated/pyite) |
| 06:26.00 | *** join/#asterisk-dev niekvlessert_ (~niek@5ED25657.cable.ziggo.nl) |
| 08:24.19 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:24.19 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:42.53 | *** join/#asterisk-dev codefreeze-lap (~murf@mail.parsetree.com) |
| 08:42.53 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 09:04.30 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:50.25 | tzafrir | origsvn.digium.com is signed by a MD5 certificate . Newer Linux distributions don't like such certificates, I believe |
| 10:36.16 | tzafrir | "modern": current Debian Testing . I gather that also Fedora 12 |
| 10:41.43 | *** join/#asterisk-dev kerframil (~kerframil@gentoo/user/kerframil) |
| 11:22.27 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 11:27.30 | snuff-home | mm it is tzafrir .. interesting |
| 11:27.53 | snuff-home | most ppl replaced em after that last 'collision' with md5 was found |
| 11:29.26 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:29.26 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:51.49 | *** join/#asterisk-dev vrban (~chatzilla@p50997436.dip0.t-ipconnect.de) |
| 13:45.14 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:46.49 | *** join/#asterisk-dev Rem| (~remi@209.191.13.247) |
| 13:51.43 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 14:07.17 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 14:14.56 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:14.57 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:35.22 | jsmith | Anybody around that understands overlap dialing enough to explain it to me, so that I can document it better? If so, please hop over to #asterisk-doc and share your knowledge! |
| 15:03.28 | *** join/#asterisk-dev codefreeze-lap (~murf@mail.parsetree.com) |
| 15:03.28 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 15:12.48 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:12.48 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:16.33 | *** join/#asterisk-dev moy (~chatzilla@74.12.129.100) |
| 15:27.47 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 15:37.59 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:37.59 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:46.50 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:46.50 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:49.16 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:49.16 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:51.36 | jpeeler | tzafrir: if you don't have any additional input for 14163, i'm going to commit it. it seems fine |
| 15:54.17 | tzafrir | jpeeler, apart from obvious minor style issues, |
| 15:54.42 | jpeeler | ok, thanks |
| 15:59.32 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-audtvbkngegpuyac) |
| 16:15.54 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:15.54 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:18.22 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:29.28 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 16:30.04 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 16:31.46 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:46.40 | *** join/#asterisk-dev alecdavis (~alec@202-78-149-14.cable.telstraclear.net) |
| 16:47.05 | alecdavis | M16950 |
| 16:47.07 | MuffinMan | [assigned] [LibPRI] General 0016950: PRI i-frames sent out of order, causing REJ supervisory frame reported by alecdavis https://issues.asterisk.org/view.php?id=16950 |
| 16:48.33 | alecdavis | the evidence is there, now to find the bug. |
| 16:50.08 | alecdavis | those more familiar with libpri may be able to spot the issue immediately. There's only 2 of them isn't there. MF and RM. |
| 16:53.37 | alecdavis | morning all. or is it nearly lunch time. Haven't had my breakfast yet. |
| 17:03.40 | jsmith | alecdavis: noon Eastern time, 11:00am Huntsville time |
| 17:03.48 | jsmith | hasn't had breakfast yet either :-( |
| 17:05.59 | leifmadsen | ya, noon here, and I'm gonna need lunch soon enough |
| 17:06.04 | leifmadsen | I never skip breakfast anymore |
| 17:13.31 | alecdavis | 06:13am |
| 17:13.44 | alecdavis | NZDT |
| 17:15.58 | leifmadsen | alecdavis: it's early there! |
| 17:16.06 | alecdavis | is see rmudgett is monitoring 16950, bet he want's this one fixed. don't all we. |
| 17:16.36 | leifmadsen | alecdavis: I even work with some people in New Zealand, so I have my google calendar setup to show me your local time it seems (beside my local time) |
| 17:16.41 | alecdavis | I know, couldn't sleep after tracking down evidence in above forementioned bug. |
| 17:17.02 | leifmadsen | M16950 |
| 17:17.04 | MuffinMan | [assigned] [LibPRI] General 0016950: PRI i-frames sent out of order, causing REJ supervisory frame reported by alecdavis https://issues.asterisk.org/view.php?id=16950 |
| 17:17.27 | leifmadsen | I think I need to remove the auto-assign on libPRI |
| 17:23.26 | alecdavis | I'm sure 2 of the calls that were tearing down were being bridged by asterisk, this happens alot as asterisk is an IVR between our TELCO and our Legacy PABX. I need to go through the logs and report back to the bug. |
| 17:35.27 | *** join/#asterisk-dev paulc (~paulc@unaffiliated/paulc) |
| 17:39.53 | *** join/#asterisk-dev jtodd (dixad9fiax@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 17:39.53 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 17:53.38 | *** join/#asterisk-dev |Rain| (rain@ev.il.net) |
| 17:59.01 | tzafrir | M16906 |
| 17:59.02 | MuffinMan | [acknowledged] [Asterisk] Resources/res_musiconhold 0016906: moh files install under datadir, at runtime: under varlibdir reported by tzafrir https://issues.asterisk.org/view.php?id=16906 |
| 17:59.26 | tzafrir | so is it datadir or varlibdir? |
| 18:06.17 | Qwell | tzafrir: I would think datadir. Since nobody has reported this before, I would say you're the first to actually change it. |
| 18:07.03 | tzafrir | change it? notice it? (I prefer datadir as well) |
| 18:07.26 | Qwell | If I understand the problem - anybody who changed it would have noticed it |
| 18:09.04 | Qwell | What does the sounds dir point to? |
| 18:09.27 | Qwell | sounds uses datadir, so moh should too |
| 18:09.37 | *** part/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 18:09.41 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 18:09.41 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 18:13.05 | tzafrir | Qwell, it's that way since the switch to relative pathes |
| 18:13.24 | tzafrir | A149917 |
| 18:13.45 | tzafrir | rev 149917, anyway |
| 18:16.57 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:27.50 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 18:27.50 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:28.20 | *** part/#asterisk-dev alecdavis (~alec@202-78-149-14.cable.telstraclear.net) |
| 18:42.18 | ctooley | The codec negotiation patch at "http://www.rtpproxy.org/wiki/AsteriskCodecNegotiationPatch" has been applied to our 1.4 installations. Is there still a need for this in 1.6.2? I think this is worked out as a result of the work done. |
| 18:42.51 | ctooley | s/work done/work done at the dev con last year/ |
| 18:46.37 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 18:47.13 | russellb | Not much has changed in the area of codec negotiation architecture ... |
| 18:47.44 | russellb | whether there is a need for a patch is defined by your own requirements, I suppose |
| 18:47.57 | russellb | I'm just saying that the behavior in that area is not going to be vastly different in 1.6.2 from 1.4 |
| 18:54.29 | Kobaz | M16618 |
| 18:54.32 | MuffinMan | [acknowledged] [Asterisk] PBX/pbx_config 0016618: [regression] pbx_config does not load when it should reported by kobaz https://issues.asterisk.org/view.php?id=16618 |
| 18:55.43 | seanbright | you can PM the bot to get that information as well |
| 18:55.54 | seanbright | /msg MuffinMan M16618 |
| 18:57.31 | Kobaz | k |
| 19:16.09 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:06.02 | seanbright | does 250565 |
| 20:06.07 | seanbright | affect ABI? |
| 20:06.14 | seanbright | and if so, do we care? |
| 20:13.01 | *** join/#asterisk-dev alecdavis (~alec@210.48.127.227) |
| 20:20.37 | putnopvut | commit asteirsk 250565 |
| 20:20.39 | MuffinMan | Failed to retrieve information on revision 250565 from repository asteirsk |
| 20:20.47 | putnopvut | doh |
| 20:20.50 | putnopvut | commit asterisk 250565 |
| 20:20.53 | MuffinMan | [250565] Committed by rmudgett on 2010-03-03T19:38:06.043354Z: Removed cdrflags from ast_channel structure. |
| 20:20.53 | MuffinMan | .. |
| 20:20.53 | MuffinMan | ..Only chan_dahdi set a value in cdrflags. Everyone else just copied it |
| 20:20.53 | MuffinMan | ..around the system. Noone cared about any value it may have contained. |
| 20:20.54 | MuffinMan | .. |
| 20:20.56 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=250565 |
| 20:21.22 | putnopvut | Yes, that certainly does, but I don't think we care because it was done in trunk only, and trunk already has ast_channel-related ABI changes. |
| 20:21.30 | Qwell | well, it is trunk.. |
| 20:21.54 | putnopvut | That's fairly minor compared to the ast_channel ao2 changes... |
| 20:25.04 | Kobaz | mmm |
| 20:25.26 | Kobaz | the local channel originate regression in 1.6.0.20+ is still killing me |
| 20:26.03 | seanbright | Kobaz: patches welcome |
| 20:26.12 | seanbright | putnopvut: Qwell: thanks. just checking. |
| 20:26.34 | Kobaz | heh |
| 20:26.35 | Kobaz | yeah i know |
| 20:26.41 | Kobaz | i'm not sure where to start |
| 20:26.50 | Kobaz | i'm not familiar with any of the low level channel stuff |
| 20:27.00 | Kobaz | and i'm too busy writing unit tests for my apps |
| 20:29.25 | seanbright | ah well |
| 20:29.48 | seanbright | then just keep randomly dropping hints |
| 20:29.51 | seanbright | people love that. |
| 20:29.52 | Kobaz | hehe |
| 20:30.03 | Kobaz | eating lunch. sec |
| 20:31.26 | Kobaz | M16628 |
| 20:31.28 | MuffinMan | [assigned] [Asterisk] Resources/res_clioriginate 0016628: [regression] Originate not launching secondary channel when primary is a Local channel reported by kobaz https://issues.asterisk.org/view.php?id=16628 |
| 20:40.39 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 21:00.08 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 21:00.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:22.30 | *** join/#asterisk-dev niekvlessert_ (~niek@5ED25657.cable.ziggo.nl) |
| 21:43.58 | kpfleming | quiet in here today |
| 21:44.20 | russellb | bunch of fools doing work instead of chatting ... |
| 21:45.15 | leifmadsen | or ping-pong |
| 21:45.17 | putnopvut | dammit, you broke the slience! Now we have to start over! |
| 21:47.50 | niekvlessert_ | although a lot of people in the channel |
| 21:50.31 | |Rain| | all of them spies! |
| 21:52.37 | seanbright | i am not talkative, but it has nothing to do with "doing work" |
| 21:54.29 | *** join/#asterisk-dev philipp64 (~chatzilla@mail.redfish-solutions.com) |
| 21:59.58 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 21:59.58 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- IAX2 is now RFC 5456. |
| 22:02.02 | mvanbaak | wedhorn: nice work |
| 22:02.30 | atis_work | anybody objects in replacing ast_channel_free() with ast_hangup() within ast_pbx_outgoing_cdr_failed()? |
| 22:03.09 | atis_work | otherwise there's inconsistency with events. If spooled call fails there's event of created channel but no event of it's end |
| 22:03.28 | atis_work | or better to remove event generation for this temporary channel? |
| 22:08.21 | *** join/#asterisk-dev jameswf (~james@unaffiliated/jameswf-home) |
| 22:10.04 | *** join/#asterisk-dev hasanakgoz (~hasanakgo@81.215.204.120) |
| 22:13.40 | Kobaz | are there events sent when the channel is spawned? |
| 22:13.50 | *** part/#asterisk-dev hasanakgoz (~hasanakgo@81.215.204.120) |
| 22:13.59 | atis_work | Kobaz: Yup, Newchannel is sent |
| 22:14.17 | atis_work | altough, it may not be valid for trunk, there's ast_dummy_channel_alloc |
| 22:14.40 | Kobaz | if a newchannel is sent, the appropriate hangup events should be sent as well |
| 22:14.50 | atis_work | I think I could hack event sending, as it relies on ast_strlen_zero(name_fmt) |
| 22:15.35 | atis_work | well, yeah.. i got event's represented in SQL as insert's and delete's, so i found that there's lot of empty rows coming from this |
| 22:16.54 | Kobaz | interesting |
| 22:17.29 | Kobaz | do you delete out all the events from your table related to a channel when it's hung up>? |
| 22:17.46 | Kobaz | 59152... 71826... going going |
| 22:17.49 | Kobaz | re |
| 22:17.53 | atis_work | yup, so there's no Hangup event.. |
| 22:18.03 | atis_work | i traced it to ast_pbx_outgoing_cdr_failed() |
| 22:18.16 | Kobaz | there should be a hangup for every associated newchan |
| 22:18.34 | atis_work | strange, i don't get where's the name_fmt passed to ast_channel_alloc |
| 22:18.47 | atis_work | it shouldn't generate event if there's no name_fmt |
| 22:21.47 | atis_work | umm, is there good way how to check for "%s", "" in name_fmt and VA_ARGS |
| 22:22.03 | Kobaz | what are you trying to do |
| 22:23.11 | atis_work | ast_channel_alloc(... "%s", "") |
| 22:23.23 | atis_work | i probably have to check for printf processed value |
| 22:24.26 | mvanbaak | <PROTECTED> |
| 22:28.11 | atis_work | ok, so the fix is: !ast_strlen_zero(name_fmt) && !ast_strlen_zero(tmp->name) |
| 22:28.21 | atis_work | added second condition for sending event |
| 22:36.40 | atis_work | M16957 |
| 22:36.42 | MuffinMan | [new] [Asterisk] Core/PBX 0016957: [patch] Rogue Newchannel events for failed Originate calls reported by atis https://issues.asterisk.org/view.php?id=16957 |
| 22:36.47 | atis_work | ready to be fixed :) |
| 22:37.50 | snuff-work | kpfleming: ping? |
| 22:37.55 | kpfleming | pong |
| 22:38.28 | snuff-work | i found a way to fix the 'stringfields' alignment thing.. using your 'get_unaligned_uint16' |
| 22:38.54 | snuff-work | for the get stringfield allocation macro |
| 22:39.38 | snuff-work | only have 2 small alignment issues with iax.. and few dundi.. and res_rtp_ast |
| 22:40.12 | kpfleming | huh |
| 22:40.39 | kpfleming | really, though, it seems like it would be better to construct the structures properly at compile time so that they will be properly aligned. unaligned accesses are slow. |
| 22:41.55 | snuff-work | well stringfields is being 'tricky'.. |
| 22:42.37 | snuff-work | by storing the length of the string in a uint16 infront of the string |
| 22:42.42 | kpfleming | correct |
| 22:42.53 | kpfleming | which means that the base address for that combination should be int16-aligned |
| 22:43.04 | kpfleming | with a byte of padding in front of it if necessary |
| 22:43.48 | snuff-work | but from memory it is aligned explictly in the definition.. |
| 22:43.54 | kpfleming | and we could have an appropriate structure definition for an individual string in a stringfield pool so that there can be a pointer to the proper type |
| 22:44.04 | kpfleming | i don't understand |
| 22:45.06 | snuff-work | could be misreading something |
| 22:46.27 | snuff-work | nope i must be imagining things again |
| 22:47.03 | kpfleming | this could be one of those cases where we are properly aligning the value in memory, but the compiler does not know that |
| 22:47.14 | snuff-work | i think that is the case.. |
| 22:57.36 | snuff-work | kpfleming: http://pastebin.ca/1822000 |
| 22:57.43 | snuff-work | current align issues |
| 22:59.24 | kpfleming | sorry, reading some complex documents right now, can't focus that much on something else |
| 22:59.26 | snuff-work | the res_rtp_ast mainly relate to the use of a char buffer casting as int.. which i have a fix for |
| 22:59.29 | snuff-work | np |
| 23:47.32 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 23:47.32 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |