| 01:19.24 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 02:56.18 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 03:54.11 | Kobaz | i may have found the moh corruption problem |
| 03:54.19 | Kobaz | it's related to dahdi |
| 03:54.48 | Kobaz | [2011-08-17 13:23:02] DEBUG[21352] sig_pri.c: Not yet hungup... Calling hangup once with icause, and clearing call |
| 03:54.53 | Kobaz | after that message... moh show classes |
| 03:55.00 | Kobaz | [2011-08-17 13:24:29] ERROR[19847] astobj2.c: bad magic number 0x6567656c for 0xd6670f8 |
| 04:33.04 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-128-145.bvtn.or.frontiernet.net) |
| 05:21.40 | *** join/#asterisk-dev oej (~olle@195.41.130.3) |
| 05:21.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:30.19 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 05:56.22 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 06:19.31 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:19.44 | schmidts | good morning |
| 06:23.15 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 06:23.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:31.22 | jmls | has anyone considered using 0MQ (http://www.zeromq.org/) in asterisk ? looks like a great fit |
| 06:32.04 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 07:06.12 | *** join/#asterisk-dev oej (~olle@office.ipvision.dk) |
| 07:06.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:20.28 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:58.53 | oej | Good morning folks |
| 08:19.38 | schmidts | good morning oej |
| 09:08.10 | oej | Hello |
| 09:08.23 | oej | Back to DTMF today. My apologies for possible outbursts later. |
| 09:08.37 | schmidts | we will keep it in mind ;) |
| 09:28.36 | oej | AAAAAAAAaaaarrrrggggghhhhh. |
| 09:28.52 | oej | We can get a NEW incoming DTMF while we're still transmitting the latest out. That's bad. |
| 09:29.13 | oej | We need dual-dual tone support. Or more than dual? |
| 10:00.47 | schmidts | oej is sending and receiving dtmf done in only one thread? |
| 10:02.48 | oej | We receive in one side and send in another channel, so I send AST_CONTROL messages between them. |
| 10:03.04 | oej | There are some interesting synchrnization issues. |
| 10:03.36 | oej | I need to clock on both channels and follow the clock on the incoming stream, which means I can still be sending outbound after inbound have stopped, depending on the timing on that side. |
| 10:03.56 | oej | Now if that side starts a NEW dtmf while I still try to catch up on the outbound channel I'm f*ed |
| 10:20.51 | schmidts | ok i see |
| 10:34.39 | schmidts | oej can you show me your code? |
| 10:34.52 | oej | If I show you mine, will you show me yours? |
| 10:34.54 | oej | ha ha |
| 10:35.02 | oej | rana-dtmf-duration-1.6.0 in my svn |
| 10:35.22 | oej | Been working on that for a while, keep finding issues. |
| 10:35.46 | schmidts | hmm ok i will show you a pastebin :D |
| 10:36.24 | oej | Feedback on that branch is more than welcome. |
| 10:36.49 | oej | It will fix DTMF duration issues clearly. We need to transmit the duration that we receive, which we do not do without that code. |
| 10:37.15 | oej | It surprised me a lot, since there was a lot of work with DTMF duration during 1.4 development. They must not have tested thoroughly |
| 10:37.42 | schmidts | :D |
| 10:38.06 | schmidts | hmm what is the path in svn? http://svn.digium.com/svn/asterisk/branches/oej doesnt work |
| 10:38.28 | schmidts | aaah ok its not branches its team |
| 10:38.40 | oej | ? |
| 10:38.41 | oej | Cool. |
| 10:38.44 | schmidts | nevermind ;) |
| 10:38.46 | oej | Anyway. it's around |
| 10:38.54 | oej | Now, another issue. |
| 10:38.56 | schmidts | man you have a lot of stuff in your directory :D |
| 10:39.08 | oej | yep. Waiting for commits |
| 10:39.35 | schmidts | which one of these is it? rana-dtmf-duration-1.8/ or rana-dtmf-rtp-duration-1.6.0/ ? |
| 10:39.40 | oej | 1.6.0 |
| 10:39.47 | oej | I just created 1.8 |
| 10:39.51 | oej | No code in there. |
| 10:40.16 | schmidts | ah ok |
| 10:41.40 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 10:42.48 | oej | We never ever lock the mwipvt. Sweet. And now we have two threads sending packets and managing p->history on that pvt. No wonder I had memory corruption. |
| 10:43.11 | oej | Hello marquis42. How's marquis43? |
| 10:49.12 | Marquis42 | Haha |
| 10:49.47 | Marquis42 | How are you oej? |
| 10:50.12 | oej | Just fine. In Denmark working with debugging Asterisk and hating DTMF. And you, sir? |
| 10:51.31 | Marquis42 | Just fine. In Detroit with with debugging Asterisk and hating peer matching. ;) |
| 10:55.26 | Marquis42 | Actually, glad to be back to doing Asterisk stuff. I spent the last three days beating my had against a wall on a problem with a Cisco CCM in Beijing. :( |
| 11:07.00 | oej | Ouch. |
| 11:07.58 | oej | If you still have some extra time, we have clearance to restart Pinanan |
| 11:09.53 | Marquis42 | I am certainly interested in continuing that. I know things kind of hit a wall because of (mostly my) time constraints. But it's still a cool idea. |
| 11:21.49 | oej | It was you, me and the customer time contraints. |
| 11:22.04 | oej | Let's discuss it next week over some suitable media. |
| 11:24.58 | oej | Hmm. Referring to the jira issue in svn commit did not work. |
| 11:28.10 | Marquis42 | oej: Sounds good. I think you still have me on Jabber, feel free to hit me up. |
| 11:28.24 | oej | That's a suitable media :-) |
| 11:28.43 | Marquis42 | I thought it might be. :) |
| 11:46.44 | oej | Sent a review on peer->mvipvt locking. Please review, it causes crashes in larger systems. |
| 11:47.03 | Marquis42 | Just saw that, I'll take a look at it later today. |
| 11:51.24 | oej | THanks. If you have voicemail notification AND sip history turned on, you need this fix. Or something that fixes the same issue, but in a totally different way. |
| 11:52.23 | Marquis42 | Yeah, I think we have a couple of systems that in retrospect may well have crashed due to this bug. :( |
| 11:54.52 | oej | Debugging options killed the system. |
| 11:58.54 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:58.55 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:01.26 | oej | Good morning, Kpfleming. |
| 12:01.41 | kpfleming | yes... thanks. you too. |
| 12:01.47 | kpfleming | well, your morning has passed. |
| 12:01.53 | kpfleming | are you still in denmark? |
| 12:13.09 | oej | Yes, I'm still in the land of breakfast lunches... |
| 12:13.33 | oej | (The Swedish word for breakfast is used for lunches here. Well, they're west of us, so they are a bit later) |
| 12:14.01 | oej | Thanks for the quick feedback, russellb |
| 12:18.50 | kpfleming | nice. someone on asterisk-ss7 wants to know what hardware he needs to use for setting up libss7 without a computer. |
| 12:19.14 | Marquis42 | I think my brain just segfaulted. |
| 12:29.45 | oej | Look for a core dump on the floor, Marquis42 |
| 12:31.23 | oej | I don't want to recommend any tool to analyze it. Sorry. |
| 12:31.46 | Marquis42 | lol |
| 12:31.48 | Marquis42 | Well played |
| 12:32.05 | oej | ;-) |
| 12:32.56 | russellb | let's deprecate threads |
| 12:33.12 | oej | Yes, they feel rather out of fashion. |
| 12:41.30 | oej | russellb: In general, you're fine with adding locks there? |
| 12:45.51 | russellb | Yes, pending review of what locks are held coming into that function, if any |
| 12:45.57 | russellb | i didn't go looking at that, it'll take a while |
| 12:53.58 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fpnmxtcquxvjpowu) |
| 12:53.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:54.01 | kpfleming | there's no need to deprecate threads... what needs to be deprecated is sharing data structures between threads |
| 12:54.51 | *** join/#asterisk-dev oej (~olle@office.ipvision.dk) |
| 12:54.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:56.11 | kpfleming | ponders an alternative solution for MASTER_CHANNEL(HASH(SIP_CAUSE, ...)) that wouldn't have such a massive performance impact |
| 13:10.23 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:14.55 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:15.54 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-dwzefblgtkirrpdy) |
| 13:27.47 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:41.40 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fpnmxtcquxvjpowu) |
| 13:41.46 | kpfleming | mnicholson: ping |
| 13:41.56 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-flkhkahiyblfszad) |
| 13:41.56 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:48.46 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:48.46 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:49.10 | mnicholson | kpfleming, pong |
| 13:49.50 | oej | Dirty proposal: Send an CONTROL frame from the pvt before it dies/cancels, collect them on the inbound as a string and publish it in SIP_CHANNEL or something |
| 13:50.01 | oej | CHANNEL(pvterrors) |
| 13:50.06 | oej | separated by something |
| 13:51.07 | mnicholson | something like that might work |
| 13:52.01 | oej | KISS... |
| 13:52.28 | mnicholson | the MASTER_CHANNEL thing uses the linkedid to find the channel to use. So it doesn't always store data on the pvt->owner |
| 13:58.52 | kpfleming | if HASH() stored each hash in a datastore, instead of in a channel variable, then a SIP_CAUSE HASH datastore created on the master channel could be shared with the child channels (using reference counting), and no channel searching (or channel locking) would be necessary to update it from the child channels |
| 13:59.18 | kpfleming | there's really no value in them being stored in channel variables... they aren't usable except through the HASH() function anyway, the storage might as well be opaque |
| 14:00.07 | mnicholson | how do we link just the SIP_CAUSE hash stuff without linking every other hash on the channel? |
| 14:01.27 | mnicholson | we could have special code for SIP_CAUSE... |
| 14:02.16 | kpfleming | the HASH function would have to have some way to indicate that a particular hash should be inherited to child channels... i don't have any ideas there, i was just hypothesizing :-) |
| 14:02.25 | mnicholson | ok |
| 14:02.37 | kpfleming | i suppose using the _ and __ prefixes like we do for channel variables would be logical and consistent |
| 14:02.39 | mnicholson | I like that idea, it would fix the issue without altering behavior |
| 14:03.00 | *** join/#asterisk-dev oej (~olle@office.ipvision.dk) |
| 14:03.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:03.15 | kpfleming | it's worth at least scoping out to figure out how much work it would be |
| 14:03.28 | oej | Back |
| 14:03.29 | kpfleming | it's certainly going to take more than 30 minutes, i think |
| 14:03.38 | oej | What's the real cause for the CPU processing? THe HASH? |
| 14:03.46 | kpfleming | no, searching for the MASTER_CHANNEL |
| 14:03.47 | mnicholson | oej, scanning the channel list |
| 14:04.20 | oej | So sending a Control message avoids that. |
| 14:04.30 | kpfleming | so this idea of sharing a datastore between the parent and child channels takes care of that completely |
| 14:04.33 | *** join/#asterisk-dev bklang (~bklang@66-208-246-34-ubr02b-waldlk01-mi.hfc.comcastbusiness.net) |
| 14:04.39 | kpfleming | yes, a control frame is a possibility too |
| 14:04.54 | kpfleming | but it requires every app that can create outbound channels to understand it |
| 14:05.24 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:05.24 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:05.27 | kpfleming | modifying HASH to be able to share a hash table between channels would not require changing app_dial, app_queue, app_followme, etc. |
| 14:06.13 | mnicholson | the datastore thing would require a HASH(__SIP_CAUSE,) datastore to be initialized on every channel so that it could be inherited later |
| 14:06.19 | mnicholson | well every sip channel |
| 14:06.29 | kpfleming | no, every channel that might create SIP channels |
| 14:06.31 | mnicholson | I guess chan_sip could do that when it created the channel |
| 14:06.40 | kpfleming | the master channel does not have to be SIP |
| 14:06.46 | mnicholson | that is true |
| 14:07.02 | kpfleming | so yes, this would require that someone who wanted to use this feature would have to add something to their dialplan, i guess |
| 14:07.07 | kpfleming | or use setvar in their config files |
| 14:07.37 | mnicholson | which is still a behavior change, but I don't think that is unreasonable |
| 14:07.50 | kpfleming | much less than what we have at the moment, agreed |
| 14:08.05 | kpfleming | i have to go afk for a bit |
| 14:08.09 | mnicholson | ok |
| 14:11.35 | oej | A humble question if someone can look at the reviewboard for the message waiting locks. It causes crashes and I feel it's important for all current releases. And it's a small change easy to review. :-) |
| 14:15.48 | oej | SO let's go back to the usage scenario. |
| 14:16.10 | oej | After a dial() we need to know the status of the various forks of the dial. |
| 14:16.26 | oej | There's a sequence in the dial string that only app dial knows |
| 14:16.42 | oej | Which could be obscured by cahn_local which makes the problem even worse |
| 14:17.23 | mnicholson | right |
| 14:22.00 | Kobaz | oej: i'm working on something similar |
| 14:22.18 | oej | similar to what, Kobaz? |
| 14:22.27 | Kobaz | <PROTECTED> |
| 14:22.32 | Kobaz | to that |
| 14:22.38 | oej | Right. |
| 14:22.50 | oej | And if we redesign, we should not go for a SIP-only solution. |
| 14:22.51 | Kobaz | I'm fixing up the console logging so that the forked calls are shown related to the original channe |
| 14:23.06 | oej | We should have a PVT error stringy that we return somehow. |
| 14:23.26 | Kobaz | probably a list of pvt errors |
| 14:23.49 | oej | Ok, so you definitely need to work on this architecture with mnicholson |
| 14:23.58 | Kobaz | right now i just have the console print something like this: |
| 14:24.00 | Kobaz | [2011-08-18 10:21:52] -- <DAHDI/i1/6105335530-d> calling SIP/213-00000044 (callee is ringing) |
| 14:24.08 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 14:24.12 | oej | So how do you handle chan_local returns? |
| 14:24.19 | oej | Hello otherwiseguy |
| 14:24.20 | Kobaz | haven't gotten to local channels |
| 14:24.39 | oej | Good for you, Kobaz. Please tell us before you go mad. |
| 14:24.43 | oej | :-) |
| 14:24.47 | otherwiseguy | oej: Hello! |
| 14:24.54 | Kobaz | previously the console would print this thing which is useless |
| 14:24.55 | oej | I am going insane with DTMF. Beep, beep, beep. |
| 14:25.05 | Kobaz | DAHDI/i1/6105335530-d called 213 |
| 14:25.09 | Kobaz | SIP/213-00000044 is ringing |
| 14:25.17 | Kobaz | how is that useful for anyone? |
| 14:25.23 | oej | Well, for some people. |
| 14:25.26 | Kobaz | well |
| 14:25.27 | Kobaz | heh |
| 14:25.33 | oej | But relating that to the dial string is good. |
| 14:25.35 | Kobaz | if you have one call at a time it's useful |
| 14:25.48 | Kobaz | SIP/213-00000044 might be ringing from an earlier Dial() |
| 14:25.52 | oej | SIP/skrep created channel SIP/fnutt-00203 that is ringing |
| 14:26.29 | Kobaz | so my main interest is tracking the parent channel for every activity |
| 14:26.43 | kpfleming | note: app_dial already creates a datastore of all forks of the tree... it's possible that could be leveraged for this thing |
| 14:26.48 | Kobaz | and so when I spawn a sip call with Dial() I want the sip error code back too |
| 14:26.56 | Kobaz | yeah app_dial has the list of things |
| 14:26.57 | Kobaz | lemme get it |
| 14:27.17 | oej | hands over a list of things to Kobaz |
| 14:27.22 | Kobaz | dialed_interfaces |
| 14:27.25 | kpfleming | right |
| 14:27.52 | Kobaz | so i got the sip error code back, but for only in the last-one-wins case |
| 14:27.53 | oej | Is there any way we can force a two second pause between all DTMF and not allow a user to start a new DTMF tone during this pause? |
| 14:28.03 | kpfleming | oej: no |
| 14:28.12 | oej | Darn. THen I got to fix the code. |
| 14:28.21 | kpfleming | well, i mean yes, you could absorb it, but you can't stop them from sending it :-) |
| 14:28.41 | Kobaz | so right now, upon sip error, i set SIPLASTERRORCODE on the original callee channel |
| 14:28.44 | oej | I want a red lamp on the handset saying "transmitting DTMF please wait" |
| 14:28.47 | kpfleming | Kobaz: but if each channel driver updated the entry in dialed_interfaces with the "result" of its dial attempt, all of that could be visible to the parent channel |
| 14:28.56 | Kobaz | kpfleming: yeah |
| 14:29.08 | kpfleming | it's an interesting thought |
| 14:29.19 | Kobaz | I should convert my sip error handback to use dialed_interfaces |
| 14:29.24 | oej | So if we change the dial interface in request_call (a.k.a sip_call etc) we could send a pointer to string buffer for that stuff |
| 14:29.24 | Kobaz | and then you can access DIALRESULT_1 |
| 14:29.26 | Kobaz | or something |
| 14:29.30 | kpfleming | a DIALED_INTERFACES dialplan function could exist then to retrieve results from it |
| 14:29.38 | oej | Again: Don't design it for SIP only. Generic, multiprotcol. |
| 14:29.48 | kpfleming | oej: the child channel already has a copy of the datastore, with a pointer to the shared list |
| 14:30.03 | oej | Ok, then it's great. |
| 14:30.04 | Kobaz | ${DIALED_INTERFACES(1,DIALSTATUS)} |
| 14:30.06 | Kobaz | or something |
| 14:30.17 | kpfleming | and DIALED_INTERFACES_KEYS or something, to enumerate the dialed interfaces |
| 14:30.27 | kpfleming | no, it's not DIALSTATUS |
| 14:30.28 | oej | speaks with a low voice - what about chan_local |
| 14:30.31 | kpfleming | that's different |
| 14:30.35 | kpfleming | oej: it's already handled |
| 14:30.40 | Kobaz | well, keys is bad, unless you do based on resulting channel |
| 14:30.43 | oej | PVTRETURNCODE |
| 14:30.49 | Kobaz | lets say you dialed SIP/100&SIP/100 |
| 14:30.52 | kpfleming | chan_local propagates the dialed_interfaces datastore to its outgoing channels |
| 14:31.01 | kpfleming | Kobaz: evil :-) |
| 14:31.21 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:31.22 | kpfleming | but right now HASH(SIP_CAUSE, ...) uses the resulting channel name, not the dialed interface |
| 14:31.32 | kpfleming | so this would be a bit tricky, but possible |
| 14:31.38 | Kobaz | it's evil, but you could do it |
| 14:31.38 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:31.38 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:32.17 | oej | Well, we're discussing two issues here. |
| 14:32.22 | kpfleming | so some method would have to exist of telling a channel driver which entry in dialed_interfaces belongs to the channel that is being requested from it |
| 14:32.24 | oej | One is to replace the broken HASH(SIP_CAUSE |
| 14:32.35 | oej | another is Kobaz work to relate cli output to the dial string |
| 14:32.40 | kpfleming | yes |
| 14:32.41 | Kobaz | already did that |
| 14:32.43 | oej | I think relating to the dial string makes sense for the future |
| 14:32.44 | Corydon76-home | oej: why is HASH(SIP_CAUSE,...) broken? |
| 14:32.49 | kpfleming | i'm only focusing on the first one |
| 14:32.58 | Kobaz | oej: that's the easy part |
| 14:32.59 | oej | SIP_CAUSE doesn't work for XMPP :-) |
| 14:33.01 | kpfleming | Corydon76-home: calling MASTER_CHANNEL every time a channel is torn down is very expensive |
| 14:33.11 | Corydon76-home | Expensive, but not broken |
| 14:33.20 | kpfleming | right |
| 14:33.24 | oej | When writing the dial plan, it's easier for me to check the return code of fork number 2 than to find out the channel name |
| 14:33.26 | Kobaz | oej, kpfleming: Actually, i've touched almost every module that deals with console output and channels, and made the output much more sane |
| 14:33.28 | Corydon76-home | Just wanted to be clear |
| 14:33.29 | kpfleming | but expensive enough that systems are being broken with it enabled |
| 14:33.40 | oej | Ok, not broken. But a bad design |
| 14:34.26 | kpfleming | oej: agreed, that's why whatever this ends up being needs to allow the dialplan writer to query the dialed_interfaces list and get tuples of (dialed_interface, resulting_channel_name, result_string) |
| 14:34.33 | Kobaz | and, i've even added generic New Call logging to the console |
| 14:34.49 | Kobaz | it looks like this: |
| 14:35.00 | Kobaz | [2011-08-18 10:21:17] == <DAHDI/i1/61053355-d> New Call (Type: DAHDI PRI) From: <6105335> (Destination: 8142371@trunkhandler_from-pstn,1) |
| 14:36.22 | kpfleming | Kobaz: i think the dialed_interfaces mechanism may in fact not let you initiate two calls at once to the identical destination |
| 14:36.25 | Kobaz | and I have some patches to show in the console who hung up first |
| 14:36.33 | oej | kpfleming: sounds fine |
| 14:36.42 | mnicholson | MASTER_CHANNEL is called for nearly every sip response, not just when channels are torn down |
| 14:36.51 | kpfleming | oh... yeah. ugh. |
| 14:37.30 | kpfleming | anyway... i must head offline to the real world for a bit. i'll be interested to see what the collective brains here come up with for a solution :-) |
| 14:37.36 | Corydon76-home | What's the specific reason for the expense? |
| 14:38.01 | Corydon76-home | Lock contention? Or iterating over many variables? |
| 14:38.30 | Kobaz | putting variables in a hash table would speed some things up |
| 14:39.01 | Corydon76-home | Kobaz: as long as variables are still stackable, that's fine |
| 14:39.07 | mnicholson | Corydon76-home, searching the channel list, so probably lock contention combined with lots of vars |
| 14:39.14 | Kobaz | yeah, you could do hash+linked list |
| 14:41.18 | oej | Arrghh. Bria stops sending RTP to us the moment we start sending DTMF to it. |
| 14:41.39 | Corydon76-home | Probably best to determine the actual cause of the expense before planning what to do about it |
| 14:41.57 | mnicholson | Corydon76-home, the cause is searching the channel list |
| 14:42.35 | Corydon76-home | But it's an ao2 hash, isn't it? Shouldn't that operation now be fast? |
| 14:43.02 | mnicholson | Corydon76-home, I believe it ends up scanning the entire list, locking each channel as it goes in some cases |
| 14:43.25 | Corydon76-home | Then we need to optimize for finding the channel based upon the linkid |
| 14:43.35 | Corydon76-home | Second hash, if need be |
| 14:43.45 | mnicholson | Corydon76-home, that is another way to address the issue, and probably should be done anyway |
| 14:43.52 | Corydon76-home | That should solve the real expense, shouldn't it? |
| 14:44.04 | mnicholson | Corydon76-home, I believe so |
| 14:48.16 | Corydon76-home | I'm sure we have places in the code where we do prefix searches, too... we might look at optimizing those, if possible |
| 14:49.19 | kpfleming | putting all channels into another ao2 container is a non-trivial change. that affects the entire system. |
| 14:49.38 | Corydon76-home | Yep, I know |
| 14:49.51 | kpfleming | that would not be an appropriate resolution except in trunk, in my opinion. |
| 14:50.20 | kpfleming | but really, there shouldn't be any need to 'search' for the master channel. there are already mechanisms in place to share data between a parent channel and it's children. |
| 14:50.33 | kpfleming | s/it's/its/ |
| 14:50.36 | Corydon76-home | It's a painful one, but we have proviso for doing so in a release version if there's no other reasonable solution |
| 14:51.22 | kpfleming | we're already talking about a reasonable solution |
| 14:51.29 | Corydon76-home | Oh? |
| 14:51.56 | Corydon76-home | Just turn it off? |
| 14:52.26 | kpfleming | no. using the dialed_interfaces datastore that already exists, which all channels in the tree from the parent on down have access to. |
| 14:52.47 | kpfleming | this in addition solves the problem of feeding SIP_CAUSE (or equivalent results) back through local channels |
| 14:53.42 | Corydon76-home | In addition? linkid doesn't remain constant through the creation of Local channels? |
| 14:57.41 | Corydon76-home | I'm not clear on how dialed_interfaces propagates information back to the parent channel |
| 15:02.07 | kpfleming | it's shared between the parent channel and all its children |
| 15:03.01 | oej | I need a DTMF queue on the outbound RTP session. |
| 15:03.27 | kpfleming | why? |
| 15:03.38 | Corydon76-home | kpfleming: are you sure about that? The duplicate routine is typically called on inheritance, and that creates a whole new list for the children channels |
| 15:04.15 | kpfleming | no, it creates a new datastore, but the datastore has a pointer to another object which is shared amongst all copies of the datastore |
| 15:04.49 | kpfleming | otherwise it wouldn't be able to accomplish its goal of keeping forwarding loops from occurring |
| 15:04.51 | mnicholson | kpfleming, Corydon76-home, im looking at the code now, the ast_dialed_interface datastore looks like it actually copies the dialed interface list (in 1.8 at least) |
| 15:05.00 | oej | kpfleming: In my work with DTMF duration, we end up in situation where we play out DTMF on the outbound channel after we have gotten DTMF end on the inbound. During that play out, we might well get a new DTMF begin coming in on the inbound channel, which I need to queue up. |
| 15:05.15 | Corydon76-home | mnicholson: yeah, that's what I'm seeing, too |
| 15:05.17 | kpfleming | mnicholson: then something is wrong |
| 15:05.34 | kpfleming | we'll have to verify with putnopvut |
| 15:05.38 | kpfleming | he wrote that stuff |
| 15:06.24 | kpfleming | if dialed_interfaces won't work, then we go back to my original suggestion of changing HASH to store its hashes in datastores instead of channel variables, and when those get inherited, the child channels get a reference, not a copy |
| 15:06.30 | kpfleming | and then they can all update the same hash |
| 15:07.04 | mnicholson | kpfleming, in theory it would still work if we just made it take a reference to the dialed_interfaces list instead of copying it |
| 15:07.09 | Corydon76-home | The nice thing about this is that with reference counting, this is all doable |
| 15:07.12 | kpfleming | correction: they get a copy of the datastore, but the datastore just holds a reference to the *real* data structure |
| 15:07.24 | kpfleming | mnicholson: maybe so |
| 15:07.27 | kpfleming | Corydon76-home: indeed |
| 15:07.56 | kpfleming | and thus... no searching of any kind required. |
| 15:08.03 | Corydon76-home | Yup |
| 15:08.58 | kpfleming | when you guys were talking about the dialed_interfaces list being copied, were you referring to chan_local specifically, or the 'inherit' function that is specific to dialed_interfaces? |
| 15:09.10 | Corydon76-home | The inherit function |
| 15:09.29 | Corydon76-home | inherit calls the duplicate function |
| 15:10.02 | kpfleming | ok |
| 15:10.07 | kpfleming | just making sure |
| 15:10.12 | Corydon76-home | in global_datastores.c |
| 15:10.55 | kpfleming | well, then i'm not keen on changing the way dialed_interfaces works... that's a whole lot of possible testing required to ensure it still functions properly |
| 15:11.03 | kpfleming | changing HASH only seems much easier to grapple with |
| 15:11.27 | kpfleming | and as a side effect, it could actually use a hash table if it wanted to, instead of putting everthing into strings |
| 15:12.16 | mnicholson | I actually thing both would be a good idea, the dialed_interfaces thing could be the basis for a more generic dial results reporting mechanism |
| 15:14.17 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:14.19 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:16.06 | Corydon76-home | <half-joking>Or, we could make each channel inherit a reference to the original channel, and the original channel gets to stick around until all of its slaves are dead.</half-joking> |
| 15:17.18 | oej | Transfers? |
| 15:17.35 | oej | Then slaves will live and the original channel is long gone. |
| 15:18.24 | oej | Anywhere where we have a linked list of AST_FRAMES? I guess the channel structure. |
| 15:19.24 | Corydon76-home | oej: That's why I added the half-joking tags |
| 15:19.34 | oej | I guessed so. |
| 15:19.36 | Corydon76-home | which I can't see, due to this client... |
| 15:25.51 | oej | Is there any code reason stopping me from adding an AST_LIST_HEAD_NOLOCK ast_frame queue in the RTP structure? I need to buffer up some DTMF frames |
| 15:28.58 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:28.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:30.24 | jmls | meh. |
| 15:30.36 | jmls | I think dialplan show globals is borked |
| 15:30.47 | Qwell | jmls: howso? |
| 15:30.51 | oej | Oh. I think that was my code originally. |
| 15:30.54 | jmls | wait 1 |
| 15:30.55 | oej | feels pain |
| 15:32.18 | jmls | http://pastebin.com/n6901ziB |
| 15:32.52 | jmls | the rest of the dialplan is just fine |
| 15:32.58 | oej | You don't show the option whether or not to read globals from extensions.conf at reload. |
| 15:33.01 | Qwell | where is RINGTIME set? |
| 15:33.03 | oej | Did you have the globals there at START |
| 15:33.11 | jmls | this is after a core restart as well |
| 15:33.23 | oej | I mean a real start, not a restart |
| 15:33.56 | jmls | core stop now; safe_asterisk; asterisk -r; dialplan show globals |
| 15:34.01 | jmls | same result |
| 15:34.20 | oej | Can you reach them from the dialplan? Are they really there? |
| 15:34.24 | jmls | no |
| 15:34.33 | jmls | that's how I found it |
| 15:34.39 | oej | Ok, then it's not an issue with "core show globals", then it's an issue with the globals. |
| 15:34.56 | oej | is off the hook ;-) |
| 15:34.59 | jmls | heh |
| 15:35.09 | jmls | can someone else verify ? |
| 15:35.19 | Qwell | jmls: where/how is RINGTIME set? |
| 15:35.21 | jmls | this is -10 head |
| 15:35.29 | Qwell | looks fine in trunk for me |
| 15:35.35 | jmls | bugger |
| 15:36.09 | jmls | I don't have RINGTIME anywhere |
| 15:36.14 | Qwell | O.o |
| 15:36.36 | Qwell | what about FOLLOWMEOPTIONS, or trunk_1 ? |
| 15:36.40 | jmls | oh, crap |
| 15:37.00 | jmls | I have a borked extensions.conf |
| 15:37.14 | jmls | which ... is ... wierd |
| 15:37.29 | jmls | as my extensions.conf consists(ed) of |
| 15:38.25 | jmls | #exec "/usr/bin/MQconfig.sh extensions.conf" |
| 15:39.27 | jmls | nevermind. I must have screwed it up somehow. |
| 15:39.40 | jmls | just don't know how that one line turned into a load of smelly poo. |
| 15:40.35 | jmls | wait - this was at the top of the file :: ;! Automatically generated configuration file |
| 15:40.47 | jmls | ;! Generator: Manager |
| 15:41.05 | jmls | I *didn't* do this ;) |
| 15:58.24 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 16:03.31 | acidfoo | is there a way to force asterisk make install to overwrite modules already present ? |
| 16:03.57 | acidfoo | (brb) |
| 16:05.53 | file | yawns |
| 16:06.18 | Qwell | acidfoo: it already does |
| 16:08.22 | pabelanger | So, just made asterisk 1.8.6.0-rc1 core dump running unit tests |
| 16:08.22 | pabelanger | http://pastebin.com/nuUK8pUB |
| 16:08.42 | Qwell | I do believe that SHELL thing was fixed. |
| 16:09.09 | Qwell | r331575 |
| 16:09.37 | pabelanger | Qwell: is there a JIRA issue? |
| 16:09.54 | Qwell | ASTERISK-18109 |
| 16:11.04 | *** join/#asterisk-dev Damin (~damin@www.gjbent.com) |
| 16:11.25 | Damin | 1 |
| 16:11.28 | Qwell | 2 |
| 16:11.42 | Damin | I have forgotten how to use IRC.. |
| 16:11.58 | Damin | I see that the more things change, the more they stay the same.. |
| 16:14.19 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:15.18 | file | you missed the zombie invasion |
| 16:17.37 | Damin | Damn.. |
| 16:17.52 | Damin | I had my weapons all polished and ready. |
| 16:18.23 | Damin | I realize this is a stupid question for #asterisk, but.. does anyone have any idea what version of Asterisk Switchvox 5.x is using? |
| 16:19.08 | file | that's a question. |
| 16:20.03 | opticron | you'd have to ask switchvox |
| 16:24.13 | Damin | Bahh.. no one there knows. ;) |
| 16:25.07 | opticron | or get console on it and compare available features and behaviors with known versions of asterisk |
| 16:32.33 | Damin | opticron: Ohh no.. THAT would VOID MY WARRANTY!!! :) |
| 16:32.41 | opticron | probably |
| 16:34.12 | Damin | It also means that I have to down my PBX, plug in a monitor and keyboard, install a CD-rom and boot from a recovery disk.. |
| 16:34.42 | Damin | That is too much like work.. |
| 16:34.59 | mvanbaak | lol |
| 16:35.12 | Damin | Anyways.. reason I'm asking is that all Switchvoxes that we upgraded to Version 5 now fail about 50% of their DTMF when using RFC 2833. |
| 16:35.36 | mvanbaak | meh, talk to oej about DTMF ;) |
| 16:35.39 | Damin | Switchvox support said "Use SIP INFO" |
| 16:35.43 | mvanbaak | he will probably kill you |
| 16:35.58 | Damin | Already had that conversation with him earlier this morning. ;) |
| 16:36.10 | opticron | huh |
| 16:36.12 | opticron | that sounds bad |
| 16:36.48 | Damin | What.. that I talked with OEJ? Or that Switchvox support said "Use SIP INFO" |
| 16:37.00 | mvanbaak | or the killing ;) |
| 16:37.11 | Damin | Short story is that SIP INFO solved the problem, but it is not a fix. |
| 16:37.33 | Damin | Call path is Switchvox to Asterisk 1.4 to L3 Sip Termination. |
| 16:37.43 | Damin | All other SIP PBX products work fine. |
| 16:37.53 | Damin | Switchvox 4.x and earlier work fine. |
| 16:37.59 | Damin | Switchvox 5.x == THE SUCK! |
| 16:38.03 | mvanbaak | dont upgrade |
| 16:38.26 | Damin | mvanbaak: Not my choice. Was called in AFTER all of the clients were upgraded.. |
| 16:38.27 | pabelanger | Qwell: So, how do we want to tag ASTERISK-18109 to be includes into 1.8.6.0-rc2? |
| 16:38.34 | pabelanger | is a tag created in JIRA> |
| 16:38.56 | Damin | mvanbaak: Nothing like testing a new revision before you roll it out to all your clients, right? |
| 16:39.05 | mvanbaak | Damin: amen! |
| 16:39.18 | mvanbaak | hhmm, I should really get used to jira ;) |
| 16:44.20 | pabelanger | Damin: Ya, nobody here would know the deeds about switchvox, since it is a Digium product. You'll have to contact Digium support |
| 16:44.42 | Damin | pabelanger: Done. Totally clueless. ;) |
| 16:44.59 | Damin | pabelanger: As I said, their suggestion was "Use SIP INFO" :) |
| 16:45.52 | pabelanger | Possible, but something like switchvox is out of the scope of this channel |
| 16:46.15 | *** join/#asterisk-dev kpfleming (user2@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:46.15 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:46.33 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:20ae:20ac:5822:3a72) |
| 16:53.53 | Damin | pabelanger: oh my. Aren't we touchy these days about "scope"? I haven't been on here in about 2 years, but has it changed that much? |
| 16:54.35 | pabelanger | touchy, no. Just trying to keep things on topic |
| 16:55.59 | mvanbaak | can I mix a gin/tonic for anyone ? |
| 16:56.09 | mvanbaak | going to make me one, and 'sharing is caring' |
| 16:56.18 | Qwell | mvanbaak: yes. Make mine without the tonic though. |
| 16:56.36 | mvanbaak | one gin/tonic without tonic on it's way sir! |
| 16:58.16 | opticron | mix in some peppermind schnaaps to make it taste like christmas |
| 16:58.25 | opticron | s/d/t/ |
| 16:58.34 | opticron | blinks |
| 16:58.41 | kpfleming | s/aa/ap/ |
| 16:58.44 | opticron | that was unexpected |
| 16:58.57 | kpfleming | infobot: botsnack |
| 16:58.57 | infobot | kpfleming: :) |
| 17:05.43 | pabelanger | heh, the testsuite does not like -rcX in the asterisk version tag. |
| 17:05.50 | pabelanger | time for a patch |
| 17:14.08 | Damin | mvanbaak: Sorry.. Gin an Tonic is not in scope for this channel. :) |
| 17:14.27 | mvanbaak | Damin: lol |
| 18:13.37 | anonymouz666 | when you are stress testing asterisk injecting lots of calls and then you stop everything... after that if the 'core show locks' output something, that means a deadlock? |
| 18:14.54 | kpfleming | no |
| 18:15.07 | kpfleming | there could be various locks held even in a relatively idle system |
| 18:15.18 | kpfleming | you are looking at a snapshot of a live system |
| 18:18.56 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |
| 18:39.06 | *** join/#asterisk-dev kpfleming (user2@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:39.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 18:40.58 | korch | so i want to generate a function call graph on my simple extension that dials out and connects a second leg through a local channel, just so i can "see" how some under the hood stuff works |
| 18:41.05 | korch | anyone know if a gdb hack like this might work? |
| 18:41.06 | korch | http://blog.superadditive.com/2007/12/01/call-graphs-using-the-gnu-project-debugger/ |
| 18:44.09 | kpfleming | call graphs are hard to do when multiple threads are involved |
| 18:48.51 | korch | :( |
| 18:49.28 | russellb | if you just want an intro into how things are put together ... http://www.aosabook.org/en/asterisk.html |
| 18:49.37 | *** join/#asterisk-dev kpfleming (user2@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:49.38 | korch | i've read that whole book :) |
| 18:49.47 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 18:55.59 | *** join/#asterisk-dev mickecarlsson (~Micke@h10n3c1o1101.bredband.skanova.com) |
| 19:08.53 | acidfoo | into: asterisk 1.4.42, main/utils.c : int ast_dynamic_str_thread_build_va() |
| 19:08.59 | acidfoo | the line; res = vsnprintf((*buf)->str + offset, (*buf)->len - offset, fmt, ap); |
| 19:09.46 | acidfoo | what if there is no string ;/ |
| 19:14.12 | acidfoo | well, what im tracking might be somewhere else.. |
| 19:14.17 | acidfoo | sigh |
| 19:15.05 | Qwell | acidfoo: The str pointer would still point to something. |
| 19:15.20 | pabelanger | otherwiseguy: ping |
| 19:16.20 | acidfoo | Qwell, yeah, I think my probleme is somewhere else finally, thanks for looking btw :) |
| 19:19.19 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:19.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:53.38 | *** join/#asterisk-dev oej (~olle@195.41.130.3) |
| 19:53.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:55.56 | pabelanger | russellb: so I am looking at your __parse_svn_version() function in the testsuite, and working on adding support for -betaX and -rcX within the asterisk version tag. I have it working for only -rcX tags, but curious if you know how to get the re.search() to include both (-rc, and -beta)? |
| 19:56.38 | pabelanger | my patch: http://pastebin.com/285fYswn |
| 19:58.21 | russellb | with some regex magic, heh |
| 19:58.26 | russellb | it would take me a few minutes to work it out |
| 19:58.57 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-utaaqognsijqyzxs) |
| 20:00.00 | pabelanger | Yup, that is the trouble I am having too. Time for google |
| 20:03.25 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-bcxhnittfkuzbbmw) |
| 20:05.14 | sruffell | hehâ¦..reminds me of the regex quote: http://www.codinghorror.com/blog/2008/06/regular-expressions-now-you-have-two-problems.html for those of you who haven't ever seen it. |
| 20:05.55 | sruffell | â¦just the Zawinski quote..not the other stuff... |
| 20:07.42 | opticron | alternatively: http://xkcd.com/208/ |
| 20:08.08 | opticron | regex hero |
| 20:09.01 | pabelanger | well, I'm trying to match both '-rc' and '-beta' in regex command. I would always just use too |
| 20:09.06 | pabelanger | s/too/two/ |
| 20:10.46 | opticron | if you can't figure out the regex, I might be able to help |
| 20:15.39 | otherwiseguy | So, does anyone understand why in ast_sockaddr_stringify_fmt, we specifically check for ast_sockaddr_ipv4_mapped, and then set the sockaddr address we send to getnameinfo to a completely unitialized ast_sockaddr struct instead of just passing in the sockaddr that was passed to ast_sockaddr_stringify_fmt in the first place? |
| 20:16.15 | otherwiseguy | It seems very wrong and crazy too me. But it looks like it was done on purpose, which gives me pause. |
| 20:17.41 | otherwiseguy | ugh, s/too/to/ |
| 20:19.21 | otherwiseguy | of course, I also just looked at something a little weird too. didn't notice that ast_sockaddr_ipv4_mapped wrote to its argument. |
| 20:19.59 | otherwiseguy | freebsd doesn't choke on the netsock2 test when that call is removed, though. |
| 21:22.20 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-flkhkahiyblfszad) |
| 21:27.06 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 21:27.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:55.06 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 23:41.13 | *** join/#asterisk-dev matiasjrossi (~matias@host207.190-138-186.telecom.net.ar) |
| 23:41.30 | *** part/#asterisk-dev matiasjrossi (~matias@host207.190-138-186.telecom.net.ar) |