| 00:07.10 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) |
| 01:41.10 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) |
| 01:41.10 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:02.10 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 02:11.02 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 03:21.24 | *** join/#asterisk-dev jmspeex (n=jmspeex@modemcable112.109-81-70.mc.videotron.ca) |
| 03:34.43 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 03:34.43 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 04:04.19 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 04:59.22 | *** join/#asterisk-dev errotan (n=errotan@5403E419.catv.pool.telekom.hu) |
| 05:04.39 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 06:22.45 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 06:49.52 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:49.52 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:03.43 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) |
| 07:18.46 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:36.19 | wdoekes | morning. in apps/app_voicemail.c, strip_control strips characters below 32. on most (but not all, I believe) systems the char is signed, so it strips not only the control characters, but also all >127. is this intentional? |
| 07:37.12 | wdoekes | it only affects the X-Asterisk-CallerIDName email header, so it's not a big deal. but I was just wondering. |
| 07:42.01 | wdoekes | (and while we're on the subject of low/no-priority things: in main/acl.c, the port 5060 is not network-ordered. this is no problem at all, as the port isn't actually used there. but it did confuse me a while when looking at strace output that asterisk was operating on port 50195) |
| 07:51.08 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) |
| 07:57.49 | *** join/#asterisk-dev Chris-NB (n=chris@85-126-61-10.work.xdsl-line.inode.at) |
| 08:23.26 | *** join/#asterisk-dev _ys (n=ys@91.151.196.67) |
| 09:06.46 | *** join/#asterisk-dev degrade (n=degrade@unaffiliated/degrade) |
| 09:54.49 | *** join/#asterisk-dev eferro (n=eferro@godzilla.alea-soluciones.com) |
| 10:59.55 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:00.04 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 11:45.32 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 11:45.32 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:49.33 | *** join/#asterisk-dev truz (n=truz@78.97.44.14) |
| 12:03.53 | *** join/#asterisk-dev Jacke (i=jacke@valhalla.bofh.org) |
| 12:04.33 | *** join/#asterisk-dev ctooley (n=ctooley@c-68-52-165-168.hsd1.tn.comcast.net) |
| 12:04.33 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 12:17.28 | jsmith | wdoekes: Please report both of those issues at issues.asterisk.org |
| 12:17.35 | jsmith | wdoekes: That way, the developers can keep track of them |
| 12:17.46 | jsmith | wdoekes: (and yes, you can mark them as low priority there) |
| 12:24.54 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:24.54 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:45.27 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 13:20.49 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.23.222.41) |
| 13:22.05 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 13:22.11 | *** join/#asterisk-dev BlargMaN00 (n=blarg@12.234.16.130) |
| 13:29.24 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 13:29.24 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 13:32.16 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:35.03 | *** join/#asterisk-dev caio1982_ (i=caio1982@CAcert-br/caio1982) |
| 13:35.28 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 13:36.35 | *** join/#asterisk-dev eliel_ (n=eliels@200.61.172.61) |
| 13:49.25 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:49.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:53.06 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:53.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:13.07 | rue_mohr | wdoekes, lsof | grep IPv4 |
| 14:25.25 | *** join/#asterisk-dev Corydon76-dig (i=indigo@pdpc/supporter/bronze/Corydon76-home) |
| 14:25.25 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 14:29.35 | *** join/#asterisk-dev aethelrick (n=richard@217.113.164.66) |
| 14:30.24 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:30.24 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:30.44 | mvanbaak | hey Kevin |
| 14:31.09 | mvanbaak | Were the os images I created usefull ? |
| 14:40.17 | *** join/#asterisk-dev jthurman42 (n=jthurman@66.154.131.25) |
| 14:42.29 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 14:52.32 | *** join/#asterisk-dev moy (n=moy@bas1-unionville55-1177733615.dsl.bell.ca) |
| 14:53.55 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:53.56 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:57.04 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 14:58.04 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:58.04 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:02.27 | kpfleming | mvanbaak: still haven't had time to try them... this weekend probably :-) |
| 15:08.29 | mvanbaak | :) I know that problem |
| 15:24.33 | kaii | if i have a channel "chan" which is in state ringing, how do i get the channel on the peer side which initiated ringing? |
| 15:24.36 | kaii | ast_bridged_channel() doesnt seem to be the right thing, as the channels arent bridged yet. (its all about SIP) |
| 15:32.02 | Corydon76-dig | kaii: it's not possible normally, but with a bit of forethought, you can make it possible |
| 15:32.13 | kaii | how? |
| 15:32.31 | kaii | i need this information to update the callerid on pickup. |
| 15:32.38 | Corydon76-dig | Before the dial, do a Set(__master_channel=${CHANNEL}) |
| 15:32.48 | kaii | without touching dialplan |
| 15:32.54 | kpfleming | not possible |
| 15:33.01 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 15:33.07 | Corydon76-dig | the variables are inherited at creation of the slave channels |
| 15:33.10 | kpfleming | the information is not stored anywhere except in app_dial in its local state |
| 15:33.55 | *** join/#asterisk-dev marv[work] (n=timr@24.214.206.254) |
| 15:34.11 | Corydon76-dig | kaii: you can do the same in code, as long as you can execute it prior to the Dial |
| 15:34.24 | Corydon76-dig | but that's what I mean by forethought |
| 15:37.11 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:37.47 | kaii | Corydon76-dig: this is ugly. cant believe the "requester" information is stored nowhere |
| 15:40.22 | Corydon76-dig | kaii: keep in mind at that point that it's not a strict 1:1 relationship |
| 15:40.49 | kpfleming | and that channels don't necessarily have another channel as a requester at all |
| 15:41.01 | kpfleming | AMI can create them, spool files can create them, apps can create them, etc. |
| 15:41.09 | kaii | in the last case, requester could be NULL |
| 15:41.52 | Corydon76-dig | Could be added at some point... we certainly have enough requests for the facility |
| 15:42.13 | kaii | and a 1:n relationship (which it is) does no harm to the thing (do not understand the argument) |
| 15:42.38 | *** join/#asterisk-dev sumasuma (n=root@64.92.218.196) |
| 15:43.29 | Corydon76-dig | kaii: it's another item to manage |
| 15:44.26 | Corydon76-dig | for instance, what happens if the master is masqueraded into? Then what was the master is no longer the master |
| 15:44.59 | kaii | a very helpful one, given the fact that call transfers and/or pickups are kinda "magical" in asterisk |
| 15:45.31 | kaii | Corydon76-dig: but i can understand your point too, it adds complexity |
| 15:46.25 | kpfleming | and communication of 'connected party' information is now present in asterisk trunk... it's just been implemented using message passing, not in the method you are trying to use |
| 15:47.42 | kaii | tahts cool. but how is "connected party" defined? bridged party? requesting parti(es)? |
| 15:47.58 | kpfleming | bridged == connected |
| 15:48.15 | kpfleming | when an outbound call is made, that channel already knows the callerid of the requesting channel |
| 15:50.15 | kaii | i have the following: SIP/A-1 calls SIP/B. SIP/B-2 is a new, ringing channel. SIP/C-3 picks. SIP/A-1 gets bridged to SIP/C-3. SIP/C-3 has no information about who SIP/A is. |
| 15:50.36 | kaii | * SIP/B-2 dies. |
| 15:50.51 | kpfleming | in asterisk trunk they will get the connected party information once the pickup is complete |
| 15:51.04 | kpfleming | SIP/C's display will be updated to show SIP/A's information |
| 15:51.12 | kaii | in asterisk 1.2 its the same, i think. (bridged partys) |
| 15:51.18 | kpfleming | no, it's not |
| 15:51.28 | kpfleming | no version of asterisk prior to current trunk updates connected party information dynamically |
| 15:51.36 | kaii | its not? how is it in 1.2? this could be my problem |
| 15:51.40 | kpfleming | well, it might be in 1.6.2 |
| 15:52.21 | kaii | so what will ast_bridged_channel(SIP/C-3) return, given it is connected to SIP/A-1 ? |
| 15:52.35 | kpfleming | SIP/A's channel pointer |
| 15:52.50 | kpfleming | but nothing in asterisk 1.2 will ever check that and send an UPDATE or INVITE to SIP/C to update the display |
| 15:53.16 | kaii | thats the code i write right now |
| 15:53.39 | kaii | it works with bogus data, ABC but i cant get the original caller information |
| 15:53.43 | kpfleming | good luck |
| 15:53.46 | kpfleming | 1.2 is ancient |
| 15:53.50 | russellb | heh |
| 15:53.52 | kpfleming | and the functionality you want has already been built |
| 15:54.10 | kaii | in my case, after ast_answer(chan) a ast_bridged_channel(chan) returns NULL |
| 15:54.19 | kaii | but i can talk. :-) |
| 15:55.00 | kaii | kpfleming: i know, but we depend on this patched 1.2 stuff right now. cant choose |
| 15:56.12 | kaii | but according to what kpfleming said, ast_bridged_channel(chan) should return the pointer for the originating caller .. whats wrong here? |
| 15:57.00 | kpfleming | not in a dialplan app that hasn't returned to app_dial yet |
| 15:57.13 | kpfleming | you have answered the channel, but you haven't allowed app_dial control of your channel to setup the bridge |
| 15:57.55 | kaii | mhh ... so the pointer is updated when app_pickup has finished executing? |
| 15:58.08 | kpfleming | yes |
| 15:58.14 | kpfleming | well.. sort of |
| 15:58.22 | kaii | this explains alot |
| 15:58.32 | kaii | thx for sharing |
| 15:58.36 | kpfleming | after the masquerade occurs, and your channel replaces the channel that called app_dial originally |
| 15:58.49 | kpfleming | you are welcome |
| 15:59.08 | kaii | but now im back with my initial problem... |
| 15:59.58 | kaii | inside app_pickup .. how can i retrieve the callerid of SIP/A who call SIP/B and send that information to SIP/C ? |
| 16:00.13 | kaii | sending information to SIP/C works fine, the caller is "ABC" now .. |
| 16:00.55 | kpfleming | we have alrready told you... you can't |
| 16:01.02 | kpfleming | the information is not available in asterisk 1.2 |
| 16:01.08 | kaii | cant/wont believe it. |
| 16:01.16 | kpfleming | then this is a pointless conversation |
| 16:01.19 | kaii | on transfer some magic does the same |
| 16:01.20 | kpfleming | facts are facts |
| 16:01.35 | kaii | well then, i have to give up. |
| 16:01.35 | kpfleming | does what? |
| 16:01.55 | kaii | kpfleming: junghanns implemented calleridupdate via SIP INFO on transfer in asterisk 1.2 |
| 16:02.02 | kpfleming | then you have to use his code |
| 16:02.06 | kpfleming | we don't know what it does |
| 16:02.09 | kaii | now i try the same on pickup |
| 16:02.21 | kpfleming | but presumably it triggers after/during the masquerade process itself |
| 16:02.32 | kaii | kpfleming: it uses ast_bridged_channel() which in my case cant work according to what you said. |
| 16:02.34 | kpfleming | so ask him how he did it, or learn his code |
| 16:02.42 | kpfleming | no, that is not what i said |
| 16:02.50 | kpfleming | it depends on *where* and *when* you call it |
| 16:03.00 | kpfleming | transfer is not a dialplan application |
| 16:03.06 | kpfleming | it works entirely differently than pickup |
| 16:03.12 | kaii | indeed |
| 16:03.20 | kpfleming | you have to figure out how to call ast_bridged_channel() AFTER the channel has been bridged, not before |
| 16:03.29 | kpfleming | the information is not available before that |
| 16:03.48 | kaii | can i trigger the bridge somehow without giving control back to the dialplan ? |
| 16:03.58 | kpfleming | nope |
| 16:04.24 | kaii | awesome. could imagine it would be so hard/impossible. |
| 16:04.28 | kaii | *couldnt |
| 16:05.14 | kpfleming | well, considering that asterisk has moved on 4+ years since that code was written, you can understand that not everything you want to do today was accomodated back then |
| 16:06.02 | kaii | but how does asterisk itself know which channels should get bridged when SIP/B answers a call frm SIP/A, when the information who called whom is not available anywhere? |
| 16:06.13 | kpfleming | app_dial does |
| 16:06.18 | kaii | kpfleming: of course i understand |
| 16:06.23 | kpfleming | it is the application that placed the call to SIP/B |
| 16:06.38 | kpfleming | but it does not store that information anywhere outside of its own data structures |
| 16:07.36 | kaii | so this is the point where is could start -> make app_dial (and app_queue) store the "requesting channel" information inside an ast_chan property |
| 16:07.39 | kaii | would you agree on that? |
| 16:07.57 | kpfleming | yes |
| 16:08.05 | kpfleming | for your application, yes |
| 16:08.25 | kpfleming | but as tilghman already pointed out, that gets complicated to manage properly |
| 16:08.26 | kaii | thx alot, you saved me lots of try'n'error. (to find out why ast_bridg3ed_channel() returns NULL) |
| 16:09.51 | kaii | i will definitely keep the masquerading issue in mind, but i think in my application the missing updates are not a problem |
| 16:12.57 | *** join/#asterisk-dev xpot-mobile (n=james@static-66-182-88-85.bbsc.net) |
| 16:15.24 | wdoekes | rue_mohr: and then what? |
| 16:26.52 | kaii | kpfleming: how long would you estimate will 1.6 be beta, when do you think *could* it reach production stability ? |
| 16:27.11 | kpfleming | 1.6 what? |
| 16:27.20 | kpfleming | there are lots of 1.6 branches and releases |
| 16:28.20 | kaii | umm.. on asterisk.org i can download 1.6.2.0-beta3 .. dunno what branch / release digium will release as "aserisk" |
| 16:28.37 | kaii | i miss alot of keys today .. need more sleep next night :) |
| 16:28.58 | Qwell | We'd never release a branch as "aserisk". :) kaii, one sec, I'll get you a link that Leif Madsen made |
| 16:29.21 | kaii | Qwell: know what i mean :P |
| 16:29.22 | Qwell | http://www.asterisk.org/node/48602 This explains the versioning very well |
| 16:29.32 | kaii | thx m8 |
| 16:29.39 | Qwell | (he really did a great job on that IMO...) |
| 16:30.32 | kaii | ah you switched to linux kernel like versioning .. |
| 16:30.56 | Qwell | more or less |
| 16:31.30 | kaii | then the question is: how long would you estimate, will 1.6.2 stay beta until it is considered "stable for production use"? |
| 16:32.02 | *** join/#asterisk-dev ccesario_ (n=ccesario@189.88.2.216) |
| 16:32.19 | kaii | just asking to find out if it would make sense to wait for 1.6.2 stable to migrate our patchset to a version near trunk |
| 16:32.39 | kpfleming | 1.6.2 will come out of beta soon... it's waiting on some t.38 fixes that i am working on right now, then it needs to go through release candidates |
| 16:32.44 | kpfleming | maybe 4-6 weeks if things go well |
| 16:32.56 | kaii | i see. |
| 16:32.59 | kpfleming | whether that is 'stable' is up to you. we never say anything is 'stable', because we don't know what people do with it. |
| 16:33.06 | kaii | then struggling with 1.4 makes no sense |
| 16:33.26 | kaii | kpfleming: yes ive seen 1.4 is still RC |
| 16:34.32 | Corydon76-dig | 1.4 isn't RC, only 1.4.26 is RC |
| 16:35.06 | kaii | right. |
| 16:35.27 | kaii | but according to leif madsen, there is only the 1.4 branch |
| 16:35.45 | kaii | which has an RC5 for subversion 26 :) |
| 16:36.00 | Corydon76-dig | You misunderstand 1.4, then |
| 16:36.34 | Corydon76-dig | 1.4 has had multiple releases, of which the 27th release is still in candidate status |
| 16:37.04 | Corydon76-dig | 27th, since we count from 0. |
| 16:37.23 | kaii | i see.. is not obvious in the versioning document posted above |
| 16:38.15 | Corydon76-dig | The versioning document posted above is for 1.6 only |
| 16:38.44 | Corydon76-dig | hence the title "about the NEW asterisk versioning method" |
| 16:45.44 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 16:47.59 | freddyk | is there any way to exchange hints between two asterisk servers ? |
| 16:48.11 | kpfleming | in 1.6.2, yes, using res_ais |
| 16:48.37 | freddyk | is there any backport for asterisk 1.4 ? |
| 16:48.48 | kpfleming | no |
| 16:48.55 | kpfleming | it uses the event subsystem, it would be a massive backport |
| 16:49.32 | freddyk | ok |
| 16:49.38 | freddyk | i've got another question |
| 16:49.54 | freddyk | i'm trying to implement conference features into a channel driver |
| 16:50.02 | freddyk | where i have already a bridged call |
| 16:50.12 | freddyk | is there any way to break that bridge |
| 16:50.16 | freddyk | ? |
| 16:50.27 | kpfleming | that depends on what you want to happe after the bridge is broken |
| 16:50.42 | freddyk | i have a two way call |
| 16:50.49 | freddyk | so i have 1 bridge and two channels |
| 16:50.55 | freddyk | bridged together |
| 16:51.06 | freddyk | i have to bridge both channels to two new channels |
| 16:51.15 | kpfleming | from within a channel driver? |
| 16:51.20 | freddyk | yes |
| 16:51.21 | kpfleming | i don't see how that could happen |
| 16:51.51 | freddyk | i'm doing that into skinny channel driver |
| 16:51.57 | freddyk | as i'm enabling conference feature |
| 16:52.04 | freddyk | and i need to unbridge channels |
| 16:52.14 | freddyk | to have both endpoints bridged to a dahdi conference |
| 16:52.19 | Qwell | conferencing doesn't belong in the channel driver |
| 16:52.33 | kpfleming | he's not putting it in the channel driver, that was poorly worded |
| 16:53.08 | freddyk | nope i'm not |
| 16:53.09 | kpfleming | really, you just want to do an async_goto on each of the channels involved to send them to a dialplan extensions that will put them into a conference |
| 16:53.17 | Qwell | ahh, I misunderstood.. I've actually had that conversation before though with chan_skinny |
| 16:53.35 | freddyk | what i really mean is |
| 16:53.46 | freddyk | that phone should have control over conference |
| 16:53.53 | freddyk | as skinny phones |
| 16:53.59 | freddyk | should display and control partecipants |
| 16:54.32 | freddyk | so i suppose that conferencing should be part of the channel driver |
| 16:54.40 | freddyk | at least conferencing control |
| 16:54.43 | freddyk | even if |
| 16:54.50 | freddyk | rtp is handled by an outside res |
| 16:56.27 | Qwell | freddyk: is this for the Conference softkey stuff? |
| 16:56.41 | freddyk | yep |
| 16:57.09 | Qwell | you might want to talk to mvanbaak and umm...somebody...about it. |
| 16:57.10 | Qwell | wedhorn |
| 16:57.24 | Qwell | They may have had thoughts about how to handle it as well |
| 16:57.47 | freddyk | i asked mvanbaak some times ago |
| 16:57.49 | freddyk | and he told me |
| 16:57.55 | freddyk | conferencing is part of asterisk |
| 16:58.03 | freddyk | as many other functions like pickup |
| 16:58.07 | freddyk | and so on |
| 17:00.36 | Qwell | full conference control type stuff (like kicking/muting a user) doesn't seem like it belongs inside the channel |
| 17:00.53 | kpfleming | honestly, the way i'd go about this is to have those 'special' keys just send AMI events that an external app can react to to manipulate the channels involved |
| 17:01.25 | *** part/#asterisk-dev jamesh1 (n=jhenders@xob.neospire.net) |
| 17:01.28 | russellb | or we could come up with an application specific control frame mechanism ... |
| 17:01.43 | kpfleming | but this is not an asterisk application at all |
| 17:01.50 | kpfleming | it's a visual conference manager |
| 17:01.53 | Qwell | XML app could do that fairly easily |
| 17:01.58 | russellb | sorry, i haven't read most of this, heh |
| 17:02.10 | freddyk | it's just few limes |
| 17:02.13 | freddyk | lines* |
| 17:02.25 | russellb | wanders off for food ... |
| 17:02.58 | Qwell | I still love just how dumb the skinny protocol is. |
| 17:03.35 | freddyk | skinny it's a protocol |
| 17:03.40 | freddyk | and has an application |
| 17:05.02 | Qwell | (I actually meant that.. there was no sarcasm or irony there. I like the protocol.) |
| 17:06.38 | *** join/#asterisk-dev jamesh1 (n=jhenders@xob.neospire.net) |
| 17:46.59 | eliel_ | hello |
| 17:47.39 | eliel_ | it is possible to do in a gcc macro ( if (typeof(_var) == int) { ... } ) |
| 18:06.57 | *** part/#asterisk-dev eferro (n=eferro@godzilla.alea-soluciones.com) |
| 18:07.06 | kpfleming | eliel_: was that a question? |
| 18:07.31 | eliel_ | s/ )/ )?/ |
| 18:07.35 | eliel_ | :) |
| 18:07.43 | kpfleming | what are you trying to accomplish? |
| 18:08.19 | russellb | not using typeof(), but i swear i think i read of a way to do that using a different gnu extension ... |
| 18:08.30 | kpfleming | i don't understand the question |
| 18:08.31 | eliel_ | i have a number of functions cmp_sint cmp_uint cmp_string, cmp_.... i want to do a "wrapper" called just cmp() |
| 18:08.46 | kpfleming | oh |
| 18:08.47 | eliel_ | based on the type of one argument |
| 18:09.06 | kpfleming | __builtin_types_compatible |
| 18:09.14 | kpfleming | we use that in one of the asterisk headers already |
| 18:09.23 | kpfleming | however... it's not very reliable for things like char * vs. char[] |
| 18:10.01 | russellb | ah, that was it |
| 18:10.46 | eliel_ | thanks! |
| 18:16.09 | eliel_ | kpfleming: no headers with builtin_types_compatible |
| 18:16.39 | kpfleming | oh... then i never committed it. sorry. |
| 18:17.29 | eliel_ | ok, no problem! |
| 18:27.45 | *** join/#asterisk-dev zeroHalo (n=zeroHalo@75.150.77.161) |
| 18:42.08 | *** join/#asterisk-dev bbryant1 (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 18:42.08 | *** mode/#asterisk-dev [+o bbryant1] by ChanServ |
| 18:52.09 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 18:52.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:11.38 | Juggie | OT: best open source network monitoring tool? |
| 19:12.11 | Corydon76-dig | Nagios |
| 19:13.09 | Juggie | does it graph? |
| 19:16.18 | kpfleming | not directly |
| 19:16.26 | kpfleming | but stuff it outputs can be sent to MRTG or other graphing tools |
| 19:17.09 | russellb | http://tinyurl.com/d5dwk6 |
| 19:17.12 | *** join/#asterisk-dev errotan (n=errotan@5403E5C2.catv.pool.telekom.hu) |
| 19:17.13 | russellb | aww, you actually answered |
| 19:17.17 | russellb | i wanted to respond with a smart ass link |
| 19:17.39 | Juggie | hahahah russellb! |
| 19:17.53 | russellb | :-) |
| 19:20.03 | jsmith | Corydon76-dig: I wouldn't call Nagios the *best* |
| 19:20.34 | jsmith | Corydon76-dig: Having used it to monitor over 6000 servers and another 1500 network devices, I don't think it's that hot |
| 19:21.11 | jsmith | Some of the design decisions where absolutely new level of mind-numbing *stupid* |
| 19:21.33 | jsmith | "Gee... let's re-parse all the config files every time someone hits a CGI script" |
| 19:21.56 | Juggie | i've been looking @ a few like Nagios, Zenoss, Zabbix, etc. |
| 19:23.08 | eliel_ | http://www.cacti.net/ |
| 19:23.30 | Juggie | ya cacti rocks but thresholds and notifications are not really built in |
| 19:23.36 | Juggie | unless there is a new release? |
| 19:23.50 | eliel_ | don't think so |
| 19:24.54 | zeroHalo | munin's also good, uses rrd for graphing, works okay with nagios for alerts, etc |
| 19:25.34 | Juggie | i think i'll give zenoss atry |
| 19:25.56 | Juggie | mostly because i found a zenoss vmware appliance image released by zenoss inc so it should be resonable. |
| 19:52.10 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 19:52.10 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:53.45 | Corydon76-dig | jsmith: just because Nagios is the best doesn't mean it's not critically flawed. Just that the others are MUCH more flawed |
| 19:55.19 | jsmith | Friends don't let friends use Nagios :-p |
| 19:55.47 | jsmith | I wouldn't want Juggie to hate me forever after using Nagios... so I recommend trying Zabbix |
| 20:02.37 | Corydon76-dig | I, on the other hand, don't mind if Juggie hates me forever |
| 20:03.32 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 20:03.32 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 20:08.19 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 20:08.19 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 20:12.32 | *** join/#asterisk-dev lasko (n=lasko@70.102.15.210) |
| 20:12.49 | lasko | Was asterisk/rtp.h replaces with asterisk/rtp_engine.h ? |
| 20:13.05 | lasko | *replaced |
| 20:13.22 | jsmith | lasko: Yeah... in Asterisk trunk, at least |
| 20:13.29 | kpfleming | only |
| 20:13.34 | lasko | Thats what I'm working with is trunk at the moment |
| 20:13.37 | jsmith | lasko: It was changed so that you could plug in a replacement RTP engine if you so desired |
| 20:13.39 | lasko | doing testing |
| 20:14.20 | lasko | Having some issues compiling getting chan_ooh323.h:53:26: error: asterisk/rtp.h: No such file or directory |
| 20:14.38 | kpfleming | there is a branch for that, just created yesterday by may |
| 20:14.50 | kpfleming | hasn't been merged yet, so for now you just need to avoid building chan_ooh323 |
| 20:14.57 | lasko | *nod* thanks |
| 20:15.16 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 20:15.16 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 20:15.42 | seanbright | well, preferably avoid building it all the time |
| 20:15.53 | lasko | *nod* I don't need it, was just curious |
| 20:16.03 | seanbright | i was just trolling |
| 20:16.05 | seanbright | as usual. |
| 20:16.10 | lasko | lol |
| 20:26.09 | *** part/#asterisk-dev zeroHalo (n=zeroHalo@75.150.77.161) |
| 20:28.58 | *** part/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 20:29.35 | tzafrir_laptop | btw: who is may? anyone on IRC? |
| 20:31.04 | russellb | I don't think he's on IRC |
| 20:31.08 | russellb | but he's reporter of issue ........ |
| 20:31.26 | russellb | M15285 |
| 20:31.29 | MuffinMan | [assigned] [Asterisk] Addons/chan_ooh323 0015285: [patch] reworked chan_ooh323 reported by may213 (Karma: neutral) https://issues.asterisk.org/view.php?id=15285 |
| 20:31.35 | russellb | since it was such a big patch, i got him a cert to put it in a branch |
| 20:33.27 | philipp64 | howdy. I was trying to build Zaptel last night, and it failed. No "hdlc_stats()" defined in zaptel-base.c. This was 2.6.27.26. 2.6.26.8 has it, however... as does 2.6.30.1. |
| 20:34.20 | philipp64 | anyone know what's going on? did it go away and come back? I don't want to go too much further than 2.6.27.26... because then we get into uncharted waters. so I need to find the earliest version where hdlc_stats() made it's reappearance. |
| 20:34.34 | russellb | how about try DAHDI :-p |
| 20:37.20 | seanbright | wtf is zaptel? |
| 20:38.58 | seanbright | sounds like a dot com fly-by-night |
| 20:39.09 | seanbright | actually, i should totally trademark that shit... |
| 20:39.54 | putnopvut | seanbright: lol |
| 20:40.07 | philipp64 | working on it... |
| 20:40.38 | philipp64 | we're still using 1.4.25.1, and to go to 1.6 we either need patches for uClibc, or to migrate to eglibc. to do that, we need to upgrade to gcc 4.3 from 4.1.2.. |
| 20:40.49 | russellb | 1.4 supports dahdi |
| 20:41.17 | philipp64 | ok. we had some build issues last time I tried. I'll go back and look again. |
| 20:42.02 | seanbright | hmmm |
| 20:42.19 | seanbright | i thought the uClibc issues had been worked out |
| 20:50.25 | seanbright | hmmm |
| 20:50.43 | seanbright | can you make asterisk link against uClibc if it's just untarred and built in a directory? |
| 20:53.49 | kpfleming | no |
| 20:53.58 | kpfleming | the compiler has to be built to link against the C library you want to use |
| 20:54.05 | Corydon76-dig | seanbright: zaptel makes calling cards |
| 21:00.03 | seanbright | Corydon76-dig: ahhh |
| 21:00.20 | seanbright | kpfleming: drat. |
| 21:01.11 | seanbright | buildroot ftw |
| 21:01.24 | seanbright | i am now the official uClibc/asterisk maintainer |
| 21:01.27 | seanbright | so sayeth the shepard |
| 21:01.43 | russellb | orly! |
| 21:01.44 | putnopvut | Someone give that man a glass of egg nog! |
| 21:01.50 | russellb | seanbright: be careful what you ask for |
| 21:02.04 | seanbright | russellb: i ask for nothing |
| 21:02.52 | seanbright | nothing gets the ladies hotter than telling them you built a cross-compile toolchain |
| 21:02.54 | Corydon76-dig | seanbright: and ye shall receive it! |
| 21:02.55 | seanbright | i speak from experience. |
| 21:03.32 | Corydon76-dig | seanbright: only if by "ladies", you mean horny geek guys |
| 21:03.36 | russellb | oh, is that how kight bright was formed? |
| 21:03.40 | seanbright | how dare you |
| 21:04.01 | seanbright | her name shall not be uttered by the likes of you |
| 21:04.17 | russellb | asterisk-commits has been to quiet today, people! |
| 21:04.18 | seanbright | but seriously... the first time it was cute. now it's on every picture of us. people aren't creative. |
| 21:04.30 | putnopvut | Did anyone give him eggnog yet? |
| 21:04.46 | Corydon76-dig | cracks an egg on his noggin |
| 21:05.05 | russellb | offers a high five for any commit in the next 5 minutes |
| 21:05.10 | russellb | ... a commit deemed productive |
| 21:05.31 | Corydon76-dig | How about a glass of 25yo whiskey? |
| 21:06.03 | Corydon76-dig | likes scotch that is older than his bf |
| 21:06.49 | russellb | how about those commits! |
| 21:07.03 | Corydon76-dig | Waiting for a test compile |
| 21:07.07 | russellb | ooh |
| 21:07.23 | seanbright | i have my script running for r210000 |
| 21:07.30 | seanbright | small whitespace fix. |
| 21:07.32 | seanbright | it's going to be awesome |
| 21:08.04 | Corydon76-dig | Is it shaped like the starship Enterprise? |
| 21:10.44 | russellb | high fives Corydon76-dig for closing a bug |
| 21:11.05 | putnopvut | Speaking of bugs: |
| 21:11.07 | putnopvut | M15182 |
| 21:11.09 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_sip/T.38 0015182: [patch] T.38 invite does not always comply with RFC 2327 reported by CGMChris (Karma: neutral) https://issues.asterisk.org/view.php?id=15182 |
| 21:11.24 | putnopvut | That patch has been sitting there for nearly a month with no feedback. |
| 21:11.31 | seanbright | no, speaking of bugs... |
| 21:11.33 | seanbright | M15052 |
| 21:11.36 | MuffinMan | [ready for review] [Asterisk] Channels/chan_sip/Registration 0015052: [patch] registration fails if multiple peers are specified in sip.conf reported by fsantulli (Karma: neutral) https://issues.asterisk.org/view.php?id=15052 |
| 21:11.38 | Corydon76-dig | russellb: rated 480, even |
| 21:11.43 | russellb | Corydon76-dig: nice! |
| 21:11.48 | russellb | smacks seanbright |
| 21:12.05 | seanbright | freddyk sits in #asterisk-bugs all day and every couple hours types M15052 |
| 21:12.09 | seanbright | and that's it |
| 21:12.11 | seanbright | he needs some love |
| 21:12.19 | russellb | go review it, then |
| 21:12.29 | seanbright | don't talk back to me, young man. |
| 21:12.40 | *** mode/#asterisk-dev [-o seanbright] by russellb |
| 21:12.42 | seanbright | recall our conversation about how chan_sip hates my guts? |
| 21:12.42 | russellb | flexes |
| 21:12.50 | seanbright | the feel is mutual. |
| 21:12.59 | seanbright | <3 |
| 21:13.01 | seanbright | feeling* |
| 21:14.26 | Corydon76-dig | chan_sip has been copping a feel? |
| 21:14.39 | seanbright | it keeps trying to register |
| 21:14.59 | seanbright | and i'm like "dude... 400 unauthorized" |
| 21:15.06 | seanbright | (or whatever the right status is) |
| 21:16.13 | Corydon76-dig | 403 Forbidden |
| 21:16.31 | Corydon76-dig | 403 should make it stop |
| 21:16.38 | Corydon76-dig | 401 will make it keep trying |
| 21:16.55 | Corydon76-dig | 400 is Bad Request |
| 21:17.18 | putnopvut | Watch what I'm about to do... |
| 21:17.31 | putnopvut | My first commit to libss7 :) |
| 21:17.49 | Corydon76-dig | putnopvut: you're going to kick seanbright with a 401? |
| 21:18.09 | putnopvut | Corydon76-dig: I would never do that. |
| 21:18.28 | Corydon76-dig | But you might with a 403? |
| 21:19.21 | putnopvut | |\| () ! |
| 21:23.58 | seanbright | putnopvut: nice. |
| 21:24.08 | seanbright | i hope to one day graduate to ss7 |
| 21:24.44 | Corydon76-dig | hopes that one days libss7 will be perfect and won't need modification |
| 21:26.02 | Corydon76-dig | I'm hoping for the same for libpri |
| 21:26.47 | seanbright | i was under the impression that ss7 is a complex beast |
| 21:26.53 | seanbright | so we've got a ways to go |
| 21:28.09 | seanbright | i could also be talking out of my ass |
| 21:28.11 | seanbright | nothing new. |
| 21:31.45 | Corydon76-dig | seanbright: Now there's a talent to be proud of |
| 21:36.56 | *** part/#asterisk-dev jamesh1 (n=jhenders@xob.neospire.net) |
| 21:39.53 | philipp64 | seanbright: does that mean you'll be getting uClibc g729 codecs out soon? :-) |
| 21:41.13 | philipp64 | Corydon76-dig: does https://issues.asterisk.org/file_download.php?file_id=23176&type=bug count as a productive commit? who do I get to sign off on it, anyway? |
| 21:41.35 | *** join/#asterisk-dev jamesh1 (n=jhenders@xob.neospire.net) |
| 21:43.53 | Corydon76-dig | What's the bug number? |
| 21:46.15 | seanbright | philipp64: if digium wants to send me the source? sure! ;-) |
| 21:46.36 | russellb | it's not as simple as just "making a build" |
| 21:46.57 | russellb | uclibc is very much designed in such a way that it expects _everything_ to built against _your_ copy with the way you have configured it |
| 21:47.05 | russellb | we couldn't just make a build that would be generally compatible |
| 21:47.40 | seanbright | true, true. |
| 21:52.50 | philipp64 | Corydon76-dig: https://issues.asterisk.org/view.php?id=15370 |
| 21:56.28 | philipp64 | thankya... thankya vurrrry much. |
| 21:59.24 | russellb | M15370 |
| 21:59.26 | MuffinMan | [assigned] [Asterisk] Core/BuildSystem 0015370: [patch] Repeatedly building the asterisk directory repeatedly downloads the sounds files reported by pprindeville (Karma: +4.00) https://issues.asterisk.org/view.php?id=15370 |
| 22:00.33 | philipp64 | yup, accummulating those karma points... I figure I'll "ascend" and turn to pure energy when I get enough of them...) |
| 22:01.47 | putnopvut | M14652 |
| 22:01.49 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0014652: [patch] early-dial SIP 484 "incomplete address" reported by vieri (Karma: neutral) https://issues.asterisk.org/view.php?id=14652 |
| 22:02.06 | putnopvut | Could someone explain to me why a feature like the "early dial" described in that issue is useful? |
| 22:05.39 | kpfleming | in places where PSTN numbers are variable length |
| 22:07.12 | kpfleming | allows users to not have to hit 'send' to place calls from SIP phonnes |
| 22:09.22 | *** join/#asterisk-dev diggles (n=doug@nat/digium/x-0e4b01715db83758) |
| 22:12.03 | *** join/#asterisk-dev sruffell1 (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:12.03 | *** mode/#asterisk-dev [+o sruffell1] by ChanServ |
| 22:13.29 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:13.29 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:17.21 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |