| 01:53.00 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.5) |
| 02:08.13 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:08.13 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 03:02.48 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 03:09.21 | philipp64 | howdy. got a question about patch #14930 in asterisk-1.6.1.0. it doesn't seem to be working properly in astlinux. we have it defined in include/pthread.h ... but I can't actually find it defined in any of the libraries. |
| 03:14.11 | philipp64 | we don't have pthread_rwlock_timedwrlock() and I can't figure out how to force it off. tried running "configure" with ac_cv_pthread_rwlock_timedwrlock="no" in the environment... |
| 03:25.08 | philipp64 | hmmm... seems that uClibc doesn't implement pthread_rwlock_timedwrlock() and I can't convince configure that I don't have it. |
| 03:25.18 | philipp64 | should I open a bug against this? |
| 04:08.55 | *** join/#asterisk-dev xpot (n=james@70.91.210.233) |
| 04:10.09 | *** join/#asterisk-dev felipe_ (n=felipe@my.nada.kth.se) |
| 04:30.31 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 04:35.14 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 05:07.07 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 05:32.18 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 05:53.23 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 06:02.29 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:35.42 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 07:03.13 | philipp64 | Qwell: you there? |
| 07:05.45 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:05.45 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:43.04 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 08:47.50 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 11:06.09 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 11:06.09 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:22.22 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:35.27 | *** join/#asterisk-dev Shazaum (n=Shazaum@unaffiliated/shazaum) |
| 11:44.13 | *** join/#asterisk-dev MrISDN (n=kkeil@p5497B07E.dip.t-dialin.net) |
| 11:55.55 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:55.55 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:04.47 | *** join/#asterisk-dev puzzled (n=foo@puzzled.xs4all.nl) |
| 12:14.23 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:14.23 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:33.27 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 12:52.06 | snuff-home | go leifmadsen go :) |
| 12:59.42 | leifmadsen | snuff-home: :D |
| 13:04.28 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:04.28 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:23.17 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:23.17 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:33.09 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 13:41.27 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 13:42.08 | *** part/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 13:42.17 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 13:42.56 | atis_work | Does anybody knows why GoSub is not working from features.conf, but Macro is? |
| 13:45.07 | atis_work | heh, wrong channel.. this is probably more -user'ish :) |
| 13:45.09 | kpfleming | well, that's interesting. Gosub relies on being called as an application in an already-executing PBX loop |
| 13:45.20 | kpfleming | Macro is itself a PBX loop |
| 13:45.33 | atis_work | oh.. |
| 13:45.41 | kpfleming | so if you call gosub from a dynamic feature, it modifies the channel's context/exten values and then returns |
| 13:45.52 | kpfleming | and expects the existing loop to jump to the new code |
| 13:45.55 | kpfleming | but there is no loop |
| 13:46.00 | kpfleming | so... nothing happens |
| 13:46.02 | atis_work | yeah, that seems correct :) |
| 13:46.08 | atis_work | a warning would be nice :) |
| 13:46.25 | kpfleming | there is a flag on the channel that indicates when the channel is in a PBX loop (AUTOLOOP or something like that) |
| 13:46.36 | kpfleming | gosub should check for that and emit a warning if the channel is not in a loop |
| 13:47.15 | atis_work | well, i'm still on 1.4 :) |
| 13:47.42 | atis_work | ok, so the next question - are the variables depending on pbx loop.. |
| 13:47.45 | kpfleming | that flag is presentin 1.4 |
| 13:47.52 | atis_work | but no warning |
| 13:48.17 | atis_work | i'm thinking of setting some variable within a feature and then reading it in bridge |
| 13:49.01 | kpfleming | no, my point is that adding the warning would be a useful patch |
| 13:50.12 | atis_work | ok, so here's "Attempt to reach a non-existent destination for gosub: (Context:%s, Extension:%s, Priority:%d)" in trunk |
| 13:50.41 | atis_work | only thing that relates to AUTOLOOP |
| 13:51.06 | atis_work | heh, that's probably not it |
| 14:00.08 | atis_work | ok, got a patch |
| 14:00.14 | atis_work | kpfleming: you forced me to do it :D |
| 14:00.27 | kpfleming | yes, that is it |
| 14:00.42 | kpfleming | AUTOLOOP is the proper flag |
| 14:00.52 | kpfleming | oh, that's a different warning you mean... never mind |
| 14:00.54 | kpfleming | it's early here :-) |
| 14:01.23 | atis_work | umm, sorry? |
| 14:01.37 | atis_work | the one i mentioned is not about that |
| 14:02.40 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:02.40 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:02.50 | atis_work | how was it.. warning or what for feature not executing? |
| 14:03.37 | atis_work | kpfleming: http://pastebin.ca/1429903 |
| 14:06.21 | *** join/#asterisk-dev xpot-mobile (n=james@static-66-182-88-85.bbsc.net) |
| 14:15.16 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:15.16 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:20.18 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.138.206) |
| 14:22.05 | kpfleming | atis_work: WARNING |
| 14:22.40 | atis_work | kpfleming: ok, so i thought correct. what about patch? should i post it in issue-tracker |
| 14:22.45 | atis_work | (damn-long-word) :D |
| 14:22.53 | kpfleming | yes, in the issue tracker |
| 14:23.38 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:23.38 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:26.56 | *** join/#asterisk-dev moy (n=moy@74.12.124.89) |
| 14:28.05 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:31.06 | atis_work | ok, done |
| 14:31.08 | atis_work | M15171 |
| 14:31.10 | MuffinMan | [assigned] [Asterisk] Applications/app_stack 0015171: [patch] Issue a warning, if trying to run gosub outside dialplan reported by atis (Karma: +18.00) https://issues.asterisk.org/view.php?id=15171 |
| 14:31.34 | atis_work | can i ask the original question now? question for a patch :D |
| 14:32.02 | atis_work | So, would it work if i set some variable in Macro called from features.conf and then read it from bridge code? |
| 14:36.09 | philipp64 | Qwell: ping? |
| 14:36.52 | Qwell | philipp64: I'll be around in a few hours |
| 14:37.21 | philipp64 | ok. I'll ask someone else then... just a quick one really: how does one turn off func_iconv? |
| 14:37.48 | philipp64 | I tried using --with-iconv=no and the makefile tries to build it anyway. |
| 14:38.02 | philipp64 | (uClibc doesn't support iconv) |
| 14:38.42 | Qwell | make menuselect |
| 14:41.10 | seanbright | we have a func_iconv? sweet. |
| 14:50.50 | tzanger | <PROTECTED> |
| 14:50.56 | tzanger | <PROTECTED> |
| 14:51.02 | tzanger | bah I had a space in there |
| 14:52.31 | seanbright | yes |
| 14:52.32 | seanbright | twice |
| 14:52.44 | seanbright | <PROTECTED> |
| 14:52.46 | seanbright | wooops |
| 14:52.50 | tzanger | haha |
| 14:58.00 | lmadsen | <PROTECTED> |
| 14:59.03 | seanbright | in life? |
| 15:00.24 | putnopvut | seanbright doesn't beat me, but he does occasionally make me cry. |
| 15:00.44 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 15:00.45 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:01.45 | mnicholson | ok, in the event of a transfer, the cdr record of the originator of the original call should follow the transferee in all cases. Does that make sense? |
| 15:02.41 | putnopvut | Even if the originator of the call isn't part of the call anymore after the transfer? |
| 15:03.13 | putnopvut | Does your logic say that because it is the same call, we should continue using the same CDR? |
| 15:03.49 | mnicholson | basically we just need to make sure the right person is billed |
| 15:03.57 | mnicholson | who should be billed in the event of a transfer? |
| 15:04.22 | putnopvut | That is an excellent question. |
| 15:04.23 | mnicholson | the transferer? the person who originated the initial call? |
| 15:04.24 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:04.25 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:04.52 | mnicholson | 1.4 cdr records don't really track enough info to delegate that question to the billing system |
| 15:05.00 | putnopvut | mnicholson: I imagine that if you asked 100 people that question, you would not find a consensus. |
| 15:05.09 | mnicholson | right |
| 15:05.30 | mnicholson | so perhaps there should be some sort of transfer option in cdr.conf |
| 15:05.54 | mnicholson | billontransfer=transferee/transferer/original |
| 15:05.55 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 15:08.25 | mnicholson | currently we generate a cdr record for each bridge, and one for each channel that was not bridged |
| 15:08.59 | mnicholson | during a transfer a bridge is torn down, that should generate a cdr record |
| 15:10.16 | mnicholson | here it gets a little tricky because the call can go through the dialplan now with out being bridged again and we might need to generate a cdr record for that. Also the call could be bridged again, in which case, we do need to generate a cdr record, but then we don't need to generate one for that channel |
| 15:12.02 | mnicholson | so, lets see. If a channel is hung up during a bridge, then we should not generate a CDR record for that channel (instead we will use the bridge's cdr record), but if a channel is hungup outside of a bridge, then we should generate a cdr record for that channel. Does that sound reasonable, especially in the event of transfers? |
| 15:13.22 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:13.22 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:16.56 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:29.37 | *** part/#asterisk-dev asteriskmonkey (n=philip@69.77.169.14) |
| 15:45.02 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:56.50 | *** join/#asterisk-dev Corydon76-dig (i=white@pdpc/supporter/bronze/Corydon76-home) |
| 15:56.50 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 16:26.28 | *** join/#asterisk-dev JerJer (n=PhatJ@asterisk/original-h323-guy/JerJer) |
| 16:28.34 | JerJer | anyone know the status of SRTP in asterisk? it seems oej's branch is gone now |
| 16:31.44 | *** join/#asterisk-dev otherwiseguy (n=otherwis@nat/digium/x-97336d59312f9607) |
| 16:31.51 | kpfleming | JerJer: ^^^ he does |
| 16:32.52 | JerJer | otherwiseguy: srtp? |
| 16:33.07 | leifmadsen | M5413 |
| 16:33.10 | otherwiseguy | JerJer: I'm going to need a little more to go on. |
| 16:33.17 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_sip/NewFeature 0005413: [branch] Secure RTP (SRTP) reported by mikma (Karma: +19.75) https://issues.asterisk.org/view.php?id=5413 |
| 16:33.43 | JerJer | all i needed was the new branch name |
| 16:34.03 | otherwiseguy | svn/asterisk/team/group/srtp I believe. |
| 16:34.26 | otherwiseguy | It isn't up to date with trunk due to the RTP engine changes |
| 16:34.27 | JerJer | yep - muffin man to the rescue |
| 16:35.09 | JerJer | if we can make it work with Zoiper and/or Linksys SPA everything is golden (at least for my current needs) |
| 16:35.42 | JerJer | if not the system i am setting up will be available for testing / debugment |
| 16:36.23 | Juggie | <PROTECTED> |
| 16:39.51 | *** join/#asterisk-dev jsmith (n=jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 16:39.51 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 16:39.53 | atis_work | Would a patch that modifies bridge config from feature would be accepted? |
| 16:40.08 | atis_work | i'm creating a quick workaround, and i wonder if i should write cleanly :) |
| 16:42.29 | JerJer | anyone ever considered making a FUNC JSON |
| 16:42.46 | JerJer | ? |
| 16:43.03 | atis_work | huh.. do you really need it.. there's not that much data in dialplan :D |
| 16:43.16 | JerJer | to parse results from a FUNC CURL |
| 16:43.19 | atis_work | there are kinds of array, but generally you don't use it |
| 16:43.20 | JerJer | easily |
| 16:44.05 | atis_work | no response to my question.. :( |
| 16:44.11 | atis_work | i'll write dirty little hack then :D |
| 16:47.10 | Corydon76-dig | JerJer: No, but there's an issue in the bugtracker to make JSON data available natively from AMI |
| 16:47.23 | Corydon76-dig | M14281 |
| 16:47.26 | MuffinMan | [ready for testing] [Asterisk] Core/ManagerInterface 0014281: [patch] JSON Manager Event Interface reported by PLL (Karma: +0.50) https://issues.asterisk.org/view.php?id=14281 |
| 16:47.42 | JerJer | two different operations |
| 16:48.15 | JerJer | i call web service via CURL in dialplan and need to parse results |
| 16:48.16 | Corydon76-dig | You want to parse incoming json data? |
| 16:48.35 | JerJer | i currently just do pipe seprated and have a macro, but its not very pretty |
| 16:49.05 | Corydon76-dig | I suppose you could do that with HASH(), as long as the structure wasn't very complicated |
| 16:49.18 | JerJer | hmm |
| 16:49.32 | JerJer | soo atttrib=value type stuff ? |
| 16:49.37 | Corydon76-dig | Right |
| 16:49.59 | Corydon76-dig | as long as you're dealing with a single level of containers, that's pretty easy |
| 16:50.34 | Corydon76-dig | Start putting containers within other containers, and it's more difficult |
| 16:50.38 | JerJer | perhaps 6 or 10 values |
| 16:50.45 | JerJer | scalar values |
| 16:51.04 | Corydon76-dig | Yeah, if it's all scalars, you're fine |
| 16:51.21 | Corydon76-dig | Would be very easy to write |
| 16:51.45 | JerJer | i'll have to look into hash |
| 16:51.53 | JerJer | now back to srtp :( |
| 16:52.03 | Corydon76-dig | There's already a mode for func_curl that permits introducing data directly into assignment to HASH() |
| 16:53.28 | Corydon76-dig | as long as the key/value pairs come back URL-encoded |
| 16:53.54 | JerJer | i did not know that |
| 16:54.00 | JerJer | glad i ask questions |
| 16:54.29 | Corydon76-dig | 1.6.2 and later |
| 16:54.51 | Corydon76-dig | Set(CURLOPT(hashcompat)=1) |
| 16:55.13 | JerJer | <PROTECTED> |
| 16:56.33 | JerJer | running srtp v1.4.2 |
| 16:56.49 | JerJer | srtp group branch |
| 16:58.21 | tzanger | kpfleming: you're a Dr. Pepper fan? |
| 16:58.30 | tzanger | (I seem to remember something along that line, but may be mistaken) |
| 17:11.20 | *** join/#asterisk-dev DarkRift (n=dark@bas1-sthubert21-1096590412.dsl.bell.ca) |
| 17:15.44 | *** join/#asterisk-dev CrashHD (n=CrashHD@65.74.156.108) |
| 17:22.14 | seanbright | line continuations should use... spaces? tabs? |
| 17:22.24 | seanbright | it's not in the coding guidelines. |
| 17:24.00 | seanbright | not continutions... just wrapped |
| 17:24.10 | seanbright | ast_log(LOG_NOTICE, "...", |
| 17:24.24 | seanbright | <PROTECTED> |
| 17:24.34 | seanbright | <PROTECTED> |
| 17:24.50 | seanbright | ^^^^^^^^ those should be spaces? |
| 17:26.14 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 17:30.01 | Corydon76-dig | seanbright: indented by tabs |
| 17:30.26 | Corydon76-dig | seanbright: and generally one more tab than the originating line |
| 17:33.10 | seanbright | alrighty. |
| 17:33.12 | seanbright | danke. |
| 17:55.49 | russellb | prefers 2 tabs in that case |
| 17:55.57 | russellb | but our guidelines don't specify for that situation :-) |
| 17:59.16 | otherwiseguy | JerJer: I seem to remember running into that libsrtp fPIC issue once before. Seems like I had to compile libsrtp from source instead of using the package that was available from the distro? It's been a while, so I could be losing my mind. May have had to manually add the fPIC flag in the Makefile? |
| 18:03.38 | kpfleming | tzanger: fan would be an extreme understatement |
| 18:04.13 | tzanger | kpfleming: have you tried Mr. Pibb? I have never heard of it before now |
| 18:04.22 | kpfleming | yes |
| 18:04.26 | tzanger | apparently it's got an equally ... vocal following |
| 18:04.33 | kpfleming | it's acceptable if i have no other choice |
| 18:04.46 | tzanger | heh |
| 18:08.21 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:08.21 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:29.46 | JunK-Y | lo guys |
| 18:34.33 | *** join/#asterisk-dev JerJer (n=PhatJ@asterisk/original-h323-guy/JerJer) |
| 18:34.36 | JerJer | <PROTECTED> |
| 18:35.29 | kpfleming | is this on 64-bit? |
| 18:35.37 | JerJer | yes |
| 18:35.43 | kpfleming | is the library static or dynamic or both? |
| 18:35.52 | JerJer | segfaults |
| 18:35.56 | kpfleming | sorry |
| 18:36.02 | kpfleming | where is the library installed? |
| 18:36.27 | JerJer | i think without --enable-pic it was just a static lib |
| 18:36.32 | kpfleming | correct |
| 18:36.40 | kpfleming | dynamic libs on 64-bit have to be built with PIC |
| 18:36.52 | kpfleming | static libs *can* be, but distros generally don't |
| 18:37.05 | JerJer | adding it to the srtp configure process seems to help - thus far |
| 18:37.18 | JerJer | compiled cleanly - perhaps an app note is in order? :) |
| 18:37.24 | kpfleming | yeah, that could be good |
| 18:37.33 | ctooley | Corydon76-dig, We both know how "meaningless" load average is on a call server for actual limitations, but when a server that's actually handling SIP and RTP hits a load average of around 400 with 4 cores (with Asterisk doing all the load generation and not something arbitrarily pushing the number), the likelihood of good call quality goes down dramatically. |
| 18:38.09 | JerJer | (and sample added to sip.conf.sample) |
| 18:38.22 | tzanger | why on earth do 64-bit dynamic libs have to be PIC? I thought they could just be mapped in with the VM to where they "need" to be |
| 18:38.48 | JerJer | doesn't remember what PIC even is - besides a fun little microcontroller :P |
| 18:39.30 | kpfleming | tzanger: because the default memory model on x86_64 is not full 64-bit addressing in all modes, as i understand it |
| 18:39.42 | tzanger | hmm, interesting |
| 18:39.48 | kpfleming | i saw something on gcc-help that explained it, but i doubt i could find it |
| 18:40.54 | tzafrir_laptop | well, dynamic libs need to be PIC anyway, regardless of platform, right? |
| 18:41.07 | tzafrir_laptop | you can never well where the loader will load your code |
| 18:41.30 | kpfleming | right |
| 18:41.55 | kpfleming | but for some platforms, the default mode is already position independent (like x86-32) |
| 18:43.31 | ctooley | JerJer, position-independent code (PIC) |
| 18:43.59 | JerJer | danke |
| 18:44.47 | tzafrir_laptop | JerJer, you could have asked infobot... |
| 18:45.35 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:46.48 | eliel | pings kpfleming to remind him about review request #79 :-) |
| 18:47.00 | kpfleming | yeah... i know |
| 18:47.05 | kpfleming | my list of tasks is long |
| 18:48.54 | file | an army of kpflemings would be very useful... but very dangerous |
| 18:49.29 | russellb | they would fight |
| 18:49.42 | russellb | to the death! |
| 18:49.46 | russellb | and that would be badness |
| 18:51.18 | eliel | kpfleming: yes, I know... a reminder doesn't hurts :-) |
| 18:51.30 | kpfleming | it can, if it annoys me :-) |
| 18:51.40 | eliel | kpfleming: does it? |
| 18:51.59 | kpfleming | avoids commenting at this time as he's involved in another project |
| 18:53.14 | eliel | understood |
| 18:58.51 | Juggie | dr. pepper would be happy |
| 18:59.02 | Juggie | sales would increase exponentially w/ the number of kpflemmings |
| 19:00.06 | eliel | thinks that will multiple kpflemings we will have in C: const const const char const const * const const; |
| 19:00.30 | eliel | s/that will/that with/ |
| 19:19.02 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 19:32.06 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 19:49.50 | JerJer | oh no there is no 'stop now' :) |
| 19:50.18 | JerJer | about to attempt first TLS+SRTP call now |
| 19:50.45 | kpfleming | there have been a lot of TLS fixes made in trunk that aren't in that branch, unfortunately |
| 19:50.49 | kpfleming | but it still may work anyway |
| 19:51.18 | JerJer | zoiper seems to only allow srtp with tls (the 'right' way) |
| 19:52.29 | JunK-Y | JerJer: CLI alias :) |
| 19:53.03 | JerJer | that would be cool for us old timers |
| 19:54.44 | russellb | see res_clialiases.c / configs/cli_aliases.conf.sample |
| 19:54.44 | russellb | heh |
| 19:54.51 | russellb | (in trunk, anyway) |
| 19:54.56 | JerJer | fun |
| 19:54.57 | russellb | and 1.6.2, i think |
| 19:55.11 | putnopvut | boycotts "core stop now" |
| 19:55.18 | putnopvut | which is easy to do with cli aliases. |
| 19:55.38 | JunK-Y | its already there in the .sample iirc |
| 19:55.47 | JerJer | i am so far behind 1.6 |
| 19:55.57 | JerJer | most of the crap i deal with is 1.4 or worse |
| 19:56.14 | JerJer | I still have holdouts on 1.2 :( |
| 19:56.18 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 19:59.47 | JerJer | how does one turn up some debug for TLS? |
| 19:59.57 | JerJer | [May 21 20:04:59] WARNING[25285]: tcptls.c:213 handle_tls_connection: FILE * open failed! |
| 20:02.25 | kpfleming | that's one area that is still lacking... there is not adequate debugging in that code |
| 20:06.29 | leifmadsen | ya, the sample file for CLI aliases should have a '1.4' template so you can use 1.4 commands |
| 20:08.34 | Juggie | if you use WaitExten() and it times out does it go to the t extension |
| 20:08.54 | Juggie | i'd just test it but i'm modding a prod system here on the fly :) |
| 20:10.39 | jsmith | Juggie: If you use WaitExten, and it times out, and there are no further priorities, I think you'll get auto-fallthrough |
| 20:13.24 | Juggie | it wont use t? |
| 20:13.43 | Juggie | so w/ the default autofallthrough=no how do you get to t now? |
| 20:13.56 | Corydon76-dig | You don't |
| 20:14.09 | kpfleming | huh |
| 20:14.18 | Corydon76-dig | Well, there's one way |
| 20:14.21 | kpfleming | autofallthrough should not affect going to the t extension |
| 20:14.43 | kpfleming | if it does, that seems totally wrong |
| 20:14.58 | Juggie | it does so far as i know because asterisk wont wait when it runs out of priorites to execute |
| 20:15.00 | Juggie | it just falls through |
| 20:15.09 | kpfleming | it never did wait |
| 20:15.17 | kpfleming | well, i guess it did |
| 20:15.20 | kpfleming | hmm, that's complicated |
| 20:15.27 | Juggie | of course it did. |
| 20:15.29 | kpfleming | but if you disable autofallthrough, then it should go back to that behavior |
| 20:15.56 | Juggie | right, i just thought waitexten might fix it on a context level instead of having to change the global setting. |
| 20:16.50 | Juggie | it would if it used t |
| 20:17.05 | Juggie | and it frankly seems a little odd that it doesnt |
| 20:17.11 | Corydon76-dig | Juggie: no, you're right, WaitExten goes to "t" if it times out |
| 20:17.18 | Juggie | ok. |
| 20:17.20 | Juggie | perfect. |
| 20:17.23 | Juggie | that will work then |
| 20:17.25 | Corydon76-dig | There's an explicit rule in WaitExten to do that |
| 20:17.56 | Corydon76-dig | It's just no longer handled in the main loop |
| 20:18.18 | Juggie | its not an option though right? as i dont see any options in WaitExten 1.4 except moh |
| 20:18.41 | JerJer | hmm - Problem setting up ssl connection: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca |
| 20:19.01 | Corydon76-dig | before autofallthrough, it was handled in the main loop, now it isn't. |
| 20:19.06 | Juggie | k |
| 20:20.59 | kpfleming | JerJer: so it doesn't trust your certificate |
| 20:21.17 | JerJer | but i have tls ca file in there |
| 20:21.20 | JerJer | (and created a ca) |
| 20:21.23 | kpfleming | The_Boy_Wonder: ^^^ you may be able to point JerJer to your updated TLS setup docs for Asterisk |
| 20:21.48 | JerJer | i see a proxy-ssl.conf file appeared in my /etc/asterisk |
| 20:22.55 | Juggie | Corydon76-dig, thanks for checking. |
| 20:24.36 | Corydon76-dig | Juggie: I'm here for your pleasure |
| 20:26.11 | Juggie | is not sure how to take that. |
| 20:26.32 | Corydon76-dig | lol |
| 20:27.15 | JerJer | maybe my pem creation is wrong - i just cat the key and crt files together |
| 20:28.10 | kpfleming | well, i don't think you can do tht |
| 20:28.18 | kpfleming | a combined file has to be a PKCS#12 file |
| 20:28.21 | kpfleming | or separate pems |
| 20:28.22 | The_Boy_Wonder | JerJer: what are you setting ssl up to do? does asterisk warn that the key failed to load? |
| 20:28.26 | The_Boy_Wonder | umm |
| 20:28.29 | kpfleming | in trunk, the key and cert can be separate fils |
| 20:28.51 | The_Boy_Wonder | kpfleming: i've seen a combined .pem file before |
| 20:28.59 | kpfleming | The_Boy_Wonder: he's tring out terry's SRTP branch, which has a much older version of chan_sip's TLS support |
| 20:29.11 | kpfleming | huh.. didn't know that. thanks for the info. |
| 20:30.06 | JerJer | copying the key and the cert into a single 'worked' for avaya shit not too long ago when they asked for a PEM file |
| 20:30.08 | The_Boy_Wonder | kpfleming: before my changes i believe that was the only file format that was possible, and since the same file was used for the public and private key they had to be combined for tls/ssl to work |
| 20:30.09 | JerJer | :) |
| 20:30.48 | kpfleming | ouch |
| 20:30.56 | eliel | is svn/dahdi/linux/trunk the main development branch? |
| 20:31.01 | kpfleming | yes |
| 20:31.09 | eliel | thanks |
| 20:33.04 | JerJer | The_Boy_Wonder: so cat ca.key ca.crt > ca.pem ? |
| 20:33.13 | JerJer | that is what i did |
| 20:33.37 | kpfleming | you should not need a CA key |
| 20:33.41 | kpfleming | just a CA cert |
| 20:33.49 | kpfleming | the only key required should be for the server's cert |
| 20:33.50 | JerJer | ok - will remove key |
| 20:34.10 | kpfleming | and it will have to be the private key, with no passphrase required |
| 20:34.44 | JerJer | yes - server key with no passphrase |
| 20:35.33 | JerJer | same same - after remove CA key |
| 20:36.22 | JerJer | hmm - does my UA need to know about my CA? |
| 20:36.27 | kpfleming | probably |
| 20:39.08 | JerJer | i have given zoiper its pem file with a key and crt signed by my CA |
| 20:39.39 | JerJer | and everything looks 'normal' in the zoiper debug log (until the tls connection doesn't come up :) |
| 20:39.42 | kpfleming | it will also need the CA cert, or it won't trust your server's cert |
| 20:39.58 | kpfleming | but it will have to be told that is the CA cert, it can't just be appended |
| 20:40.31 | eliel | [offtopic] someone read "fundamentals of queueing theory" ? or recommends a book about that subject? |
| 20:41.31 | JerJer | seems like tlsdontverifyserver=yes should relax things a bit, but it doesn't |
| 20:45.31 | russellb | that only affects when Asterisk is the TLS client |
| 20:45.42 | russellb | telling it not to do any verification on the server certificate from the other side |
| 20:45.46 | JerJer | oh |
| 20:46.54 | JerJer | hmm - tlsverifyclient ? |
| 20:47.25 | JerJer | no change |
| 20:48.23 | JerJer | oooooooooooooooooooh *light bulb* |
| 20:51.57 | JerJer | i have to add in the CA certificate in the PEM file that i feed to the UA |
| 20:52.24 | JerJer | so client key, client cert, ca crt > pem_file |
| 20:52.49 | JerJer | now i got a CN mismatch - which i can fix with a little dns magic |
| 20:53.14 | leifmadsen | JerJer: any chance of documenting some notes when you figure it all out? Just open an issue and assign it to me, and I'll take it from there and try to write up a real document |
| 20:53.15 | JerJer | heh - at least i have something 'good' to blog about now |
| 20:53.59 | JerJer | leifmadsen: totally (gmta) |
| 20:54.50 | leifmadsen | gmta? |
| 20:59.10 | JerJer | great minds think alike |
| 20:59.25 | JerJer | schaweeeet ---> Via: SIP/2.0/TLS |
| 20:59.48 | JerJer | SIP read from TLS: |
| 21:07.23 | JerJer | well i see the a=crypto line in the sdp's - other than sniffing the wire, is there way to know its using SRTP ? |
| 21:09.22 | russellb | put your ear to the wire? |
| 21:09.31 | russellb | I don't know if smelling the wire will tell you much |
| 21:09.36 | seanbright | i haven't sniffed wire since high school |
| 21:09.56 | seanbright | good thing maryland doesn't have a three strikes law |
| 21:12.38 | JerJer | i picked the wrong week to stop sniffing glue |
| 21:29.09 | seanbright | so are we going to see a tangible performance boost from all this const-ness? |
| 21:29.22 | seanbright | or is it more for protecting the apis? |
| 21:29.37 | kpfleming | well, performance is rarely tangible :-) |
| 21:29.51 | kpfleming | but no, i doubt you'll see much of a difference, it's just for API protection |
| 21:30.12 | seanbright | excellent. |
| 21:35.35 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 21:35.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 22:01.57 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 22:03.12 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) |
| 22:19.10 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:19.10 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |