| 00:50.30 | *** join/#asterisk-dev micols (~mio@rlogin.dk) |
| 00:56.40 | *** join/#asterisk-dev micols (~mio@rlogin.dk) |
| 01:13.46 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 01:13.46 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 02:24.09 | *** join/#asterisk-dev moy (~moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 02:51.46 | *** join/#asterisk-dev moy (~moy@74.12.130.209) |
| 03:09.53 | *** join/#asterisk-dev wdbl (~not@ool-44c0668f.dyn.optonline.net) |
| 03:23.10 | *** join/#asterisk-dev lmsteffan (~laurent@reef.ac-noumea.nc) |
| 03:23.15 | *** join/#asterisk-dev lmsteffan_ (~lmsteffan@reef.ac-noumea.nc) |
| 03:25.06 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 03:25.06 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 03:25.55 | *** join/#asterisk-dev wdbl (~not@ool-44c0668f.dyn.optonline.net) |
| 05:21.41 | *** join/#asterisk-dev philipp64 (~chatzilla@mail.redfish-solutions.com) |
| 05:31.07 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 05:31.07 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:10.24 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:10.24 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:27.38 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:43.12 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-155-51.cinci.res.rr.com) |
| 08:51.08 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:15.13 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 09:15.13 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 09:16.07 | *** join/#asterisk-dev Toommi (~name@geldern.screenwork.de) |
| 09:16.15 | *** part/#asterisk-dev Toommi (~name@geldern.screenwork.de) |
| 10:13.44 | *** join/#asterisk-dev mbranca (~matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 11:23.27 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:23.27 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:57.17 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 13:25.33 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 13:25.33 | *** 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. |
| 13:27.26 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 13:27.44 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 13:45.34 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:45.34 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:56.44 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 13:56.44 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 14:05.12 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:05.12 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:21.34 | *** join/#asterisk-dev miguel3239 (~miguel323@12.187.84.162) |
| 14:26.41 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 14:33.07 | *** join/#asterisk-dev Gugge (~gugge@vlan2.dlxhosting.dk) |
| 14:42.03 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 14:53.10 | *** join/#asterisk-dev Aven (~avenger@78.36.107.48) |
| 14:54.55 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:54.55 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:55.04 | Aven | Someone uses SFA for 1.6.2.6? At me Asterisk crashed at incoming a call. |
| 14:55.05 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:55.05 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:57.22 | *** join/#asterisk-dev TommyBotten (tommy@91.205.185.140) |
| 14:58.28 | *** join/#asterisk-dev wdbl (daemon@173-15-183-209-BusName-Philadelphia.hfc.comcastbusiness.net) |
| 14:59.33 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:59.33 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:00.48 | leifmadsen | Aven: works for me |
| 15:01.42 | Aven | :( |
| 15:02.50 | Aven | i downgrade to 1.6.2.5 for work SFA... ^( |
| 15:04.27 | Aven | Support of a product at Digium very bad... 3 days support case it is opened |
| 15:04.46 | leifmadsen | when did you open it? |
| 15:04.49 | kpfleming | digium was closed on friday and over the weekend |
| 15:04.52 | leifmadsen | right |
| 15:04.57 | leifmadsen | (that's where I was going with that :)) |
| 15:05.49 | Aven | ok, I will wait still |
| 15:09.00 | *** join/#asterisk-dev [psy] (~psy0rz@lounge.datux.nl) |
| 15:09.24 | [psy] | whats the 'opposite' of the Newchannel event? it seems to be Hangup? |
| 15:21.16 | *** join/#asterisk-dev bklang_ (~bklang@tesla.alkaloid.net) |
| 15:24.18 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 15:25.28 | *** join/#asterisk-dev Corydon76-lap (~Corydon76@nat/digium/x-ygkftvmockghlwlh) |
| 15:25.28 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:26.51 | seanbright | good morning friends |
| 15:27.14 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:27.14 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:27.49 | [psy] | hiiiiiii |
| 15:47.22 | seanbright | jmls: re: oej's comments - seems like a good idea to me. |
| 15:49.01 | russellb | yeah, same here |
| 15:49.04 | russellb | sorry, heh |
| 15:49.24 | russellb | Also, I had another thought about the feature... do you really want to mute the stream, or just prevent it from being recorded? |
| 15:50.05 | russellb | the way it's written actually mutes the audio, so nothing can get it, which seems not ideal |
| 15:50.15 | rob | wq |
| 15:50.22 | rob | lol |
| 15:50.23 | rob | oops |
| 15:50.27 | seanbright | wq! |
| 15:50.29 | russellb | rob: :x > :wq |
| 15:50.36 | rob | 8D |
| 15:50.37 | putnopvut | russellb: never! |
| 15:50.41 | seanbright | C-X C-C |
| 15:50.42 | rob | %s/lol/oops/g |
| 16:01.15 | *** join/#asterisk-dev ebroad (~EB@72.11.213.195) |
| 16:02.03 | chazzam | oops oops? |
| 16:11.15 | *** join/#asterisk-dev ManxPower-work (~manxpower@216.186.151.147) |
| 16:11.25 | ManxPower-work | Can anyone think of why I might get this message? |
| 16:11.26 | ManxPower-work | [Mar 22 12:09:02] WARNING[31610]: chan_sip.c:3752 sip_write: Asked to transmit frame type 4, while native formats is 0x100 (g729)(256) read/write = 0x100 (g729)(256)/0x100 (g729)(256) |
| 16:11.36 | ManxPower-work | I have the licenses |
| 16:12.04 | kpfleming | that usually happens when there are frames in the queue around the time the format changes or a channel gets bridged |
| 16:12.10 | kpfleming | they don't get dumped, but they are the wrong format |
| 16:12.40 | ManxPower-work | A bug? |
| 16:12.50 | kpfleming | not really, no |
| 16:13.16 | ManxPower-work | I'll just disable g729 for now |
| 16:13.20 | kpfleming | it's just telling you that a frame is getting lost, but since it was during a switch from one call leg to another, there's not really anyway to guarantee it would get delivered anyway |
| 16:13.37 | ManxPower-work | *nod* Should it really be a WARNING? |
| 16:14.29 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:14.54 | kpfleming | yes, because in chan_sip it can't know why the frame arrived, and in other circumstances it could be much more serious |
| 16:15.25 | ManxPower-work | I've never, in all my years of using Asterisk, had good luck with allowing more than one codec for a peer. |
| 16:17.57 | ManxPower-work | kpfleming, how would you keep the format from changing? I've disabled everything except G729 and still getting that error. |
| 16:18.21 | kpfleming | are both channels in the bridge using the same format? |
| 16:18.42 | ManxPower-work | no. transcoding should be going on between a PRI ulaw and g729 SIP. |
| 16:19.02 | ManxPower-work | the sip connection should not be "changing formats" |
| 16:19.03 | *** join/#asterisk-dev davidbrillert (~aragon125@h216-235-8-130.host.egate.net) |
| 16:19.29 | kpfleming | so when the two channels get bridged together, there could already be a frame (or two, in bizarre cases) in the read queue on the PRI channel. after the bridge happens, that frame is still in the queue, but hasn't been transcoded. |
| 16:20.13 | ManxPower-work | having hundreds of these messages make the signal/noise ratio on the CLI just horrid. |
| 16:21.50 | kpfleming | there may be a bug open in mantis about this situation already... if not, there should be. what should happen is when ast_channel_make_compatible() gets called, any existing frames in the queue should either be dropped or converted using the new trasncoding path that that function created. |
| 16:22.52 | ManxPower-work | That does not help much as we are running 1.4 |
| 16:23.26 | kpfleming | then go into chan_sip and disable th emessage |
| 16:23.29 | ManxPower-work | Sometimes I think it would be easier to port trixbox to 1.6 than get the patches for the features we want in 1.4. |
| 16:23.42 | kpfleming | trixbox or freepbx? |
| 16:23.58 | ManxPower-work | kpfleming, this specific box is Trixbox |
| 16:24.02 | ManxPower-work | May it rot in hell. |
| 16:24.05 | kpfleming | ahh well |
| 16:24.34 | ManxPower-work | Well, "mostly trixbox". I've replaced parts of it with decent code. |
| 16:24.58 | ebroad | gui's...whats wrong with vi :) |
| 16:25.11 | ManxPower-work | ebroad, That's what *I* use. |
| 16:25.16 | ebroad | hehe |
| 16:25.28 | ebroad | so why trix(are for kids)box |
| 16:25.54 | ebroad | or maybe i shouldn't open that can of worms |
| 16:26.04 | Qwell | ebroad: two words. $ |
| 16:26.29 | ebroad | Qwell, $ is one character |
| 16:26.47 | Qwell | ebroad: that doesn't sound as cool though. |
| 16:27.00 | ebroad | Qwell, yea is guess thats true' |
| 16:28.37 | ebroad | s/is/i/ |
| 16:28.41 | ManxPower-work | No. GUIs are for people that are unable or unwilling to learn even the most basic things about their PBX and just want to randomly click on stuff and hope it works. |
| 16:28.55 | ebroad | i do that every day ;) |
| 16:29.05 | ebroad | randomly click stuff that is |
| 16:29.21 | ManxPower-work | We will stop deploying Trixbox and FreePBX before the end of the year. |
| 16:29.38 | ebroad | good for you |
| 16:30.02 | Qwell | ManxPower-work: you should at least use AsteriskNOW :p |
| 16:30.15 | ManxPower-work | Qwell, not a chance in hell. |
| 16:30.16 | ebroad | theres nothing like vi and the complete lack of dependency checking in slackware |
| 16:31.52 | ebroad | does ael have array support? |
| 16:34.34 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:41.06 | *** part/#asterisk-dev ManxPower-work (~manxpower@216.186.151.147) |
| 16:45.14 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 16:50.21 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 17:02.11 | jmls | russellb: ping ? |
| 17:02.40 | russellb | pongggg |
| 17:02.43 | jmls | quote "do you really want to mute the stream, or just prevent it from being recorded?" |
| 17:03.02 | jmls | aren't I just muting the audio that is connected to mixMonitor ? |
| 17:03.13 | jmls | When testing, the agent could still hear the caller |
| 17:03.24 | jmls | but the MixMonitor file was muted |
| 17:04.02 | jmls | now thinks that we haven't retested since the new changes were put in |
| 17:05.59 | russellb | hm, it could be |
| 17:06.02 | seanbright | "we"? |
| 17:06.07 | seanbright | what is this we crap? |
| 17:06.08 | seanbright | heh |
| 17:06.19 | russellb | if the audiohook gets its own copy of the frame, then yeah |
| 17:07.19 | jmls | "we" as in my grunts on the ground .. :) |
| 17:11.01 | jmls | I did ask a question to ask about ast_frame_clear, over the weekend. but everyone was asleep. |
| 17:11.11 | jmls | or just ignored me .... :( |
| 17:12.03 | jmls | http://pastebin.ca/1849401 |
| 17:12.44 | jmls | Line 05: what list is this looping through ? |
| 17:13.15 | jmls | and doesn't line 07 mean than line 08 clears the next frame, not the frame passed in as a parameter ? |
| 17:14.27 | file | there can be a chain of frames |
| 17:15.27 | seanbright | line 7 happens at the end of each pass through the for loop |
| 17:16.15 | jmls | see, that's why I *love* C. Line 7 executes after line 8 ... :P |
| 17:16.36 | jmls | I know, something to do with macros, right ? |
| 17:16.41 | file | it's a for loop. |
| 17:17.16 | jmls | crap, I see it now. It's the formatting that confused me |
| 17:17.29 | jmls | I thought the } on line 9 was matching with the for |
| 17:17.48 | jmls | doh |
| 17:18.28 | jmls | annnnyyyyyway, so this clears all frames on the chain ? Do all of these frames belong to the same audiohook, then ? |
| 17:21.40 | *** join/#asterisk-dev jameswf (~james@unaffiliated/jameswf-home) |
| 17:27.10 | ebroad | R556 |
| 17:27.14 | MuffinMan | [R556] Improve handling of T.38 re-INVITEs that arrive before a T.38-capable application is executing on a channel. [Pending] Submitted by kpfleming => https://reviewboard.asterisk.org/r/556/ |
| 17:27.24 | ebroad | woops |
| 17:27.45 | ebroad | R566 |
| 17:27.49 | MuffinMan | [R566] Use the correct IP address in the c and o sdp lines when using an externally mapped IP address [Pending] Submitted by ebroad => https://reviewboard.asterisk.org/r/566/ |
| 17:28.28 | ebroad | need some advice/comments on this one, when anyone has a minute |
| 17:32.16 | *** join/#asterisk-dev cusco (~trilili@213.63.137.210) |
| 17:33.18 | cusco | hi |
| 17:33.26 | cusco | two asterisks in a iax trunk, both using 1.6.2.6... does one assume the other's UNIQUEID ?? |
| 17:34.37 | cusco | in a previous asterisk verson we kept getting warnings like: WARNING[2523] chan_iax2.c: Assigned (0x7fdc6c1af428)UniqueID to (0x7fdc6c1af431)1267331104.2590 |
| 17:35.19 | Corydon76-lap | This is not tier2 support |
| 17:35.40 | cusco | I know... sorry |
| 17:36.18 | tzafrir | how do I get post-review to upload a new diff rather than update an existing one? |
| 17:42.56 | *** join/#asterisk-dev moy (~chatzilla@74.12.131.89) |
| 17:47.05 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 17:58.08 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 17:58.08 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 17:59.10 | eliel | hello |
| 17:59.26 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 18:03.12 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 18:13.05 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 18:13.05 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 18:34.37 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:01.21 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 19:04.42 | *** join/#asterisk-dev pabelanger (~pabelange@yoda.kanatek.com) |
| 19:04.51 | pabelanger | afternoon |
| 19:05.13 | russellb | morning |
| 19:06.56 | seanbright | Corydon76-lap: split takes a 'limit' argument |
| 19:07.04 | seanbright | that would save you from having to join again |
| 19:08.49 | pabelanger | russellb: Is there any information about automating dahdi yet from bamboo? |
| 19:09.33 | russellb | I could certainly add DAHDI builds there. The reason I haven't is mostly a reflection of organizational breakdown at Digium. There is a separate team dedicated to DAHDI that handles their own approach to testing things. |
| 19:10.05 | russellb | I would certainly welcome DAHDI into the framework if those in charge of DAHDI development and maintenance decided that's what they wanted to do. |
| 19:11.11 | seanbright | hmmm |
| 19:11.16 | seanbright | i smell in-fighting |
| 19:11.22 | seanbright | :-) |
| 19:11.22 | kpfleming | and the bigger issue with DAHDI is that it needs to be built against a lot of different linux/distros (kernels), not against different operating systems |
| 19:11.49 | russellb | right |
| 19:11.57 | russellb | no fighting, I'm just deferring that work :-) |
| 19:12.10 | russellb | they have their own automated test stuff going |
| 19:12.15 | russellb | I'm not about to duplicate effort |
| 19:12.40 | pabelanger | I wasn't sure if there was talk about adding automated testing of actually hardware. IE: test cases to test dtmf detection on a TDM410p. |
| 19:12.49 | eliel | russellb: i am waiting the last "ship it" for the data api to get it merged :-) |
| 19:13.30 | russellb | right, that's the kind of stuff they do |
| 19:14.30 | russellb | eliel: k, i'll try to give it another look over soon |
| 19:14.50 | eliel | russellb: good! |
| 19:16.14 | russellb | it may not be today |
| 19:16.19 | russellb | as it is Monday, and Monday is Monday |
| 19:18.03 | kpfleming | Monday is also a day that ends with 'y' |
| 19:18.36 | Qwell | Saturday and Sunday end in 'y' as well, and they are not usually terrible. |
| 19:19.08 | Qwell | I suspect the real trouble comes from the 'd'. |
| 19:22.08 | eliel | russellb: no problem, i can wait, the only problem is that the branch is not getting automatically merged |
| 19:22.17 | eliel | and i am doing the work |
| 19:49.29 | putnopvut | Awesome, I've found a combination that will cause Asterisk trunk to reliably crash on startup. Step 1, set preload => pbx_config.so in modules.conf. Step 2, in extensions.conf add a hint for a SIP device that is not defined in sip.conf. Step 3, start Asterisk. Since pbx_config.so is preloaded, it gets loaded before ast_channels_init is called. When the hint is parsed, we call ast_device_state on the device used in the hint |
| 19:49.29 | putnopvut | . chan_sip's device_state callback is called, but since the device being used is not defined in sip.conf, chan_sip returns AST_DEVICE_UNKNOWN. The fallback behavior of ast_device_state is to search the channels container for a channel with a matching prefix. However, the channels container is NULL at this point, and so attempting to find a specific channel causes a crash. My proposed solution is to call ast_channels_init() |
| 19:49.30 | putnopvut | <PROTECTED> |
| 19:52.28 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 19:52.28 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 19:55.24 | russellb | not that i know of, just see what ast_channels_init() depends on |
| 19:55.37 | russellb | probably the logger and that's about it |
| 20:14.11 | kpfleming | it seems like having the channel list in a usable state before loading any modules makes a great deal of sense :-) |
| 20:14.49 | russellb | specifically, channel drivers, heh |
| 20:14.50 | russellb | oops |
| 20:24.24 | putnopvut | All ast_channels_init does is intitialize the channels container and register some CLI commands. So yeah, logger should be it. |
| 20:24.32 | putnopvut | I'll give it a shot and see what happens. |
| 20:26.16 | Corydon76-lap | r544 |
| 20:26.21 | MuffinMan | [R544] Ensure line terminators for emails are consistent [Pending] Submitted by tilghman => https://reviewboard.asterisk.org/r/544/ |
| 20:26.25 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 20:26.25 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:26.40 | Corydon76-lap | Could I get a "Ship It!" from someone please? |
| 20:28.20 | russellb | putnopvut: so, ast_cli_init(), too then (I think that exists..) |
| 20:28.58 | putnopvut | russellb: hmm, I don't see that being called in main() |
| 20:29.16 | putnopvut | Ah, but ast_cli_perms_init is called there. |
| 20:29.31 | russellb | I guess I made it up |
| 20:36.03 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:38.50 | jpeeler | would it be tragic to disallow native bridging in cases involving limits (the L flag)? just not sure if i need to defend the change on reviewboard or if i can just explain the change in the commit (which will go back to matching current 1.4 behavior) |
| 20:39.44 | file | I think someone would not like that. |
| 20:39.56 | putnopvut | jpeeler: Well, when using RTP channels, we can do a P2P bridge in such a case. Perhaps there can be something in chan_dahdi specifically for that? |
| 20:40.14 | jpeeler | the timing is off though |
| 20:41.30 | jpeeler | but it sounds like it's not even up for debate and somehow it must be fixed |
| 20:41.47 | kpfleming | what causes the timing to be different? |
| 20:42.58 | jpeeler | the native bridging is relying on the timeout updated from ast_waitfor_n, where as non-native calculates the time difference with timeval calculations |
| 20:43.47 | kpfleming | ahh |
| 20:43.51 | kpfleming | yes, i remember when we did that |
| 20:43.52 | jpeeler | the timeval calculations are all stored in the bridge config, which isn't not available in the channel drivers currently, i assumed with all the feature timer stuff/dtmf handled non-natively that was done on purpose |
| 20:44.01 | kpfleming | yes |
| 20:44.31 | kpfleming | but the native bridge code could keep its own timeval for when the bridge should end, and calculate it based off the time the bridge started and the passed-in limit |
| 20:44.49 | kpfleming | how much time difference are we talking about here? |
| 20:45.56 | jpeeler | 300 microseconds (i think that's the next unit after milliseconds) |
| 20:46.03 | kpfleming | smaller? yes |
| 20:46.11 | kpfleming | 300 microseconds over what time period? |
| 20:46.20 | jpeeler | it's not much, but enough to cause edge cases to not playing warnings, 5 milliseconds |
| 20:46.52 | kpfleming | wait... i'm confused |
| 20:47.01 | kpfleming | what was specified as '5 milliseconds'? |
| 20:47.41 | putnopvut | "300 microseconds over what time period?" "5 milliseconds." |
| 20:48.08 | jpeeler | 300 microseconds is the time difference observed, but it is actually over 3 milliseconds |
| 20:48.14 | jpeeler | L(8000:5000) |
| 20:49.04 | kpfleming | so the amount of time that it should have measured is 5 milliseconds, but it measured 5 milliseconds minus .3 milliseconds? |
| 20:51.58 | jpeeler | it is staying in the native bridge for the right amount of time, but by the time it reaches the point in the channel_bridge to see how much time passed it is .2-.3 milliseconds late |
| 20:53.18 | kpfleming | so then i would say that the fix is fairly simple... when the generic bridge calls into the native bridge, it should adjust the time limit down by 1 or 2 milliseconds, to account for any delay between the native bridge noticing that it should exit and the exit/return/etc. actually happening |
| 20:53.25 | kpfleming | in fact, that could even be as much as 5 or 10 milliseconds |
| 20:53.47 | file | if you were really cheeky you could try to make it adaptive and learn |
| 20:53.55 | kpfleming | then let the generic bridge handle the fine-grained timing right at the end of the window |
| 20:54.04 | kpfleming | file: except it could be very variable, and you don't have a large sample set |
| 20:54.17 | kpfleming | and there's not much to be gained by staying in the native bridge 3 milliseconds longer |
| 20:54.19 | file | kpfleming: you're no fun! |
| 20:54.23 | kpfleming | i know! |
| 20:55.25 | jpeeler | the fine tuned calculations are done in the generic bridge, so switch from native to generic? |
| 20:55.31 | kpfleming | right |
| 20:55.51 | kpfleming | if the actual limit is 5 seconds from now, tell the native bridge it is actually 4.99 seconds |
| 20:56.11 | kpfleming | and then when the native bridge returns, the generic bridge will figure out how much time has actually elapsed and adjust |
| 20:56.22 | kpfleming | but it won't be *more* than the limit allowed for |
| 20:58.26 | jpeeler | alright, i thought it would be all or nothing. sounds good to me |
| 20:58.43 | kpfleming | nope... might as well let the native bridge handle *most* of the bridging time |
| 21:25.46 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 21:39.44 | *** join/#asterisk-dev Cresl1n (~matt@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:39.44 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 21:40.47 | jpeeler | kpfleming: what about for repeated warnings, should after playing a warning it continue trying to use the native bridge for as long as possible and then jump to the generic bridge? |
| 21:41.22 | kpfleming | yes, you should strive to use the native bridge whenever possible, which i think the code already tries to do |
| 21:42.31 | kpfleming | it doesn't seem likely that the next native bridge interrupt would be so short (20 milliseconds or less) to be a concern, but there's no reason to drop into the native bridge if you know you have to come back out in 100 millseconds or less |
| 21:43.43 | jpeeler | ok |
| 22:38.29 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 22:40.05 | Kobaz | pokes Cresl1n |
| 22:40.11 | Cresl1n | hey! |
| 22:40.12 | Cresl1n | :-) |
| 22:40.15 | Cresl1n | jumps |
| 22:40.15 | Kobaz | ooOoo |
| 22:40.25 | Kobaz | if you're not too busy |
| 22:40.32 | Kobaz | i have some libpri stuff going on |
| 22:40.38 | Kobaz | i'll make you some cookies |
| 22:40.48 | Kobaz | or send flowres |
| 22:40.57 | Cresl1n | heh |
| 22:41.02 | Cresl1n | what's wrong? |
| 22:41.13 | Cresl1n | is it a bug or not a bug? |
| 22:41.22 | Kobaz | libpri is crashing when sending an indication via dahdh_indicate |
| 22:41.23 | kpfleming | yes, it is a bug or not a bug |
| 22:41.24 | Kobaz | yeah it's a bug |
| 22:41.33 | Kobaz | here's the bug |
| 22:41.37 | Cresl1n | ah, ok, well, to be honest though |
| 22:41.46 | Cresl1n | libpri issues I prefer to funnel through tech support |
| 22:41.58 | Kobaz | digium tech support? |
| 22:42.00 | Cresl1n | yeah |
| 22:42.08 | Kobaz | but this is a memory corruption issue |
| 22:42.16 | Kobaz | either that or something is writing bad data to the pri txqueue |
| 22:42.31 | Kobaz | or would they handle that too |
| 22:43.08 | Kobaz | oh |
| 22:43.12 | Kobaz | someone else just posted the same bug |
| 22:43.14 | Cresl1n | Yeah, any kind of bug with libpri, that should be included in card support |
| 22:43.29 | Kobaz | this is a sangoma card though |
| 22:43.33 | russellb | burn |
| 22:43.34 | Kobaz | i really think it has nothing to do with the card |
| 22:43.45 | Kobaz | that it's asterisk/libpri |
| 22:43.49 | russellb | then I guess you don't get Cresl1n's time :-p |
| 22:43.51 | Qwell | they're welcome to submit patches too |
| 22:44.05 | Kobaz | heh |
| 22:44.12 | Cresl1n | Kobaz: Understandable, but on the other hand, that's an area where there's value in having a Digium card then :-) |
| 22:44.38 | Kobaz | i dont understand the whole seperation |
| 22:44.44 | Kobaz | isn't libpri just a driver written by you guys |
| 22:44.53 | Kobaz | signalling helper, essentially |
| 22:44.59 | russellb | yes. |
| 22:45.10 | russellb | however, Cresl1n is saying that his time is given priority to Digium customers |
| 22:45.32 | Kobaz | yeah |
| 22:45.35 | Kobaz | understandable |
| 22:45.37 | russellb | otherwise, you're welcome to submit a bug report on mantis (which you have already done) |
| 22:45.41 | Kobaz | yeap |
| 22:45.42 | russellb | and someone will get to it eventually ... |
| 22:45.46 | Kobaz | hehe |
| 22:45.46 | Cresl1n | Kobaz: no offense or anything, it's just something that Digium is able to do to add value to its board customers |
| 22:45.53 | Kobaz | Cresl1n: yeah |
| 22:46.25 | Kobaz | so if i go and buy a digium card, reproduce the crash.. i can give you guys a call? |
| 22:46.28 | Kobaz | heh |
| 22:46.31 | Cresl1n | You definitely can |
| 22:46.39 | Kobaz | nifty |
| 22:47.04 | kpfleming | a digium card that you can use libpri with :-) |
| 22:47.15 | Kobaz | heh |
| 22:47.28 | Qwell | kpfleming: PRI works over analog, doesn't it? :D |
| 22:47.36 | russellb | preferably the most expensive one. |
| 22:47.38 | Qwell | (in theory. and obviously I'm kidding)) |
| 22:48.09 | Kobaz | so that's what mattf was talking about when he said these issues are handled via tech support |
| 22:48.10 | Cresl1n | Kobaz: It's a big world though, maybe there's someone else on the bug tracker that wants to look at it |
| 22:48.17 | russellb | and really, you're going to want to buy 4 of them, to prove that it's not related to the board. |
| 22:48.18 | Kobaz | i'm like... why would sangoma care about a libpri issue |
| 22:48.19 | Cresl1n | Kobaz: yeah, that was me actually :-) |
| 22:48.23 | Kobaz | oh |
| 22:48.23 | Cresl1n | <---- mattf |
| 22:48.26 | Kobaz | hehe, k |
| 22:48.51 | Cresl1n | Yeah, Digium cares about libpri issues |
| 22:49.04 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:49.04 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:49.16 | Cresl1n | chan_dahdi/libpri/DAHDI problems (anywhere in that stack) we consider to be part of our free technical support we provide to board customers |
| 22:49.29 | Cresl1n | that's why it can be worth it to buy Digium :-) |
| 22:49.50 | Kobaz | russellb: well, i think if i can make it crash with a digium card, i've mostly removed the possability it's the board |
| 22:50.00 | russellb | Kobaz: I know, I'm just messing around. |
| 22:50.03 | Kobaz | heh |
| 22:50.31 | Kobaz | i put in a patch to chan_dahdi |
| 22:50.44 | Kobaz | it might have fixed it.. although in a bug-hiding type of way |
| 23:07.35 | *** join/#asterisk-dev pyite (~dschreibe@unaffiliated/pyite) |
| 23:18.57 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |