| 00:08.19 | *** join/#asterisk-dev bklang (~bklang@12.130.118.254) |
| 00:19.39 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 02:29.19 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.114.36.170) |
| 02:35.04 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 02:36.36 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 02:36.36 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 02:45.48 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-38-140-211.ptld.qwest.net) |
| 03:00.46 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 03:00.46 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:43.46 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-38-140-211.ptld.qwest.net) |
| 07:03.57 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:11.11 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:11.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:15.43 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-36-110-118.ptld.qwest.net) |
| 07:27.14 | *** join/#asterisk-dev lftsy (~lftsy@pul-lav-fw-so-01-x1.vtxnet.net) |
| 07:31.17 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:33.13 | *** join/#asterisk-dev lftsy (~lftsy@pul-lav-fw-so-01-x1.vtxnet.net) |
| 07:55.55 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 08:04.35 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 08:07.38 | jamespass | Hey Corydon76-lap - you there? |
| 08:07.59 | jamespass | You answered my question last night, but I want to expand a little. |
| 08:08.32 | jamespass | what did you mean by they are exported generally, record the call and you should see?? |
| 08:08.57 | jamespass | What we need is to 'hide' the dtmf from the called party |
| 08:09.03 | jamespass | but the system needs to see it. |
| 08:09.10 | jamespass | let me give a scenario... |
| 08:09.19 | jamespass | the caller calls and talks to the called party |
| 08:09.42 | jamespass | the called party asks the user to verify his pin |
| 08:09.49 | tzafrir | jamespass, maybe he's still awake, but I suspect he'll be here in five hours or so |
| 08:09.51 | jamespass | the caller types the pin in by DTMF |
| 08:10.06 | jamespass | (Can anyone else help maybe?) |
| 08:10.43 | jamespass | but the system doesn't play the DTMF to the called party, but instead is able to store it in a variable/output to a db or some other method |
| 08:10.58 | jamespass | I'm pretty sure this isn't possible currently. |
| 08:11.09 | jamespass | Can someone confirm? |
| 08:11.36 | jamespass | I guess it's a dial() application question. |
| 08:11.50 | tzafrir | jamespass, not really |
| 08:12.08 | jamespass | not really possible? |
| 08:12.13 | tzafrir | Dial is used to establish a bridge. Which version of Asterisk is it? |
| 08:12.28 | jamespass | Actually I don't care - we can implement it on anything |
| 08:12.38 | jamespass | 1.6 pref. |
| 08:13.14 | tzafrir | 1.6.<?> |
| 08:13.29 | jamespass | 1.6.latest |
| 08:14.00 | tzafrir | (1.6.1.8.beta3 . Fine ;-) |
| 08:14.19 | jamespass | :-) |
| 08:14.34 | jamespass | so if it isn't dial that I would look to implement this then where? |
| 08:15.12 | tzafrir | Dial basically connects two channels together ("bridges" them) |
| 08:15.19 | jamespass | ok |
| 08:15.31 | jamespass | so the dtmf is in the channel driver? |
| 08:15.41 | tzafrir | I suspect so |
| 08:16.11 | jamespass | ouch - that makes it more complex because we would need to deal with it in chan_dhadi and chan_sip |
| 08:16.37 | jamespass | or actually just chan_sip because we could intercept it in on the extension side..... |
| 08:16.47 | jamespass | ..thinking out loud!... |
| 08:19.17 | tzafrir | Just a stupid thought: transfer the caller to a "authenticasion" extension temporarily? |
| 08:20.05 | jamespass | could do, but if the called party is a queue agent it would be difficult to bring the call back. |
| 08:20.23 | jamespass | 'intercepting' the DTMF is far preferable. |
| 08:21.03 | jamespass | who wrote chan_sip - maybe i need to have a dialogue with them |
| 08:22.38 | tzafrir | many people wrote chan_sip. |
| 08:22.42 | tzafrir | $ wc channels/chan_sip.c |
| 08:22.42 | tzafrir | <PROTECTED> |
| 08:23.17 | jamespass | yeah sure - there must be a maintainer |
| 08:23.26 | tzafrir | I suppose they love dialogs ;-) |
| 08:24.19 | tzafrir | another thing to think at first: |
| 08:25.01 | tzafrir | how do you mark the beginning of such one-sided capturing of DTMFs? |
| 08:25.07 | jamespass | yeah i know |
| 08:25.11 | tzafrir | Where do those DTMFs go? |
| 08:25.21 | jamespass | they can go out via the AMI |
| 08:25.45 | jamespass | we wouldn't want to mark the beginning |
| 08:25.50 | tzafrir | That means a complex state machine |
| 08:25.55 | jamespass | all dtmf should be supressed to the called party |
| 08:26.00 | jamespass | explain? |
| 08:26.28 | tzafrir | You'd have to implement a listener that keeps track of all such calls |
| 08:27.24 | jamespass | yes |
| 08:27.34 | jamespass | that's not such a nightmare though |
| 08:28.20 | tzafrir | Do caller and calle have to talk with each other at time of authentication? |
| 08:34.56 | jamespass | we just have a process that logs into the AMI, keeps a track of the cal |
| 08:35.00 | jamespass | yes they do |
| 08:46.28 | jamespass | is it possible do you think? |
| 08:48.12 | tzafrir | IIRC digit events are already logged into the manager (or can be easily made to) |
| 08:48.55 | tzafrir | But you want to avoid them from being played to the callee under some circumstances |
| 08:49.54 | *** join/#asterisk-dev lftsy (~lftsy@pul-lav-fw-so-01-x1.vtxnet.net) |
| 08:53.29 | jamespass | yes |
| 08:53.32 | jamespass | IIRC? |
| 08:54.59 | jamespass | ah - if i remember correctly!! |
| 08:55.13 | jamespass | let me test |
| 09:00.37 | jamespass | I saw this from voipinfo... |
| 09:00.38 | jamespass | When Asterisk is handling a call and needs to listen to that call, e.g. to monitor it for DTMF transfer tones, Asterisk will detect and rebuild all DTMF tones on that call |
| 09:01.01 | jamespass | surely we can supress the rebuild portion simply enough? |
| 09:10.43 | *** join/#asterisk-dev newasterx (dasdasdsad@114.199.103.188) |
| 09:16.18 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 09:17.07 | newasterx | hello |
| 09:17.57 | newasterx | why i can not sent text message using SIPCon1 as textphone/softphone while voice is very clear |
| 10:07.46 | *** join/#asterisk-dev lftsy (~lftsy@pul-lav-fw-so-01-x1.vtxnet.net) |
| 11:17.39 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 11:32.26 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 11:32.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 11:32.37 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:32.37 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:44.19 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:44.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:18.54 | *** join/#asterisk-dev lftsy (~lftsy@install.deckpoint.ch) |
| 12:34.50 | *** join/#asterisk-dev frawd (~francois@210.Red-88-24-190.staticIP.rima-tde.net) |
| 13:32.05 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 13:47.54 | sruffell | tzafrir: If the dahdi_device/span/channels are fully formed before the KOBJ_CHANGE is sent....that should remove the need for the "user_ready" attributes/wait_queues. Does that make sense to you or are you using it for something else too? |
| 13:49.13 | tzafrir | the "user_ready" attribute was intended to coordinate with other scripts. Specifically: how can you tell that all spans are ready? |
| 13:49.51 | sruffell | I was thinking that dahdi_cfg could have an option for it to wait for either a timeout, or for all spans that it's been told about to be present. |
| 13:50.25 | tzafrir | How does that work with dynamic spans? |
| 13:50.53 | sruffell | it could be an extra option....so "configure and wait"..? |
| 13:51.28 | sruffell | so all the *other* spans are configured in parallel, then the init script could configure any dynamic spans and then wait for a time for all the other spans that should be there. |
| 13:55.03 | sruffell | also...I don't think this conflicts with anything you're doing....but even leaving the door open for keeping span/channel numbers settable by dahdi_cfg I won't be able to ensure there is any relation between the minor number and the channel number. since it has to be assigned before the KOBJ_CHANGE. |
| 13:55.49 | sruffell | it didn't look like there was any set relation in your branch on that front either... |
| 13:56.14 | sruffell | ..since all the channels aren't under the DAHDI / Zaptel major number. |
| 13:56.40 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 13:56.40 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 13:58.59 | *** join/#asterisk-dev eliel (~eliels@186.18.131.44) |
| 13:59.13 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 14:28.07 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 14:34.24 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 14:34.52 | tzafrir | sruffell, is there any working example I could test? |
| 14:36.26 | tzafrir | When exactly is a KOBJ_CHANGE event sent? Isn't it the same as the 'online' event explicitly sent from the span device in the sysfs branch? |
| 14:39.57 | sruffell | ahh...I mispoke...KOBJ_ONLINE is what I meant, not KOBJ_CHANGE. |
| 14:41.39 | sruffell | as for an example.....it's not fit for human consumption, but all the gory edits are at http://github.com/sruffell/dahdi-linux/tree/sruffells-sysfs. I started down the path of removing the global _chans list, but that's been quite involved and I don't want to get that tied up into the default case of first come first serve span numbering. |
| 14:42.49 | tzafrir | one thing that can go towards the goal of removing that list is reduce its usage, though |
| 14:43.23 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 14:43.29 | tzafrir | specifically, it should be possible not to use it in almost all system calls |
| 14:44.08 | sruffell | yeah..that's done on that branch.....it's still not moved out of the spanno assignment path...and conferencing seems to make assumptions about it. |
| 14:44.22 | sruffell | like I said...not really in a form for review..but feel free to see what's there. |
| 14:45.08 | sruffell | <PROTECTED> |
| 15:22.42 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:22.42 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:31.30 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 15:31.52 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 15:50.44 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 15:53.27 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 15:54.29 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 15:56.57 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 16:07.37 | *** join/#asterisk-dev mpe (~mpe@x1-6-00-1e-2a-2a-b3-a2.k758.webspeed.dk) |
| 16:22.52 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 16:25.32 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 16:34.28 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 16:36.52 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 16:48.12 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@63.64.154.89) |
| 16:50.33 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 16:57.13 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 16:59.32 | *** join/#asterisk-dev mpe (~mpe@x1-6-00-1e-2a-2a-b3-a2.k758.webspeed.dk) |
| 17:34.36 | *** join/#asterisk-dev mpe (~mpe@x1-6-00-1e-2a-2a-b3-a2.k758.webspeed.dk) |
| 17:43.19 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 17:50.28 | seanbright | good times. |
| 17:52.56 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-150-41.cinci.res.rr.com) |
| 17:55.14 | russellb | mhm |
| 17:55.19 | kpfleming | seanbright: lolzerz |
| 18:20.41 | seanbright | so whats everyone doing today? |
| 18:20.44 | seanbright | asterisk dev'ing? |
| 18:25.19 | kpfleming | writing a new relational SQL database in POSIX shell |
| 18:26.16 | pabelanger | drinking a Barq's root beer |
| 18:26.51 | russellb | napping |
| 18:27.00 | seanbright | excellent |
| 18:33.27 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@c-68-34-116-180.hsd1.md.comcast.net) |
| 18:33.28 | Kobaz | waiting on hold for adtran tech support |
| 18:33.35 | Kobaz | and writing some last minute code for an install tomorrow |
| 18:33.48 | seanbright | so will FORMAT2 cause the RFC to get updated? |
| 18:35.26 | Kobaz | and trying to figure out why music on hold gets some nasty corruption in 1.6.2 |
| 18:36.39 | putnopvut | I saw the mailing list post about that. Weird looking stuff indeed. |
| 18:36.41 | russellb | seanbright: we have a number of other additions that need to get into a standards doc |
| 18:36.56 | kpfleming | RFCs don't get updated |
| 18:36.59 | russellb | seanbright: and it's actually a new RFC that is a set of additions to the old one, not an update of the old one |
| 18:37.01 | seanbright | superceded |
| 18:37.05 | kpfleming | obsoleted |
| 18:37.19 | seanbright | damn |
| 18:37.27 | kpfleming | but FORMAT2 would not cause the entire RFC to be obsoleted... it's just a set of new IEs |
| 18:37.37 | kpfleming | just like the CALLTOKEN stuff |
| 18:37.40 | seanbright | i just got 5456 printed and bound |
| 18:37.45 | seanbright | so i can read it in the library |
| 18:37.46 | kpfleming | it doesn't change the protocl |
| 18:37.58 | seanbright | 'library' |
| 18:38.09 | Qwell | seanbright: you mean restroom, don't you? |
| 18:38.21 | seanbright | no |
| 18:38.23 | seanbright | yes. |
| 18:38.27 | Qwell | knew it. |
| 18:38.34 | seanbright | i know. i'm transparent. |
| 18:38.40 | file | it's true. |
| 18:38.47 | kpfleming | s/in the library/while watching chick movies' |
| 18:39.18 | Kobaz | haha |
| 18:39.34 | seanbright | is the new rfc still in process? |
| 18:39.52 | kpfleming | what new RFC? |
| 18:40.07 | seanbright | someone misspoke |
| 18:40.10 | seanbright | or i misread |
| 18:40.20 | kpfleming | we have plans to produce some. nothing serious has been done yet. |
| 18:40.28 | kpfleming | there are three or four needed, for various things. |
| 18:41.02 | seanbright | gotcha. |
| 18:42.12 | file | never enough time! |
| 18:42.50 | seanbright | very true. |
| 18:43.55 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 19:20.57 | tzafrir | sruffell, still here? |
| 19:21.07 | sruffell | yes sir |
| 19:50.01 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 20:40.25 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 21:48.25 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.50.119.172) |
| 21:53.04 | *** join/#asterisk-dev hehol (~Adium@ip-78-94-0-76.unitymediagroup.de) |