| 00:31.32 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 00:32.22 | Agro | Oh! I think I can do a memcpy to the position of the dataptr plus the amount of samples I've already read in.... |
| 00:33.16 | Corydon76-home | No, plus the byte-length of the data |
| 00:33.29 | Agro | Right, that |
| 00:33.31 | Corydon76-home | Samples is half that, because samples are two bytes apiece |
| 00:33.35 | Agro | But that would fix the reallocation problems, right? |
| 00:34.20 | Corydon76-home | Repeat with me: the value returned from malloc or realloc MUST be passed back to realloc, NOT that value plus any number at all. |
| 00:34.37 | Agro | no, this was what i was thinking: |
| 00:34.54 | Agro | dataptr = (short*)realloc(dataptr, newlength * sizeof(short)); |
| 00:35.22 | Agro | then i would do memcpy(dataptr+totalength, f->data.ptr, f->samples) |
| 00:35.23 | Corydon76-home | And as kpfleming pointed out, the right answer is to feed the frame into the dsp routines which process the stream and keep state. |
| 00:35.25 | Agro | and remove the increment |
| 00:35.45 | Agro | oh, tahts how the faxing tone detection works... |
| 00:35.46 | Corydon76-home | The dsp routines feed out a stream of DTMF |
| 00:36.01 | Agro | From dsp.c, I would need to use the tone_detect method then |
| 00:36.28 | Corydon76-home | Follow how it's done elsewhere; it will be much easier. |
| 00:36.47 | Agro | There is no where else, from what I've seen. :/ |
| 00:37.00 | Corydon76-home | Nowhere else to do what, exactly? |
| 00:37.24 | Agro | well the tone detection thing i was trying to do, but since you mentioned process it by frames, im looking at how faxing is detected now |
| 00:37.51 | Agro | yeah, seems much easier |
| 00:37.55 | Corydon76-home | Fax detection is done exactly the same way as DTMF detection |
| 00:38.10 | Agro | in dsp.c, it just uses the tone_detect function |
| 00:38.22 | Corydon76-home | In fact, the fax signal outputs through the DTMF frame system |
| 00:38.29 | Agro | oh |
| 00:38.44 | Agro | but dsp.c has all my answers, right? |
| 00:38.53 | Corydon76-home | Well, not the signal itself, but the signal that a fax is coming through |
| 00:39.10 | Corydon76-home | 2100Hz, IIRC |
| 00:39.14 | Agro | 1100hz |
| 00:39.32 | Corydon76-home | Well, whatever |
| 00:39.47 | Agro | yeah, 2100 and 1100 |
| 00:40.02 | Corydon76-home | Comes through as DTMF 'f' |
| 00:40.17 | Agro | f? |
| 00:40.18 | Corydon76-home | Or 'F', something like that |
| 00:40.40 | Corydon76-home | Yeah, DTMF is 0-9 A-D, so we borrowed another letter for the fax detection |
| 00:43.43 | Agro | ohh |
| 00:44.24 | Agro | i think this would be some good shortened code to do it hopefully http://pastebin.com/vbZvW002 |
| 00:46.14 | Corydon76-home | You can't call tone_detect() directly, as it's a static function, unless you're modifying dsp.c, and we don't recommend that you do that |
| 00:46.38 | Agro | i moved all the functions i needed to my source file |
| 00:46.39 | Agro | :) |
| 00:46.51 | Corydon76-home | You really shouldn't do that |
| 00:46.55 | Agro | wouldnt it work? |
| 00:47.09 | Corydon76-home | Given your lack of knowledge of C, I doubt it |
| 00:47.27 | Agro | well i got it to compile |
| 00:48.14 | Corydon76-home | Use the APIs. I am not prepared to help you debug DSP code. |
| 00:49.09 | Agro | ive been trying for a few days now... no solutions :/ |
| 00:49.24 | Corydon76-home | I do know some of how it works in theory. Other than management routines, however, I never monkey with that code, because without a good knowledge of it, you're going to be screwed when anything goes wrong. |
| 00:50.00 | Agro | yea |
| 00:50.08 | Corydon76-home | You should treat the code like a black box and ONLY use the public APIs |
| 00:51.05 | Corydon76-home | Unless you're a mathematician, sound engineer, and a good computer programmer, messing with DSP routines is usually a bad idea. |
| 00:51.11 | Agro | :/ |
| 00:51.16 | Agro | The APIs dont give me access to what i want |
| 00:51.26 | Corydon76-home | I suspect they do. |
| 00:51.40 | Agro | kpfleming even said the header files dont |
| 00:51.40 | Corydon76-home | You probably just don't know how to use them |
| 00:51.51 | Agro | some of the DSP functions dont even work <.< |
| 00:51.58 | Corydon76-home | What is it, exactly, that you're trying to do? |
| 00:52.12 | Agro | Detect a tone of x frequency for x amount of time |
| 00:52.27 | Corydon76-home | which tones? |
| 00:52.41 | Agro | 2600hz, for one |
| 00:52.56 | Corydon76-home | Why that tone? |
| 00:53.09 | Agro | well, im doing it for a certain website that gives you "challenges" to do |
| 00:53.24 | Agro | i wrote a pbx framework in c with asterisk, now im stumped on tone detection |
| 00:53.43 | Agro | and the first challenge for pbx will be to produce a 2600hz sound |
| 00:54.05 | Corydon76-home | Produce or detect? |
| 00:54.14 | Agro | the user will have to produce it |
| 00:54.23 | Agro | asterisk will have to detect it |
| 00:54.29 | Corydon76-home | Ah |
| 00:55.27 | Agro | so any suggestions to do this? |
| 00:57.19 | Corydon76-home | Yes |
| 00:57.28 | Corydon76-home | Look at ast_fax_detect_init() |
| 00:58.05 | Corydon76-home | You're going to create another version of that exact same function, but instead of the fax tones, you're going to use the 2600Hz tone |
| 00:58.21 | Corydon76-home | And then once you create that, add it to the header file |
| 00:58.31 | Agro | so recompile asterisk? |
| 00:59.36 | Corydon76-home | You'll have to, yes |
| 00:59.44 | Agro | and also, some parameters im confused with |
| 00:59.44 | Agro | static void ast_tone_detect_init(tone_detect_state_t *s, int freq, int duration, int amp, unsigned int sample_rate) |
| 00:59.50 | Agro | what is amp and sample_ratE? |
| 01:00.31 | Agro | well sample rate is probably 8 i think, or 16 for faxes |
| 01:00.33 | Corydon76-home | Your sample rate is whatever sample rate you're receiving from the remote end, usually 8000 |
| 01:00.39 | Agro | oh |
| 01:01.02 | Agro | whats amplitude? |
| 01:01.48 | Corydon76-home | IIRC, it's volume, measured in dB |
| 01:02.12 | Agro | so basically noise? |
| 01:02.34 | Corydon76-home | No, not noise. How loud the signal is, coming over the wire |
| 01:03.04 | Agro | ok |
| 01:03.15 | Corydon76-home | The larger the amplitude, the louder the signal |
| 01:03.27 | Agro | ah |
| 01:03.39 | Corydon76-home | frequency is what determines tone, amplitude, the volume |
| 01:04.01 | Agro | oh |
| 01:04.48 | Corydon76-home | Looks like faxes are at 16dB |
| 01:04.57 | Agro | yeah |
| 01:06.02 | Agro | and the duration is how long the frequency your looking for is played,? |
| 01:06.10 | Corydon76-home | Correct |
| 01:06.22 | Agro | ok |
| 01:06.33 | Corydon76-home | Also measured in milliseconds |
| 01:06.40 | Agro | right |
| 01:06.58 | Corydon76-home | Just remember that the sample rate is NOT in milliseconds |
| 01:07.25 | Agro | ok |
| 01:08.06 | eZz | Agro: hey are you continue working on tone detection ? |
| 01:08.16 | Agro | Yeah, I'm getting there |
| 01:08.23 | Agro | brb |
| 01:08.50 | eZz | have a great day folks, gonna sleep, it's 4am here ;) |
| 01:13.11 | Corydon76-home | Agro: once you have that, modify the section of ast_dsp_process that does the generation of DTMF to generate your special DTMF digit |
| 01:13.40 | Corydon76-home | Basically, look for cng_tone_state within the file to find it |
| 01:14.32 | Corydon76-home | Or possibly even create another element within struct ast_dsp, using that same type with your own custom name |
| 01:14.55 | Corydon76-home | That way, you can detect both fax and your 2600Hz tone at the same time |
| 01:15.50 | Corydon76-home | seizetrunk_tone_state or whatever |
| 01:16.19 | Agro | right |
| 01:16.38 | Agro | wait, generation of DTMF to generate your special DTMF digit? |
| 01:17.09 | Corydon76-home | How else are you going to handle it in the dialplan? |
| 01:17.22 | Agro | I have to generate something to handle it? |
| 01:17.47 | Corydon76-home | You've detected it; now you want to do something special when that happens, right? |
| 01:17.54 | Agro | oh |
| 01:18.02 | Agro | i was thinking i could do that in my module |
| 01:18.30 | Agro | just have the function to detect it inside asterisk, then when it detects it, the module handles it |
| 01:18.38 | Corydon76-home | Possibly |
| 01:18.49 | Agro | yeah |
| 01:18.51 | Corydon76-home | What are you going to do when you get that event, though? |
| 01:19.00 | Agro | well, the user completes the mission |
| 01:19.15 | Agro | Oh, and the missions are C scripts |
| 01:19.33 | Agro | The Tone Detection thing will be a module that uses the functions ill write to detect the 2600hz thing |
| 01:19.36 | Corydon76-home | You're not going to make them dial a number, now that they've seized the trunk, and receive a message? |
| 01:19.57 | Agro | seized the trunk? |
| 01:20.15 | Corydon76-home | You don't know what the 2600Hz tone did? |
| 01:20.39 | Agro | oh, long distance calls |
| 01:20.55 | Corydon76-home | Kind of |
| 01:21.17 | Corydon76-home | Back in the early 80s (and before), telephone trunks were signalled inband |
| 01:21.22 | Agro | phone phreaking |
| 01:21.29 | Agro | thats basically what im trying to simulate here |
| 01:21.36 | Corydon76-home | 2600Hz was the tone used by the phone computer to indicate that a trunk was free. |
| 01:21.45 | Corydon76-home | no longer in use |
| 01:22.00 | Agro | yeah |
| 01:22.09 | Corydon76-home | So the phone phreakers learned to play the tone and gain access to the unbilled trunk |
| 01:22.23 | Agro | people like wozniak and jobs :) |
| 01:22.45 | Corydon76-home | Once they played the tone, they could then dial any number and it would be billed as time for the first number they dialled, usually a local call |
| 01:23.13 | Corydon76-home | People like Cap'n Crunch, of the famed whistle |
| 01:23.50 | Agro | capn crunch is back in the market :) |
| 01:23.52 | Corydon76-home | Toy whistle packed in cereal boxes that just happened to generate a perfect 2600Hz tone |
| 01:24.14 | Agro | lol pure coincidence |
| 01:24.19 | Corydon76-home | Yes |
| 01:24.57 | Agro | do you know how long they had to whistle it? |
| 01:25.06 | Agro | (setting up the function in dsp.c right now) |
| 01:25.07 | Corydon76-home | I don't, no |
| 01:25.16 | Agro | oh, guess ill just put the fax one for now |
| 01:25.22 | Agro | and decibals... |
| 01:26.03 | Agro | i hope 16 will work xD |
| 01:26.38 | Corydon76-home | I hope you're testing this |
| 01:26.51 | Agro | i have no idea how to measure decibals |
| 01:27.31 | Corydon76-home | Ask the website you're doing this for if they have a Cap'n Crunch whistle you can use to test this |
| 01:27.56 | Agro | well theres this application for tone generation |
| 01:28.03 | Corydon76-home | Since we know that was used in the day and we know it worked, it is the best possible test |
| 01:28.08 | Agro | does the sound have to be external? |
| 01:28.12 | Agro | or can it be from the computer itself |
| 01:28.36 | Corydon76-home | When it's processed by Asterisk, it's just a stream of packets |
| 01:29.08 | Corydon76-home | A computer cannot "hear"; it can only process |
| 01:29.20 | WIMPy | can't you just use Asterisks R1 support instead of sumulating it on top? |
| 01:29.57 | Corydon76-home | WIMPy: I doubt he's using any hardware |
| 01:30.12 | WIMPy | Do you have to use hardware? |
| 01:30.22 | WIMPy | Well, I guess so. |
| 01:30.34 | Corydon76-home | I think so, to get the stream into DAHDI |
| 01:31.06 | Agro | our aterisk server has DAHDI |
| 01:31.10 | WIMPy | Well, I've never tried it, but Andreas put R2 support in to LCR. Probably after finding an old bluebox in the attic. |
| 01:31.17 | WIMPy | You could probably (ab)use that. |
| 01:31.47 | Corydon76-home | Yeah, and then there's several countries still using it |
| 01:31.53 | Agro | brb |
| 01:31.58 | WIMPy | Ugh |
| 01:32.30 | Corydon76-home | I remember a guy deployed to South Korea who realized the military base was still using 2600Hz signalling |
| 01:33.03 | WIMPy | Well, they use all kinds of interesting stuff. |
| 01:34.08 | WIMPy | Some ppl there dial from one DISA-like thing to another to get access to round about anything. |
| 02:00.40 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 02:27.13 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-szydmseaeeftzfel) |
| 02:29.03 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-ztaygdjislcjcnsh) |
| 07:41.23 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 08:11.10 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:11.10 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:14.35 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 08:27.39 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 09:07.10 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 10:14.40 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 11:30.28 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:30.29 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:12.42 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ptimzzlqovyukksn) |
| 12:12.42 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:14.43 | *** join/#asterisk-dev micols (~t@rlogin.dk) |
| 13:36.50 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-njhuurauenuordmw) |
| 13:42.54 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:43.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:47.38 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 13:59.13 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:59.13 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:03.57 | kpfleming | umm... did pabelanger misunderstand that the ICE/etc. patch will include the relevant bits of pjproject in the asterisk source tree? |
| 14:04.25 | kpfleming | they aren't in the review, though, for what should be obvious reasons |
| 14:05.28 | file | kpfleming: I specifically mentioned discussing how exactly we want to approach that from a build perspective |
| 14:06.28 | kpfleming | oh, right |
| 14:06.34 | kpfleming | well, but from a different viewpoint |
| 14:07.06 | kpfleming | you mentioned whether we should extract some bits and use our own build system, or use their build system. in either case, though, the relevant bits will be in the asterisk source tree, and not provided by an external dependency. |
| 14:07.43 | file | aye |
| 14:09.04 | russellb | does their stuff just not lend itself to packaging? |
| 14:09.13 | russellb | without serious effort? |
| 14:09.46 | file | correct. |
| 14:10.33 | pabelanger | russellb: Right. I'm trying to find the history of why it is not included into Debian. This is my main concern |
| 14:11.07 | russellb | yeah, bundling code is generally considered evil, but if it just sucks for that, and nobody is willing to fix it, oh well |
| 14:12.18 | kpfleming | the pjproject build system is designed for direct embedding/linking, not packaging |
| 14:12.53 | russellb | which probably makes sense for their customers using it in proprietary applications |
| 14:12.56 | russellb | not so much for linux distributions |
| 14:13.00 | file | right |
| 14:13.28 | kpfleming | there are also many, many build options, and the code doesn't have a way to turn those features on and off at run time |
| 14:15.58 | russellb | boo |
| 14:16.14 | file | it is frustrating |
| 14:17.20 | pabelanger | Ya, that's why I like the optional building of the code. If pjproject is found, build asterisk within, otherwise disable the functionality |
| 14:18.27 | russellb | pabelanger: the code would be in the tree |
| 14:18.44 | russellb | if it ever gets packaged, it could be made to use the package if found, then fall back to internal |
| 14:18.54 | russellb | but that seems like wishful thinking |
| 14:19.06 | file | unless you package it... yeahhhhh |
| 14:19.19 | file | gives russellb some cake |
| 14:19.46 | russellb | i'm not doing it unless the code doesn't require work |
| 14:19.59 | russellb | accepts cake |
| 14:20.27 | kpfleming | that's the same plan we followed for other libraries like gsm and such. for now, we bundle it, and if some distro decides to package it in a way that we can make use of it, then we can modify asterisk to use it. |
| 14:20.50 | russellb | nods |
| 14:20.51 | kpfleming | the same will be true for libopus when it appears. debian testing will have it, no other distro will, so we need to bundle the code. |
| 14:21.04 | russellb | orly |
| 14:21.14 | kpfleming | well, fedora 18 might. |
| 14:21.28 | kpfleming | but it will be in the minority for quite some time. |
| 14:21.38 | russellb | if someone can remind me when it's available, i can get it into fedora and EPEL |
| 14:22.00 | kpfleming | the code is in an Internet-Draft that is in IETF Last Call |
| 14:22.07 | kpfleming | and also available from a git repo |
| 14:22.17 | russellb | cool. |
| 14:22.39 | kpfleming | but i don't think the internal build system of it is prepared for packaging either. one of the debian guys is doing debian packages, though. |
| 14:23.07 | russellb | adds it to his stuff-to-package-if-i-get-bored-one-day file |
| 14:23.37 | kpfleming | oh lovely.. .there's already something else out there called libopus |
| 14:23.40 | file | if you get further bored you can clean out my front garden |
| 14:23.48 | russellb | file: nothx |
| 14:23.58 | file | I'll buy pizza |
| 14:24.07 | russellb | i'll take your pizza. |
| 14:24.13 | russellb | but i will not be your lawn bitch |
| 14:24.21 | file | no deal! |
| 14:24.55 | russellb | k. |
| 14:26.45 | kpfleming | russellb: already eats plenty of pizza, he doesn't need more |
| 14:28.29 | russellb | true story |
| 14:28.44 | russellb | still have over $500 on the gift card we won... |
| 14:30.05 | tzafrir_laptop | isn't the pjsip code packaged anywhere? |
| 14:30.27 | kpfleming | no... that's what we just documented here |
| 14:31.07 | tzafrir_laptop | libopus is probably not packaged only because the protocol is not properly defined |
| 14:31.28 | kpfleming | we were talking about the OPUS codec, not the libopus project |
| 14:33.23 | tzafrir_laptop | IIRC the celt developers got burned with "early versions" of celt being used in various places |
| 14:33.52 | kpfleming | the OPUS code is now in IETF Last Call, so it's very close to being complete |
| 14:36.06 | kpfleming | 'ron@debian.org' has been participating in the codec mailing list and talking about debian packaging of OPUS, as recently as April 19th |
| 14:36.54 | tzafrir_laptop | Ron Lee, yes |
| 14:38.02 | tzafrir_laptop | http://bugs.debian.org/610980 |
| 14:38.03 | kpfleming | thanks, didn't know his last name and he doesn't include it in his messages to the list |
| 14:40.45 | kpfleming | so i guess the packages for OPUS will have to be libopuscodec or something similar |
| 14:42.47 | kpfleming | although even that name is not 'official' as far as the IETF is concerned, it's not a trademark or anything. the only official name for a conforming implementation will be RFC 6xxx (whatever number gets assigned) |
| 14:43.07 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:43.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:25.32 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:18.04 | Juggie | zzzz |
| 16:18.57 | jsmith | Juggie: My thoughts exactly.... |
| 16:19.29 | Juggie | food for thought.... |
| 16:19.33 | Juggie | 160,000 |
| 16:19.42 | Juggie | 24hrs |
| 16:19.44 | Juggie | that is all,. |
| 16:19.55 | Juggie | :) |
| 16:45.31 | *** join/#asterisk-dev hehol (~Adium@ip-178-202-243-147.unitymediagroup.de) |
| 17:02.52 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-igchgweufiwqpwoq) |
| 17:08.46 | pabelanger | BTW: was just sent this URL from #debian-voip, seems fedora is hard at work trying to package pjsip: https://bugzilla.redhat.com/show_bug.cgi?id=728302 |
| 17:08.48 | pabelanger | russellb: ^ |
| 17:29.21 | jsmith | pabelanger: Scary, isn't it? |
| 17:29.51 | russellb | oic |
| 17:32.22 | pabelanger | indeed |
| 17:48.16 | *** join/#asterisk-dev F|shie (~chatzilla@182.177.125.72) |
| 17:52.51 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-80-31.hsd1.tn.comcast.net) |
| 17:52.52 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 18:23.12 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 18:24.29 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:24.29 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 18:26.50 | Agro | hi kpfleming |
| 18:27.25 | kpfleming | Agro: hello |
| 18:28.22 | Agro | I'm just modifying Asterisk itself to do the tone detection. Everything else is kind of complicated lol |
| 18:28.48 | eZz | hi |
| 18:28.53 | Agro | hi |
| 18:28.55 | eZz | Agro: did you finished a patch ? |
| 18:29.05 | Agro | on asterisk? |
| 18:29.17 | eZz | yup |
| 18:29.57 | Agro | Nope, I'm working on it right now. I figured out that there's some sort of makefile to prevent compiling the whole asterisk again |
| 18:30.07 | Agro | just the edited files and its dependencies |
| 18:30.30 | kpfleming | yes, that's how the build system works |
| 18:30.50 | Agro | thats helpful |
| 18:31.01 | Agro | who knows how many times im going to recompilie XD |
| 18:31.25 | kpfleming | a lot, i suspect :-) |
| 18:32.33 | eZz | heh |
| 18:32.56 | eZz | i have own build system, my svn storage and night builder from my storage |
| 18:33.21 | Agro | Well, Corydon76-home told me I could make the tone I want to detect's functionality similar to the faxing one |
| 18:34.00 | eZz | true |
| 18:35.06 | Agro | and i basically have to modify ast_dsp_process to do it. And since I want to know that the tone was detected for my module, I have to add an extra field in the ast_dsp struct to know that the tone was detected |
| 18:38.29 | eZz | looks like you wanna create a frequency meter |
| 18:38.53 | Agro | nah, im just doing 2600hz for now |
| 18:39.05 | Agro | thats basically the only reason im doing this <.< |
| 18:45.39 | Agro | i THINK im done with the code ._. not positive itll work |
| 18:46.30 | Agro | first ill test what im doing with a DTMF digit so i dont have compile anything ._. |
| 19:05.03 | *** join/#asterisk-dev F|shie (~chatzilla@182.177.9.247) |
| 19:43.40 | otherwiseguy | So, currently local channels are created with local_new() which takes an optional linkedid parameter. Both sides of the local channel are created by passing this linkedid to ast_channel_alloc. If linkedid is NULL, then the ;1 and ;2 channels both end up with separate linkedids (their own uniqueid). Seems like the ;2 should always have the same linkedid as ;1. Anyone familiar enough with the linkedid field to know whether or not |
| 19:44.45 | mjordan | otherwiseguy: your question was truncated at "whether or not" |
| 19:46.04 | otherwiseguy | nice |
| 19:46.23 | otherwiseguy | whether or not that is correct? |
| 19:47.24 | otherwiseguy | Also fun is if the linkedid *is* set the same on both, I randomly get 0, 1, or 2 LINKEDID_END events. |
| 19:47.49 | otherwiseguy | Also, I hate local channels. |
| 19:50.11 | putnopvut | otherwiseguy: in my 2 minute research into CEL and the linkedid, it makes sense to me for both local channels to have the same linkedid. |
| 19:51.30 | otherwiseguy | putnopvut: thanks. now to look at why I get random numbers of linkedid_end events. |
| 19:51.41 | putnopvut | I have a hunch on it, but I'm not sure if I'm correct. |
| 19:51.56 | putnopvut | It could be that both local channels are removed from the channels container very close to each other. |
| 19:52.16 | putnopvut | When determining if a particular linkedid is the "last" one, the CEL code searches the channel code to see if that's the case. |
| 19:52.27 | otherwiseguy | yeah. time between destruction and unlinking causing issues. |
| 19:52.40 | putnopvut | That's what came to my mind looking at the cel.c code. |
| 19:52.56 | otherwiseguy | that's about as far as I had got as well. |
| 19:53.00 | otherwiseguy | gotten |
| 19:53.53 | putnopvut | A Brit would have found "got" to be perfectly acceptable there :) |
| 19:54.05 | otherwiseguy | all I wanted to do was write some simple CEL tests... |
| 19:54.12 | otherwiseguy | :-) |
| 19:54.24 | putnopvut | How could a test be "simple" and involved chan_local? |
| 19:54.33 | putnopvut | s/ved/ve/ |
| 19:55.14 | otherwiseguy | Indeed. I was reusing the cdr tests and just adding matches for CEL as well. CDRTestCase pretty much dictates that you use local channels for some reason. |
| 19:55.34 | putnopvut | ah, seemed a good strategy |
| 19:59.56 | otherwiseguy | so, now I suppose I shall start staring at local_hangup. |
| 20:00.12 | otherwiseguy | I think I shall complain bitterly to myself while I do so. |
| 20:02.16 | putnopvut | I'm working on an interesting issue that involves SIP dialogs sticking around forever. The typical order of things is, Asterisk receives a BYE, sip_hangup() gets called, dialog auto destructs. However, in certain circumstances, such as an AGI script running in the 'h' extension that takes a long time to complete, it may be that instead, the order goes Asterisk receives a BYE, dialog auto destructs, and then sip_hangup() is |
| 20:02.16 | putnopvut | <PROTECTED> |
| 20:02.39 | putnopvut | In the latter case, the SIP dialog stays in memory forever because dialog_unlink_all() is never called. |
| 20:03.32 | putnopvut | Calling dialog_unlink_all() before sip_hangup() is a bad idea because it means that certain information that usually is logged in the hangup might not be logged (like the hangup cause). |
| 20:03.43 | putnopvut | So I have two potential ways of fixing this |
| 20:04.20 | putnopvut | Way #1: If __sip_autodestruct() is called and an owner channel is present, then reschedule destruction for later. Keep doing so until the owner is gone. |
| 20:05.00 | putnopvut | Way #2: If __sip_autodestruct() is called and an owner channel is present, set a flag on the dialog. In sip_hangup(), if this flag is set, then call dialog_unlink_all() so that the dialog gets cleaned up. |
| 20:05.32 | putnopvut | My initial thoughts leaned towards Way #2, but I'm curious if anyone thinks that Way #1 would be a better idea. |
| 20:06.09 | otherwiseguy | looks at chan_sip |
| 20:07.09 | putnopvut | Have a look at ASTERISK-19425 if you're interested in the issue. |
| 20:07.22 | putnopvut | My last comment shows how I was able to reproduce the problem. |
| 20:08.13 | putnopvut | It also mentions Way #2 as my current plan of attack. I just thought of Way #1 a second ago. |
| 20:20.47 | otherwiseguy | #1 seems pretty simple and keeps things all in one place, wheras #2 adds yet another dialog flag. As long as we are sure that #1 will eventually terminate, seems happy. |
| 20:21.04 | otherwiseguy | putnopvut: ^ |
| 20:21.35 | otherwiseguy | With an initial glance, seems like both would work equally well. |
| 20:21.41 | putnopvut | otherwiseguy: yeah, both methods depend on sip_hangup() being called eventually. |
| 20:22.21 | otherwiseguy | yeah. I was imagining the AGI getting hung forever…but if that happens, well, you have lots of problems. :-) |
| 20:22.36 | putnopvut | Yep. I think that's actually what's happening in the reporter's case. |
| 20:22.37 | putnopvut | BUT |
| 20:22.55 | putnopvut | He also has an RTP timeout, which with this change should result in the dialog getting destroyed properly. |
| 20:23.27 | putnopvut | In his case, there's a minute gap between when the AGI starts, then the RTP timeout hits, then the AGI starts going again, eventually calling sip_hangup() on the channel. |
| 20:23.42 | putnopvut | So in his case, the channel goes away, but the dialog sticks around forever. |
| 20:29.16 | kpfleming | it's an infinite protocol discourse |
| 20:41.25 | otherwiseguy | …and lunch. |
| 20:48.18 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 20:48.18 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:31.21 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 21:38.10 | Agro | In dsp.h, features are defined like this: #define DSP_FEATURE_FAX_DETECT(1 << 4) |
| 21:38.29 | Agro | How would I add in my own to detect another tone? |
| 21:42.51 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ptimzzlqovyukksn) |
| 21:46.24 | Agro | Corydon76-home, you here? |
| 22:35.40 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 23:00.21 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 23:00.21 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-ztaygdjislcjcnsh) |
| 23:00.21 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-szydmseaeeftzfel) |
| 23:00.21 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 23:00.21 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 23:00.22 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 23:00.22 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@66-232-81-197.ctcweb.net) |
| 23:00.22 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 23:00.22 | *** join/#asterisk-dev eZz (~ez@195.114.6.134) |
| 23:00.22 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 23:00.22 | *** mode/#asterisk-dev [+oooo putnopvut snuff-home snuff-work seanbright] by wolfe.freenode.net |
| 23:00.22 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 23:00.22 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 23:00.22 | *** join/#asterisk-dev tzanger (tzanger@wallace.mixdown.ca) |
| 23:00.22 | *** join/#asterisk-dev zh-home (~zerohalo@74.61.196.236) |
| 23:00.22 | *** mode/#asterisk-dev [+o ChanServ] by wolfe.freenode.net |
| 23:02.04 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:02.04 | *** mode/#asterisk-dev [+o pabelanger] by wolfe.freenode.net |
| 23:11.52 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 23:11.52 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:15.17 | putnopvut | Is res/ael/pval.c autogenerated? |
| 23:46.13 | *** join/#asterisk-dev russellb_ (~russellb@redhat/russellb) |
| 23:46.14 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 23:48.16 | *** join/#asterisk-dev mvanbaak_ (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 23:48.16 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 23:51.17 | *** join/#asterisk-dev GameGamer43 (u5533@gateway/web/irccloud.com/x-cetdyepmqwhkvxno) |
| 23:51.22 | *** join/#asterisk-dev sezuan (bouncer@irc.scheff32.de) |
| 23:54.29 | *** join/#asterisk-dev micols (~t@rlogin.dk) |