| 00:30.23 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 00:30.23 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:37.07 | *** join/#asterisk-dev greenwolf (6c79ab0f@gateway/web/freenode/ip.108.121.171.15) |
| 01:21.11 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 02:18.17 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 05:32.49 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 06:24.12 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 06:24.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:38.20 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 06:38.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:38.35 | oej | Morning folks |
| 07:30.20 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a978:b69a:dfe2:c7e7) |
| 07:50.49 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:50.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:51.17 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 09:19.59 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:19.59 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:21.47 | *** join/#asterisk-dev mjordan1 (~mjordan@75.76.55.191) |
| 11:21.47 | *** mode/#asterisk-dev [+o mjordan1] by ChanServ |
| 11:31.50 | oej | Afternoon folks |
| 11:32.03 | oej | mjordan: Committed the queue patch and put the sip stuff on reviewboard. |
| 11:33.02 | snuff-home | :) |
| 11:35.44 | mjordan1 | oej: excellent! |
| 11:35.57 | mjordan1 | must take dog to vet, be back later folks |
| 11:36.01 | *** part/#asterisk-dev mjordan1 (~mjordan@75.76.55.191) |
| 11:47.45 | *** join/#asterisk-dev ang-st (~pg@rsbac/developer/ang-st) |
| 11:51.08 | ang-st | hello |
| 11:51.51 | ang-st | i'm devellopping a little module that send audio frame |
| 11:52.28 | ang-st | and on rtp stream audio is scrambled |
| 11:52.52 | ang-st | http://imgur.com/EW26I54 |
| 11:53.37 | ang-st | the top waveform is grabbed from wireshark, the second from Monitor() app |
| 11:54.26 | snuff-home | how are you adding the frames.. using an audiohook or some other method ? |
| 11:56.48 | ang-st | i send ast_frame via ast_write |
| 11:57.44 | ang-st | something like this : pastebin.com/xXMv53ve |
| 11:58.00 | ang-st | along a while loop |
| 12:02.27 | snuff-home | unfortunately i cant help much.. as not RTP man.. but depending on what you want to do.. audiohooks might also be option.. |
| 12:02.45 | snuff-home | pitch change example ... funcs/func_pitchshift.c |
| 12:02.59 | snuff-home | also there is a funcs/func_volume.c |
| 12:04.06 | snuff-home | but are you saying that a mixmon output seems 'fine'.. but actual rtp sent isn't good ? |
| 12:04.30 | ang-st | yep, that's it |
| 12:04.45 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:06.10 | ang-st | i have extensions.conf and sip.conf setuped like that : http://pastebin.com/eSYavjvT |
| 12:08.00 | ang-st | so it's g711 alaw side to side and i have no warning about audio convertion or such |
| 12:09.11 | ang-st | i took example on res_fax.c for sending frame but i may have miss something |
| 12:15.52 | snuff-home | you just want to 'add' audio to existing stream ? |
| 12:16.29 | snuff-home | if so.. audiohook is probably nicer than dealing with raw frames |
| 12:17.36 | ang-st | snuff-home: no i generate audio frame from spandsp |
| 12:17.36 | snuff-home | and place to look for an example of 'whisper' with audiohooks is app_chanspy |
| 12:18.09 | ang-st | actually just a simple tone |
| 12:19.01 | snuff-home | k.. sorry i cant help.. maybe someone wiser will answer later |
| 12:19.28 | ang-st | thanks for your time anyway :) |
| 12:20.07 | ang-st | i'll hang around and even post on ml |
| 12:46.54 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 12:50.06 | oej | THanks for the quick responses to my review in chan_sip! |
| 12:55.39 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ifxobwkpypylejgp) |
| 13:04.34 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:04.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:21.40 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-qkmyhwejxtovrxdo) |
| 13:28.14 | seanbright | shouldn't the lower bound for the ast_slinear_saturated_* functions in utils.h be -32768 instead of -32767? |
| 13:30.56 | seanbright | minor issue to be sure, but looks wrong to me |
| 13:39.42 | ang-st | ok got it : messed up datalen and number of samples |
| 13:41.06 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:41.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:41.44 | *** join/#asterisk-dev coreyf1513 (~cfarrell@2001:4830:117f:3:68a7:4d6f:f748:ea84) |
| 13:42.10 | snuff-home | ang-st: good to hear |
| 13:44.23 | snuff-home | file: in relation to 'understanding' new res_sip.. a database table style diagram.. showing 1 to many.. many to many.. etc.. |
| 13:44.55 | jsmith | My definition of a happy Asterisk server: 239 active channels,139 active calls,2372664 calls processed |
| 13:45.38 | snuff-home | nice jsmith |
| 13:45.55 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 13:46.25 | jsmith | snuff-home: It's all putnopvut's fault -- he was the one who patched the problem we were having last fall :-) |
| 13:48.40 | *** join/#asterisk-dev coreyf1513 (~cfarrell@2001:4830:117f:3:68a7:4d6f:f748:ea84) |
| 13:50.50 | putnopvut | Ah yes, that one. |
| 14:09.51 | jsmith | putnopvut: I can't tell you how muchwe appreciate you tracking down that bug. Our senior VP of operations tried to kiss me the other day because he's been so happy about our call center's uptime |
| 14:10.01 | jsmith | (which was really awkward, but that's another story) |
| 14:11.26 | putnopvut | lol |
| 14:12.16 | leedm777 | Qwell: what's the recommended configure options for pjproject? |
| 14:14.41 | Qwell | leedm777: I'm going to document it soon. I use: configure --prefix=/usr --enable-shared --with-external-speex --with-external-gsm --with-external-srtp --disable-sound --disable-resample |
| 14:22.11 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-qlsntqfbvtkkfeaf) |
| 14:22.14 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-qlsntqfbvtkkfeaf) |
| 14:22.40 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-qlsntqfbvtkkfeaf) |
| 14:37.19 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-snlyquuaydxetzco) |
| 14:37.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:40.13 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:40.13 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:06.08 | *** part/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 15:31.17 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 15:31.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:43.11 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:46.26 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 15:46.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:54.55 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 15:54.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:19.44 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:19.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:24.19 | mjordan | hypotheticalish situation. Currently, when an outbound channel is created, we squelch any CDRs created for that channel unless they survive the bridging operation. That works fine today, and ensures that in a 2-party bridge you get a single record for A -> B |
| 16:24.54 | mjordan | consider a multi-party scenario, however, where A dials B and the two are bridged (one CDR), but then channel C enters the bridge. This should create records for A and C, but it should also have something noting the path of communication for B and C |
| 16:25.09 | mjordan | do we show B and C, even though B was an outbound channel? |
| 16:27.13 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-fozecshxwtwpykwa) |
| 16:28.38 | mjordan | hears the sound of crickets |
| 16:29.36 | Qwell | I was in Walmart the other day, in the sporting goods section. We walked by the box of crickets. It said "We are out of crickets." |
| 16:29.42 | Qwell | There was much chirping, coming from the box. |
| 16:29.54 | Qwell | I felt you should know. |
| 16:30.58 | file | mjordan, ...yes? |
| 16:31.11 | jsmith | mjordan, ...no? |
| 16:31.26 | Qwell | mjordan, ...beer? |
| 16:31.29 | mjordan | oh nos. Now I have competition. |
| 16:31.34 | jsmith | B didn't call C and C didn't call B... C just happened to call A who was bridged with B |
| 16:31.35 | mjordan | Qwell: 30 more minutes! |
| 16:31.41 | Qwell | wait, what? |
| 16:32.03 | jsmith | file: Your arguments for? |
| 16:32.15 | file | I'm not getting involved. |
| 16:32.22 | mjordan | jsmith: yeah, that's where it's kind of at now. It gets weird, however, when you have Originated channels who didn't call anyone but can talk to everyone |
| 16:32.39 | Qwell | How did C get into the bridge? |
| 16:32.55 | jsmith | mjordan: Yeah, it's awfully murky... especially when C probably didn't call A directly, but called the bridge |
| 16:33.18 | mjordan | yeah, that's the case here |
| 16:33.31 | Qwell | C called *something*, right? It didn't literally call the bridge. |
| 16:33.36 | mjordan | In fact, from the perspective of the CDR engine, it really only knows that all the parties can talk, it doesn't care a lot about how they got there |
| 16:33.40 | mjordan | Qwell: no, it can |
| 16:33.59 | mjordan | well, theoretically anyway |
| 16:34.26 | jsmith | mjordan: Well, it called an *extension*, that connected it to the bridge, right? |
| 16:34.29 | mjordan | In general, you would use Bridge, which could Bridge with either or A or B |
| 16:34.45 | mjordan | which means it's bridged with both A and B, because they were already in a Bridge |
| 16:34.48 | Qwell | jsmith: yes, that |
| 16:35.03 | mjordan | however, there are things in development that allow you to join a bridge based on the bridge identifier, as bridges are now first class objects (tm) |
| 16:35.09 | jsmith | As I see it, we should end up with two CDR records |
| 16:35.09 | file | conceptually you are bridging participants together, not just connecting to a bridge |
| 16:35.17 | jsmith | 1) A calling B |
| 16:35.24 | jsmith | 2) C calling the bridge |
| 16:36.30 | jsmith | but that's just me -- I tend to view CDRs as "Who dialed whom", and not "which audio got heard by whom" |
| 16:36.45 | mjordan | interesting |
| 16:36.48 | mjordan | I landed on the second half |
| 16:37.03 | mjordan | mostly because "Dial" ends up being so flaky |
| 16:37.13 | jsmith | Now, if we're talking about CEL, I'm on the second half |
| 16:37.18 | mjordan | noooooo |
| 16:37.24 | jsmith | stirs the pot |
| 16:37.52 | mjordan | I'm going to get a lot of Jira issues on this whole thing |
| 16:38.33 | jsmith | Not if we come up with a number of scenarios (Alice calls Bob, Charlie calls into the bridge between Alice and Bob based on bridge identifier" and vet them on the mailing list |
| 16:38.55 | *** part/#asterisk-dev ang-st (~pg@rsbac/developer/ang-st) |
| 16:38.58 | jsmith | Well, you'll still get the Jira issues filed, but you can close them with "This behavior was discussed and decided on the mailing list" |
| 16:40.08 | mjordan | jsmith: there's actually a spec on the wiki |
| 16:40.11 | file | cee dee arrrrrrrrrrrs |
| 16:40.35 | mjordan | which is currently under review |
| 16:40.58 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification |
| 16:41.17 | jsmith | mjordan: I'll go read that now |
| 16:41.28 | jsmith | file: cee dee ARRRGHs |
| 16:43.45 | mjordan | jsmith: it does need some updating here and there, but it's mostly still correct with how things have developed |
| 16:46.05 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-mevaedteynndlaes) |
| 16:53.33 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-mevaedteynndlaes) |
| 16:53.56 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 16:55.25 | jsmith | mjordan: OK, reading through what you have there, I still thing there should be two CDR records, one from Alice to Bob, and one from Charlie to an extension in the dialplan that joins the Bridge. If you think you can tie Charlie's call to Alice's call, put the samed LinkedID in Charlie's CDR record |
| 16:56.37 | mjordan | jsmith: I can definitely tie Charlie and Alice together |
| 16:56.47 | mjordan | as well as update the linkedid |
| 16:57.14 | mjordan | I think what the spec needs is a statement that "outbound channels don't participate in multi-party bridges" - with the knowledge that a channel is no longer 'outbound' if it survives the bridge |
| 16:57.45 | jsmith | I'm not sure I follow... |
| 16:58.36 | jsmith | When you say "outbound channels", do you mean Originated channels? |
| 16:59.34 | mjordan | I should have said 'dialed' |
| 17:00.12 | mjordan | originated are outbound, but are considered full participants. A dialed channel is outbound, but is automagically considered the Party B to any CDR created, and does not create subsequent records in a multi-party bridge |
| 17:08.42 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-uwxlbmqadblqmlqr) |
| 17:14.48 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 17:14.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:19.57 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-105-205-226.user.veloxzone.com.br) |
| 17:20.15 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 17:20.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:25.17 | *** join/#asterisk-dev italoros_ (~italoross@187.60.66.11) |
| 17:37.16 | file | grooves |
| 17:40.31 | jsmith | mjordan: Yeah, I can go along with that definition |
| 17:42.29 | *** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 17:46.12 | marv | my terrible chan_gulp rename suggestion: chan MOHMI. I'll let someone else decide what it stands for. |
| 17:49.43 | jsmith | Multiple Opportunities to Help Make Improvements :-p |
| 17:49.55 | jsmith | ducks and hides |
| 17:52.28 | mjordan | I'd vote for that... |
| 17:52.31 | file | when something works on the first try I question reality |
| 17:53.03 | Qwell | putnopvut, file: mind if I fix the merge props on pimp_my_sip, to reflect the merge to trunk? |
| 17:53.09 | file | Qwell, nope |
| 17:53.28 | Qwell | and should I re-enable automerge, afterwards? |
| 17:53.50 | putnopvut | Yes, that would be good. |
| 17:53.53 | putnopvut | Thanks! |
| 17:55.14 | Qwell | wait, did my --record-only actually delete a prop? wtf |
| 17:55.34 | Qwell | nevermind |
| 18:52.49 | seanbright | how goes the svn -> git migration? |
| 19:00.44 | putnopvut | In the manager Bridge action, does anyone know why the courtesy tone is only played to the second channel? Any reason why it couldn't be played to both? |
| 19:01.28 | putnopvut | I'm guessing it was just designed that way by whoever wrote the manager action, but the rationale escapes me. |
| 19:06.09 | mjordan | putnopvut: sounds like an oversight to me |
| 19:35.59 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:48.49 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 19:48.49 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:54.50 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 19:54.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:54.28 | Kobaz | mmm |
| 20:54.40 | Kobaz | are there any parts of chan_sip that are dependent on having fast disk io? |
| 20:54.47 | Kobaz | call-processing wise |
| 20:54.51 | *** part/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 20:57.27 | Qwell | Kobaz: unlikely |
| 20:57.58 | Qwell | I mean, maybe if you got a ton of REGISTERs in a row, and had to shove them all in the astdb, but that's small, and not in the call path. |
| 20:58.49 | Kobaz | mm |
| 20:58.54 | Kobaz | i'm having lots of call path problems |
| 20:59.11 | Qwell | VM? Recordings? |
| 20:59.12 | Kobaz | and i rolled back to before my fix from the other day and i'm still having problems |
| 20:59.23 | Kobaz | call recording, average 30-40 channels |
| 20:59.30 | Qwell | that'd do it |
| 20:59.43 | Qwell | but, that's not really chan_sip. |
| 21:00.51 | Kobaz | well |
| 21:00.52 | Kobaz | mm |
| 21:01.57 | Kobaz | so the problems i have are like, a polycom trying to make a call and it retrys sending the invite like 5 times and gives up |
| 21:02.03 | Kobaz | asterisk never processes it |
| 21:02.15 | Kobaz | doing a tcpdump right on the server and i see the traffic |
| 21:02.30 | coreyf1513 | Kobaz: using monitor or mixmonitor? |
| 21:03.01 | Kobaz | mixmonitor |
| 21:03.07 | Kobaz | yeah i already went through that one |
| 21:03.20 | Kobaz | monitor onto a heavily loaded disk will drop audio frames |
| 21:08.03 | jsmith | Kobaz: Are you running out of file handles? |
| 21:11.15 | Kobaz | hmmmm |
| 21:11.33 | Kobaz | # lsof | wc -l |
| 21:11.34 | Kobaz | 16882 |
| 21:15.51 | jsmith | and ulimit -a? |
| 21:16.24 | jsmith | or, more precisely, ulimit -n |
| 21:16.57 | Kobaz | mm |
| 21:17.06 | Kobaz | ulimit -n 1024 ? |
| 21:17.08 | Kobaz | mmm wtf |
| 21:18.47 | leifmadsen | asterisk.conf: ;maxfiles = 1000 |
| 21:19.13 | Kobaz | oh |
| 21:19.36 | Kobaz | is that the default? |
| 21:20.29 | Kobaz | i bumped it up to 2000 |
| 21:20.55 | Kobaz | # lsof | egrep "^asterisk" | wc -l |
| 21:20.56 | Kobaz | 1031 |
| 21:21.24 | Kobaz | that's with like 4 channels going |
| 21:23.17 | Kobaz | it looks like there's supposed to be a 'core show fd' |
| 21:39.41 | coreyf1513 | Kobaz: that comes with a DEBUG_FD_LEAKS |
| 21:40.10 | Kobaz | ah okay |
| 21:40.52 | Kobaz | oo core show settings should hae it |
| 21:41.09 | Kobaz | <PROTECTED> |
| 21:48.09 | Kobaz | i think it's a load issue |
| 21:48.16 | Kobaz | my disk io on this machine is just crazy |
| 22:09.37 | jsmith | Kobaz: Probably your call recording -- are you using a ramdisk, and if so, what kind? |
| 22:52.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:52.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:02.59 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:02.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:13.17 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:13.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:15.39 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-tokumavesuouilex) |
| 23:26.11 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-snlyquuaydxetzco) |
| 23:26.21 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:26.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |