| 00:01.11 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 00:02.17 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:02.17 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 00:17.31 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 00:37.08 | *** join/#asterisk-dev eliel_ (n=eliels@151-202-114-200.fibertel.com.ar) |
| 02:14.19 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 02:14.19 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 02:32.32 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 02:41.55 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 02:41.55 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:54.09 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 02:58.58 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.194) |
| 02:59.42 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 04:34.55 | *** join/#asterisk-dev ScribbleJ (n=nsj@c-67-172-6-141.hsd1.il.comcast.net) |
| 04:48.45 | *** join/#asterisk-dev CunningPike (n=arodgers@S01060014bf81366b.vc.shawcable.net) |
| 05:39.12 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 06:19.41 | *** join/#asterisk-dev fiddur (i=fiddur@c042.rit.se) |
| 06:19.52 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 06:41.56 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.199) |
| 06:51.42 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:51.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:23.58 | *** join/#asterisk-dev frawd (n=francois@244.Red-83-60-157.dynamicIP.rima-tde.net) |
| 08:28.40 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:28.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:00.24 | *** part/#asterisk-dev frawd (n=francois@244.Red-83-60-157.dynamicIP.rima-tde.net) |
| 09:04.41 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:40.52 | *** join/#asterisk-dev Mr_BOnD_007 (i=bond0070@119.160.199.6) |
| 10:33.35 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 10:33.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:17.13 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:24.46 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 11:24.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:03.48 | oej | Hello there, folks |
| 12:04.36 | tzafrir_laptop | helloej |
| 12:11.46 | mvanbaak | hello oej |
| 12:22.24 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 12:42.33 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.207) |
| 13:12.07 | *** join/#asterisk-dev DarkRift (n=dark@bas1-sthubert21-1096611993.dsl.bell.ca) |
| 13:19.54 | *** join/#asterisk-dev shido6 (n=shido6@96-28-34-156.dhcp.insightbb.com) |
| 13:38.50 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.186.223) |
| 14:22.23 | Corydon76-dig | Morning, jsmith |
| 14:23.23 | jsmith | Morning Corydon76-dig! |
| 14:23.23 | Corydon76-dig | How's the show? |
| 14:24.41 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:24.41 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:24.55 | Corydon76-dig | Morning, lmadsen |
| 14:26.00 | lmadsen | Corydon76-dig: morning sir! |
| 14:29.20 | tzanger | Octothorpe|away: my bro got his CCIE yesterday |
| 14:29.46 | lmadsen | tzanger: guess he got all the smarts eh? |
| 14:29.51 | lmadsen | ;) |
| 14:29.52 | tzanger | lmadsen: for sure |
| 14:30.15 | tzanger | although he told me by saying "my quest to lower the IQ of the average CCIE has been successful." |
| 14:31.31 | lmadsen | lol |
| 14:31.32 | lmadsen | sweet :) |
| 14:37.00 | lmadsen | mvanbaak: w00t! E71 shipped :) |
| 14:37.23 | lmadsen | left NJ at 3:15am! |
| 14:39.43 | jsmith | Corydon76-dig: It's good... I'm exhausted from teaching, but the show is going well |
| 14:43.22 | Corydon76-dig | jsmith: don't eat all the Israeli chocolate. ;-) |
| 14:44.50 | jsmith | Corydon76-dig: Haven't even opened the bag yet, as I knew I'd go overboard |
| 14:45.08 | jsmith | Corydon76-dig: I have, however, been nibbling on some English chocolates that David Duffett shared w/ me |
| 14:45.09 | tzanger | lmadsen: haha you got an E71? |
| 14:45.16 | tzanger | I'm waiting for a Usbee-SX to arrive today |
| 14:51.18 | *** join/#asterisk-dev ctooley (n=ctooley@12.165.91.2) |
| 14:51.18 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 14:55.04 | *** join/#asterisk-dev DarylVOIP (n=daryl@75.147.121.177) |
| 14:59.47 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-bccf72b386862e9d) |
| 14:59.47 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:04.27 | *** join/#asterisk-dev mnicholson_ (n=matthew@72.146.43.239) |
| 15:24.53 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 15:28.21 | *** join/#asterisk-dev sasargen (n=chatzill@72-58-224-209.pools.spcsdns.net) |
| 15:29.00 | DarylVOIP | Does anyone know a reasonable string to sent to an Asterisk box to see if IAX2 is working? I'm trying to check it with an F5 BigIP rule and can send <something> and need to get back some response that I can predict at least a portion of. |
| 15:35.10 | agx | does app_queue alread provide hints? to monitor a queue status via BLF is it just a matter of updating the state when there are 0 (IDLE) or more then 0 (BUSY) people inside a queue? i see a good spot to put this infoes is where there are already manager events fired out, right? |
| 15:36.56 | agx | like: ast_device_state_changed("queue:%s", queuename); ? |
| 15:41.10 | putnopvut | agx: nope, queues don't do that. |
| 15:43.40 | agx | putnopvut, i know; sorry for bad english :) i meant i think its not difficult to add it, right? |
| 15:43.54 | putnopvut | hmm...it may not be difficult to add it. |
| 15:44.46 | agx | putnopvut, i just watched the code that does the parkinglot hint and do something like that: it just involve calling 2 functions: ast_device_state_change() and the callback that will return the queue status, right? |
| 15:45.23 | agx | putnopvut, i've to lock the queue structure and count the people that are in queue: if its 0 then its IDLE if is > 0 then its BUSY, right? |
| 15:46.05 | putnopvut | agx: you may want to do something slightly different than that. |
| 15:46.45 | putnopvut | If its 0 then its "not in use", if it's > 0 and < maxlen, then it is "in use" |
| 15:46.53 | putnopvut | If the count == maxlen, then it is "busy" |
| 15:47.06 | putnopvut | That logic is similar to what chan_sip uses to report the device state of a SIP device. |
| 15:47.28 | agx | putnopvut, i did this already for an external app: http://pastebin.com/m6ea6b65f |
| 15:49.07 | agx | putnopvut, i see now :) perhaps i should try to report a ringing state if the queue is not full and busy only if the queue is full (count==maxlen) ? :) |
| 15:49.33 | putnopvut | that would make sense. one problem I'm trying to understand is what the use of these hints would be. |
| 15:50.07 | agx | putnopvut, to have a BLF that show if there are people inside the queue instead of having 20 BLF blinking all the time :) |
| 15:50.43 | agx | putnopvut, using static memeber queue = SIP/10, SIP/11, ... SIP/20... and monitoring via exten=>hint,SIP/10&SIP/11&...SIP/20... |
| 15:51.16 | agx | putnopvut, the BLF get blinking when you have a call also from non-queue like from 10 to 11 |
| 15:51.26 | putnopvut | oh, I see. That is a neat idea :) |
| 15:53.28 | oej | agx: That sounds like a cool idea. |
| 15:53.56 | agx | ok thanks: 2nd step now |
| 15:54.00 | oej | agx: It should be configurable as to what states you want. I can imagine someone wants it to blink when there's too many people in the queue |
| 15:54.32 | oej | wrote the metermaids - states for parkinglots |
| 15:54.37 | agx | i'm not a member of the queue, how do i pickup a call off from the queue? is there already a function or i should use something like "QueueUnparkCall()" ? |
| 15:54.42 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:54.55 | agx | oej, indeed actually i watched that code and patched an external app: app_valetparking to support same stuff |
| 15:55.43 | agx | oej, so i got the idea that app_queue is not much different then the parking stuff |
| 15:59.15 | *** part/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 16:00.32 | oej | agx: Well, but there are many more options on what people want to react to. |
| 16:00.45 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 16:02.21 | agx | oej, like? |
| 16:06.36 | *** join/#asterisk-dev moy (n=chatzill@bas1-unionville55-1177733953.dsl.bell.ca) |
| 16:08.19 | *** join/#asterisk-dev sasargen_ (n=chatzill@72-58-224-209.pools.spcsdns.net) |
| 16:10.39 | oej | agx: Like I mentioned earlier, a fast blink when the queue is full and needs more agents |
| 16:10.50 | oej | agx: A steady lamp when everything is ok |
| 16:11.22 | oej | oej: You basically have off, on, slow blink (hold) and fast blink(ringing) to play with on most business phones |
| 16:11.41 | mvanbaak | oej is talking to himself ? |
| 16:12.41 | oej | Note to myself: Don't mumble to myself |
| 16:13.39 | agx | mvanbaak, lol |
| 16:14.01 | agx | oej, oh i see i can use "hold" to play too |
| 16:14.56 | agx | oej, ok thanks - i'll give a try in free time to see what i'm able to figure out :) |
| 16:15.07 | oej | agx: Good luck! |
| 16:20.19 | *** join/#asterisk-dev jsolis (n=jimmy@190.41.153.85) |
| 16:29.33 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.171.23) |
| 16:31.49 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:31.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:32.39 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 16:37.50 | mcargile | So I am seeing the following errors in asterisk-1.6.1-rc1 but I am not sure what is causing them to show up so I am not quite sure how to report them in the bug tracker. http://pastebin.ca/1327187 |
| 16:40.42 | sasargen | On asterisk 1.4.23.1 __ast_play_and_record in app.c sets "duration" of the recording prior to silence removal and recording prepend, even though both of these processes change the length of the recording. Is there any reason the final length of the recording is not returned as "duration"? |
| 16:42.12 | mcargile | sorry wrong pastebin. http://pastebin.ca/1327194 this one has more of the CLI output |
| 16:42.19 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-100abccbbc48404f) |
| 16:42.19 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:43.47 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:52.56 | lmadsen | tzanger: E71... aye :) |
| 17:00.34 | *** join/#asterisk-dev angler_ (n=angler@nat/digium/x-f85694e252f7ee41) |
| 17:00.37 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-e3c1667d6482116a) |
| 17:00.43 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:00.43 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:00.46 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-904d650f6263664f) |
| 17:00.46 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:00.50 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@nat/digium/x-dbb695dfbffd0d14) |
| 17:02.05 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 17:02.05 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 17:03.17 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-8b1a0e17e7902fd5) |
| 17:03.17 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 17:32.07 | *** join/#asterisk-dev oej (n=olle@80.251.192.2) |
| 17:32.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:41.43 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 17:41.43 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 17:44.33 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 17:44.33 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 17:44.59 | *** join/#asterisk-dev sasargen_ (n=chatzill@68-245-179-195.pools.spcsdns.net) |
| 17:45.14 | Qwell | putnopvut: unlock spyee if it doesn't exist? |
| 17:45.16 | Qwell | that makes no sense to me O.o |
| 17:45.18 | Qwell | ast_channel_unlock(NULL)? |
| 17:46.17 | seanbright | it's over your head |
| 17:46.31 | putnopvut | Qwell: look at the next commit |
| 17:46.49 | Qwell | yeah, I see it now |
| 17:46.58 | Qwell | it takes forever for svn-commits to get to me... |
| 17:47.11 | putnopvut | same here. But the IRC channel is pretty quick. |
| 17:47.39 | kpfleming | nothing quite like public honesty :-) |
| 17:48.34 | putnopvut | kpfleming: I've come to terms with the fact that with OSS, mistakes are public knowledge. |
| 17:49.56 | seanbright | what makes a commit message come through [svn-commits] vs. [asterisk-commit]? |
| 17:51.07 | seanbright | for example, the 1.4 commit came through [svn-commits]. the trunk and branch commit came through [asterisk-commits] |
| 17:51.15 | seanbright | <-- confusulated |
| 17:51.24 | kpfleming | it should always go to both lists |
| 17:51.27 | kpfleming | are you subscribed to both lists? |
| 17:51.30 | seanbright | i am, yes. |
| 17:51.39 | seanbright | maybe it's my filtering |
| 17:51.42 | kpfleming | then your mail client or somethign else is dropping one of the two messages |
| 17:51.54 | kpfleming | otherwise you'd see all asterisk commits twice |
| 17:52.35 | seanbright | should i unsubscribe from one? |
| 17:52.41 | seanbright | are they redundant? |
| 17:52.44 | kpfleming | yes |
| 17:52.47 | seanbright | cool |
| 17:52.50 | kpfleming | svn-commits is *everything* public |
| 17:52.54 | seanbright | ahh |
| 17:52.55 | seanbright | cool |
| 17:53.14 | kpfleming | and if you want to organize the messages into folders, there are custom headers in the messages you can filter on |
| 17:53.25 | seanbright | yeah, i think i use listid |
| 17:53.46 | kpfleming | no, i mean within the svn-commits list |
| 17:53.53 | seanbright | ohhh, gotcha |
| 17:53.56 | kpfleming | you could filter asterisk, dahdi, repotools, etc. into different folders |
| 17:54.03 | seanbright | cool |
| 17:55.49 | ScribbleJ | I have the dumb question, because I am in over my head here. If I have a program that wants "16-bit PCM, 8khz" and I am feeding it SLINEAR from asterisk, is that all the same then? |
| 17:56.26 | kpfleming | yes |
| 17:56.47 | ScribbleJ | Thanks. |
| 17:56.49 | kpfleming | not a dumb question, actually, a well formed and accurate question :-) |
| 17:58.00 | ScribbleJ | Shucks, thanks. |
| 18:50.59 | *** join/#asterisk-dev sasargen (n=chatzill@68-245-179-195.pools.spcsdns.net) |
| 18:57.30 | *** join/#asterisk-dev manxpower (n=Administ@router.asteriasgi.com) |
| 18:57.53 | manxpower | in 1.6 neither ${ACCOUNTCODE} nor ${CHANNEL(accountcode)} do not seem to work. |
| 19:00.32 | manxpower | UPGRADE.txt indicates it was turned into a function, but there is no function ACCOUNTCODE |
| 19:02.37 | snuff-home | manxpower: accountcode was for CDR as i remember.. |
| 19:02.57 | snuff-home | aka ${CDR(ACCOUNTCODE)} |
| 19:03.04 | snuff-home | would show u value |
| 19:03.05 | manxpower | snuff-home: perhaps, but you could access it from the dialplan as ${ACCOUNTCODE} for years |
| 19:03.14 | manxpower | Ah, I shall try that |
| 19:04.15 | snuff-home | mm manxpower never knew that.. its 6am and i've already learnt something for the day.. |
| 19:05.14 | manxpower | snuff-home: ${CDR(accountcode)} worked. Thanks |
| 19:06.06 | lmadsen | maybe the UPGRADE.txt should say which function :) |
| 19:06.17 | lmadsen | "it's one of those functions... --> over there" |
| 19:12.36 | snuff-home | mm what happened to the bot that announced new bugs.digium issues? |
| 19:15.07 | lmadsen | good question... |
| 19:15.12 | lmadsen | I had actually forgotten about him |
| 19:15.15 | lmadsen | oh! |
| 19:15.20 | lmadsen | moved to #asterisk-bugs :) |
| 19:15.47 | lmadsen | although I don't think it announces new issues now that you mention it... just closed issues |
| 19:25.00 | *** join/#asterisk-dev oh2gma (n=oh2gma@xdsl-83-150-94-231.nebulazone.fi) |
| 19:25.32 | ScribbleJ | Hey, can someone tell me if I'm 'doin' it wrong' -? Writing plugin to Generic Speech API, want to use silence detection dsp to tell where speech ends, but data provided in speech API is just the /data/ portion of the slinear frames, not the full frame. So I have to take the data provided to me in the speech api, and build a new frame for it then pass it to the dsp. |
| 19:26.32 | ScribbleJ | So I guess my question is twofold: 1) Why the decision to jut send the slinear data to the speech api rather than the full frame struct, or even allowing the speech api engine to select frame type? 2) Considering how it is... am I doin it right? |
| 19:28.17 | file | I don't remember why I did it that way... and yeah, that seems fine |
| 19:28.46 | ScribbleJ | file: you are the man, incidentally, I mean, if you are the man who wrote this, it's quite nice. That's my sole complaint. |
| 19:29.04 | ScribbleJ | And I already worked 'around' it as described. |
| 19:29.08 | file | yay |
| 19:29.57 | ScribbleJ | Anyhow, slin seems to be the appropriate type for any speech rec system I've heard of, so it's only a questionable decision when you're doing something dumb like I am that prolly should be in the rec engine anyhow. |
| 19:31.28 | file | nods |
| 19:31.48 | file | the Lumenvox stuff takes care of all that, which is why there isn't some stuff built in to do that if the engine is not capable |
| 19:32.03 | ScribbleJ | Yeah, it seemed to me this was probably all written with LumenVox in mind - |
| 19:32.19 | ScribbleJ | Which is why I think you are so brilliant for making it a generic plugin API in the first place. |
| 19:32.35 | file | that's the way we do things. |
| 19:32.39 | ScribbleJ | Makes stuff a lot easier for me. |
| 19:36.11 | *** part/#asterisk-dev manxpower (n=Administ@router.asteriasgi.com) |
| 19:36.41 | oh2gma | hello, how can I enable debugging on 1.6.1-rc1? 'core set debug 1-10' doesn't give me anything. |
| 19:37.02 | Corydon76-dig | oh2gma: enable debug in logger.conf |
| 19:37.14 | oh2gma | thanks |
| 19:53.00 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 19:53.00 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 19:57.23 | *** part/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 20:10.59 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 20:32.17 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) |
| 20:32.25 | Damin | Hmm.. |
| 20:32.36 | Damin | Is there any way to disable packet2packet bridging in 1.4? |
| 20:33.31 | file | not directly |
| 20:34.33 | file | any Dial features that require DTMF will force stuff to go through the core |
| 20:39.23 | Damin | file: Ok.. I'm actually running up against the same Sonus/XO/L3 interop bug as Kristian has.. |
| 20:39.50 | Damin | file: Basically, the only thing that I can get to reliably pass DTMF to L3 is using g711 w/ inband DTMF. |
| 20:39.58 | file | if it is packet2packet bridging then we aren't generating the RFC2833 packets... we are passing them through |
| 20:40.01 | Damin | file: RFC2833 from Asterisk to Sonus is unreliable.. |
| 20:41.03 | Damin | file: On one side, I have a 1.2 box connected to a 1.4 box w/ rfc2833compensate=yes enabled. On the other side, I've got a SIP session to an L3 Sonus SBC.. |
| 20:41.55 | Damin | file: I'm trying to force the 1.4 box to NOT packet2packet bridge... so can I force the 1.4 box to answer and play an audio file before dialing? |
| 20:42.07 | file | that wouldn't do it |
| 20:42.21 | Damin | file: The idea here is to see if masquerading the 1.2 box behind the 1.4 box has any positive/negative effects.. |
| 20:42.48 | file | hrm the code does not check if compensation is enabled |
| 20:42.49 | Corydon76-dig | file: glad to see you're feeling better |
| 20:42.57 | file | Corydon76-dig: meh |
| 20:43.58 | file | Damin: tT will stop a packet2packet bridge |
| 20:45.26 | Damin | file: i was just going to ask if "t" would work.. |
| 20:45.31 | Damin | file: Alright.. let me try that.. |
| 20:45.48 | Damin | file: I assume that forces the call through the core, and sets a DSP on the channel so that it can pick up the DTMF event.. |
| 20:46.00 | file | nope ... |
| 20:46.04 | file | it just forces it through the core |
| 20:46.15 | file | if the DTMF is already coming in as RFC2833 then a DSP is pointless |
| 20:48.33 | Damin | file: Yeah.. that makes sense.. |
| 20:49.45 | Corydon76-dig | Anybody else's spouses call them 3 times a day, while they're at work? |
| 20:51.10 | Damin | Corydon76-dig: Mine does.. |
| 20:51.22 | Damin | Corydon76-dig: Doesn't mean that I answer it though! ;) |
| 20:51.44 | Corydon76-dig | Damin: heh |
| 20:51.46 | Damin | file: OK.. so it still doesn't work even if it brings it into the core.. |
| 20:51.56 | Damin | file: Just tested... |
| 20:52.13 | file | ok |
| 20:52.30 | Damin | file: So it looks like we can't get Asterisk 1.4 to work properly w/ L3's Vector network unelss we use G711ulaw and Inband DTMF.. which sucks.. |
| 20:53.10 | Damin | file: For whatever reason, their Sonus doesn't like 1.4's RFC-2833.. |
| 20:53.25 | file | or 1.2's apparently |
| 20:53.30 | Damin | file: Kielhofner has a theory that it is on the Sonus side.. |
| 20:53.39 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 20:54.12 | Damin | file: yeah.. they wouldn't even have a conversation about 1.2.... just basically said.. "Our trace shows RFC violations in your DTMF stream.. you need to fix your implementation"... |
| 20:54.31 | Damin | file: Which on 1.2 is no big surprise.. |
| 20:54.43 | lmadsen | funny how almost everyone else can interopt with asterisk... :) |
| 20:55.07 | Damin | lmadsen: Yep.. |
| 20:55.20 | Damin | lmadsen: You know anyone using 1.4 w/ L3's Sonus network? |
| 20:55.23 | lmadsen | nope |
| 20:55.40 | Damin | lmadsen: Ughh.. |
| 20:55.44 | lmadsen | if I did, I presume I'd be having the same problem as kristian and yourself |
| 21:01.50 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 21:04.41 | *** join/#asterisk-dev jsolis (n=jimmy@190.41.153.85) |
| 21:18.35 | Damin | From Kielhofner: |
| 21:18.36 | Damin | Looks much better. However... Do you see the large gap between the last voice RTP packet and the first DTMF event? Yeah, that's the delay introduced by Asterisk while the DTMF traverses the core. |
| 21:18.36 | Damin | Catch 22 for you: You need DTMF to go through the core so you can fix it up. However, this introduces enough delay to exceed the Sonus DSPs buffer (100ms). |
| 21:18.36 | Damin | Thus, your events are discarded. |
| 21:31.19 | Damin | So.. |
| 21:31.46 | Damin | Any way to have the core continue to send RTP during a DTMF event? |
| 21:35.00 | mvanbaak | Corydon76-dig: you're too fast |
| 21:35.18 | mvanbaak | Corydon76-dig: I was reading the patch for xml docs in res_jabber |
| 21:35.37 | mvanbaak | Corydon76-dig: going back to the ticket to assign it to me just to find out you already got it in |
| 21:37.25 | Corydon76-dig | mvanbaak: I assigned it to myself before working on it |
| 21:37.45 | kpfleming | Damin: it's supposed to continue to send RTP unless you have DTMF controlled features enabled |
| 21:38.11 | kpfleming | if we receive RTP continuation events, we'll forward them on |
| 21:42.45 | Damin | kpfleming: OK.. so here is where I am at.. Using 1.4 is not an option.. because in it's most basic form, using Packet2Packet bridging, the 1.2 DTMF events will be bridged out directly to the Sonus (this doesn't work). |
| 21:43.07 | Damin | kpfleming: 1.2 isn't an option.. because the DTMF implemention is just borked enough that it doesn't work at all.. |
| 21:43.07 | kpfleming | correct |
| 21:43.48 | kpfleming | are you saying the source of these DTMF events is Asterisk 1.2? |
| 21:44.00 | Damin | kpfleming: So to may Switchvox systems play nice w/ Level 3 requires injecting an Asterisk server in the middle that uses g711ulaw and inband DTMF. |
| 21:44.18 | Damin | kpfleming: Doesn't matter. 1.2 fails RFC2833 tests w/ Sonus, as does 1.4 |
| 21:44.18 | kpfleming | right |
| 21:44.32 | kpfleming | what is the *source* of the DTMF events? |
| 21:44.35 | Damin | kpfleming: This means that g729 w/ Level 3 is not an option.. |
| 21:44.40 | kpfleming | a SIP phone, an analog device, etc. |
| 21:44.53 | Damin | kpfleming: Switchvox and Altigen PBX systems.. |
| 21:45.00 | kpfleming | that does not answer the question |
| 21:45.03 | kpfleming | those are devices in the path |
| 21:45.16 | Damin | kpfleming: Polycom -> Switchvox -> Asterisk 1.2 -> l3 |
| 21:45.29 | Damin | kpfleming: Polycom -> Switchvox -> Asterisk 1.4 -> L3 |
| 21:45.33 | kpfleming | so, we know the Polycom device generated the RFC2833 events properly |
| 21:45.47 | kpfleming | the Switchvox system is based on 1.2, so it will 'corrupt' them, essentially |
| 21:45.54 | Damin | kpfleming: Yes.. that's my point.. |
| 21:46.09 | mvanbaak | Corydon76-dig: I noticed :) |
| 21:46.23 | kpfleming | and i don't remember whether 1.2 sends the single DTMF event at the beginning or the end... i think it's at the end |
| 21:46.36 | Damin | kpfleming: it rapid fires them all at the end of the event.. |
| 21:46.43 | kpfleming | so... that cannot be fixed |
| 21:47.04 | kpfleming | because during the time of the DTMF event, the polycom phone is not sending audio packets, it's sending RFC2833 continuation packets |
| 21:47.13 | Damin | kpfleming: Unless I put a 1.4 box in w/ rfc2833compensate=yes, and there are some patches to 1.4 to make it's native DTMF output actually work properly as well.. |
| 21:47.16 | kpfleming | the 1.2 box is eating those |
| 21:47.29 | Damin | kpfleming: Yep.. |
| 21:47.48 | kpfleming | i don't see how that could fix it either... during the time that the Polycom phone is sending DTMF, the 1.2 box won't be receiving or sending audio frames, and neither will the 1.4 box |
| 21:48.00 | Damin | kpfleming: I was kind of hoping that using a "t" as file suggested earlier would work, but it does not appear to.. |
| 21:48.01 | kpfleming | and the 1.4 box does not know that a DTMF event is occurring, because the 1.2 box hasn't told it yet |
| 21:48.27 | kpfleming | so if you need 'no gaps in audio', you can't solve this problem |
| 21:48.34 | kpfleming | not with asterisk 1.2 in the path |
| 21:48.49 | Damin | kpfleming: Is Switchvox SMB 4.0 based on 1.4? |
| 21:48.53 | kpfleming | yes |
| 21:49.09 | kpfleming | ABE C.x, but the same thing, yes |
| 21:49.33 | Damin | kpfleming: is it theoritically possible to get 1.4 to 1.4 to "work properly"? |
| 21:50.15 | kpfleming | it should already work properly, as long as none of the 1.4 systems have DTMF controlled features enabled |
| 21:50.31 | kpfleming | that is assuming the original source of the DTMF events generated them correctly |
| 21:51.09 | Damin | kpfleming: Has 4.0 SMB been dropped for public consumption yet? I can try to upgrade a few lab boxes and see if that theory tests out.. |
| 21:51.37 | kpfleming | no, it has not |
| 21:51.58 | Damin | kpfleming: That would be a good test.. |
| 21:53.47 | kpfleming | testing with a plain 1.4 box should be equivalent |
| 21:55.07 | Damin | kpfleming: Yeah.. I can do that.. I'll setup a registration from my Polycom to a 1.4 box and test.. |
| 21:55.12 | kpfleming | thanks |
| 21:55.19 | kpfleming | that would be good to have as a test |
| 22:00.55 | Damin | kpfleming: One other test I'm going to do is to test 1.2 and 1.4 behind a FreeSwitch box. They specifically hacked something into their core to workaround the Sonus issue.. |
| 22:01.13 | kpfleming | you didn't understand what i told you |
| 22:01.22 | kpfleming | during the time that the DTMF event is occurring, no audio packets are flowing |
| 22:01.26 | Damin | kpfleming: I'm pretty sure that proxying everything through a FreeSwitch server would actually fix the issue. |
| 22:01.28 | kpfleming | and nothing can create them, except for PLC |
| 22:01.40 | kpfleming | there aren't any audio packets to forward |
| 22:01.49 | Damin | kpfleming: I understand it completely.. There is a "hack" in freeswitch that works around it w/ SONUS. |
| 22:02.08 | Damin | kpfleming: I'll see if I can find the commit for it.. |
| 22:02.19 | kpfleming | so they just generate audio packets whenever there aren't any? |
| 22:02.22 | kpfleming | that seems wrong |
| 22:02.36 | Damin | kpfleming: I don't claim to know what it does.. |
| 22:03.16 | kpfleming | you should :-) |
| 22:04.30 | kpfleming | you should claim, i mean. you don't have to actually know what it does. |
| 22:04.59 | Damin | kpfleming: I believe this is the patch http://fisheye.freeswitch.org/browse/FreeSWITCH/src/include/switch_types.h?r=10664 |
| 22:05.17 | kpfleming | i don't think i can look at it, sorry |
| 22:07.01 | snuff-work | thanks mvanbaak / Corydon76-dig accepting the xml for res_jabber :) |
| 22:07.13 | putnopvut | snuff-work: thanks for writing it! |
| 22:10.28 | snuff-work | i've done little more on the ao2 jabber.. made callbacks etc.. still can't get refcounts to fully balance out :( |
| 22:12.27 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 22:12.28 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:12.46 | snuff-work | mm bad pigdin |
| 22:13.23 | mvanbaak | I thought you were using ao2_irssi ;) |
| 22:13.43 | snuff-work | irssi is on my home lappy.. this is work |
| 22:14.01 | mvanbaak | I'm running irssi in a screen on a server |
| 22:14.14 | mvanbaak | no matter where I am, I use it with the help of ssh |
| 22:18.27 | snuff-work | ah. that would require little extra effort.. |
| 22:20.26 | ScribbleJ | mvanbaak, that is a nice setup; I personally prefer to attack it from the other end, though,a nd use dircproxy - then I can switch clients at will and miss nothing. Also the only reasonable way to do it from .e.g a bberry. |
| 22:21.48 | mvanbaak | ScribbleJ: use ssh on the blackberry ;) |
| 22:22.06 | ScribbleJ | mvanbaak, any particular client you like for it? |
| 22:22.22 | mvanbaak | ScribbleJ: I dont like the blackberry so no |
| 22:23.12 | ScribbleJ | Ah, I misread you. |
| 22:23.36 | mvanbaak | I bet there's an ssh client for the blackberry |
| 22:23.42 | mvanbaak | if not, throw away the phone |
| 22:24.49 | ScribbleJ | Oh, there are... but all the ones I have used are uncomfortable. |
| 22:24.49 | mvanbaak | I find the blackberry uncomfortable |
| 22:24.49 | ScribbleJ | And I did, actually... a few months ago I decided to screw the 'smartphone' trend and get something simple that is Just A Phone. |
| 22:25.24 | mvanbaak | I always take my eeepc with me. so if I need irc/mail whatever I use that one to login to my server and run 'screen -rd' |
| 22:25.43 | ScribbleJ | Oooh, that sounds nice. |
| 22:26.37 | mvanbaak | uhhuh |
| 22:26.42 | mvanbaak | [ shellbox ][ (0*irc) 1 mail 2 voip 3 virsh 4- eggdrop-ambernet ][ 04/02 23:26 ] |
| 22:26.50 | mvanbaak | that's my screen statusline at the moment |
| 22:27.27 | mvanbaak | it's quiet right now because I'm prepping for bed |
| 22:30.03 | mvanbaak | ok, zzzzzzzzzzzzz time |
| 22:30.29 | ScribbleJ | Take it easy! |
| 22:35.49 | *** join/#asterisk-dev bird_of_Luck (n=melifaro@77.73.232.13) |
| 22:52.26 | Damin | kpfleming: Polycom -> 1.4 -> L3 Sonus using Packet2Packet bridging works fine. |
| 22:52.47 | kpfleming | that is what we would have expected |
| 22:53.07 | kpfleming | in theory, it should also work without P2P bridging, as long as no DTMF-controlled features are enabled |
| 22:53.17 | kpfleming | however, there may not be any way to force that without enabling features |
| 22:53.30 | kpfleming | i don't remember well enough, but mr file would know |
| 22:53.33 | Damin | kpfleming: However, when I add a "tT" to the dial string, and disable packet2packet, it breaks.. |
| 22:53.57 | kpfleming | ok |
| 22:54.09 | file | yeah there is no way to disable p2p without a feature |
| 22:54.09 | kpfleming | you understand why that is? |
| 22:54.15 | Damin | kpfleming: Yes... |
| 22:54.18 | kpfleming | ok, good |
| 22:54.34 | Damin | kpfleming: Because Asterisk waits until the end of the event before forwarding it.. |
| 22:54.40 | kpfleming | right |
| 22:54.46 | kpfleming | because the feature code is watching the events |
| 22:55.00 | Damin | kpfleming: Unfortunately, at that point, the Sonus is already borked.. |
| 22:55.11 | kpfleming | that feature code, in 1.6, could be improved to allow the events to be forwarded if the BEGIN event does not match a feature code, i guess |
| 22:55.34 | kpfleming | but if it does, there is no fix |
| 22:55.54 | Damin | kpfleming: So the upshot if this is.. if you have a 1.2 box, you can't use it w/ L3. :) |
| 22:56.02 | kpfleming | yes |
| 22:56.09 | Damin | kpfleming: Which means that no current Switchvox implementations can use L3. |
| 22:56.14 | kpfleming | RFC2833 in 1.2 was just too badly broken |
| 22:57.11 | Damin | kpfleming: Well.. more precisely, if you have an Asterisk 1.2 box, you need to force g711ulaw and inband DTMF w/ any Sonus that you connect to.. |
| 22:57.26 | kpfleming | or anything you connect to that might end up connecting to a Sonus gateway |
| 23:06.56 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 23:06.56 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 23:31.59 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-0852bf864542304b) |
| 23:31.59 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 23:39.30 | *** join/#asterisk-dev ScribbleJ (n=nnsj@c-67-172-6-141.hsd1.il.comcast.net) |
| 23:39.48 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:53.14 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:59.14 | jpeeler | Corydon76-dig: something is not quite right with the working_fork detection in 1.6.0 |
| 23:59.26 | Corydon76-dig | jpeeler: how so? |
| 23:59.52 | putnopvut | Unknown value '@WORKING_VFORK@' found in build_tools/menuselect-deps for WORKING_VFORK |