| 00:12.52 | *** join/#asterisk-dev xpot-mobile (n=james@hsc-4-55.hotspot.utah.edu) |
| 00:47.56 | *** join/#asterisk-dev rue_mohr (n=rue@h24-207-90-17.cst.dccnet.com) |
| 00:48.20 | rue_mohr | the 1mw is also broken using 1.6.1.1 |
| 01:14.31 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 01:14.31 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 01:16.46 | rue_mohr | k, I'v logged it as a bug |
| 01:19.53 | russellb_ | there are no bugs |
| 01:24.04 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 01:25.50 | snuff-work | bugs are just unreported features |
| 01:41.51 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) |
| 01:41.51 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 01:42.18 | rue_mohr | mmmm |
| 01:42.55 | rue_mohr | I really want to find this -11db problem, but even if I could ap into the streams I wouldn't know where to tap |
| 01:43.18 | rue_mohr | the call path from the milliwatt app to the t1 card cant be that convouluded |
| 01:43.40 | rue_mohr | # 0015386 |
| 01:47.35 | rue_mohr | if dahdi_monitor works by creating a conference, isn't it plausable to have it operate on a sip channel? |
| 01:47.35 | russellb_ | rue_mohr: did you try both milliwatt methods in asterisk btw? |
| 01:47.43 | rue_mohr | yes |
| 01:47.46 | russellb_ | ok. |
| 01:47.53 | rue_mohr | milliwatt and playtones |
| 01:47.56 | russellb_ | the old and new methods, to be clear ... |
| 01:48.04 | russellb_ | i mean, milliwatt() and milliwatt(o) (use the old way) |
| 01:48.05 | rue_mohr | shall I add that clip to the report? |
| 01:48.28 | rue_mohr | didn't do milliwatt(o) Iused playtones(1000/1000) |
| 01:48.37 | russellb_ | so here's the thing ... |
| 01:48.52 | rue_mohr | but my meter isn't effected by freq |
| 01:48.57 | russellb_ | milliwatt() in 1.2 did one thing, milliwatt() in 1.6 uses playtones() internally |
| 01:49.13 | russellb_ | milliwatt(o) in 1.6 will do what 1.2 did with milliwatt() |
| 01:49.24 | rue_mohr | k, I'll give it a go right now |
| 01:49.35 | russellb_ | just trying to see if this change in how milliwatt() works is to blame |
| 01:51.05 | russellb_ | in fact (and really, please don't hit me), I think with playtones() (and milliwatt()), there is a -8dB setting or so built in by default |
| 01:51.08 | russellb_ | :-/ |
| 01:51.13 | rue_mohr | yup, I'm dedicated to helping pin this down |
| 01:51.46 | rue_mohr | I changed the dtmf levels in the code to 0, and it had no effect |
| 01:52.00 | russellb_ | where'd you change it? |
| 01:52.30 | russellb_ | specifically, i'm referring to some code in main/indications.c, where it says ... if (vol < 1) { d.vol = 7219; /* Default to -8db */ } |
| 01:52.36 | russellb_ | in any case, try it and we'll see ... |
| 01:52.52 | rue_mohr | russellb, I'll be damned, milliwatt(o) = -00.42dbm |
| 01:52.57 | russellb_ | :-X |
| 01:53.00 | rue_mohr | is it still a bug? |
| 01:53.28 | russellb_ | well, potentially. |
| 01:53.49 | russellb_ | By changing to use playtones internally, we got the exact frequency we wanted, but we got a db drop that was an unintended side effect |
| 01:53.56 | russellb_ | so, yeah, i would still call it a bug |
| 01:54.17 | russellb_ | so let me see what I can do about fixing this such that we don't get that drop ... |
| 01:54.20 | russellb_ | willing to try a patch? |
| 01:54.30 | russellb_ | also, what asterisk version? 1.6.1? |
| 01:55.43 | rue_mohr | yes, I'm willing to do patches, right now I'm more comfortable with 1.4.25.1 but am willing to go with 1.6.1.1 |
| 01:55.48 | JunK-Y | hi guys |
| 01:55.51 | russellb_ | nope, 1.4 is perfect |
| 01:55.54 | russellb_ | just needed to know which |
| 01:55.56 | rue_mohr | ok |
| 01:56.59 | rue_mohr | so 0db IS 14844... |
| 01:57.42 | russellb_ | ok, thanks |
| 02:01.44 | russellb_ | rue_mohr: ok, so, patch is uploaded to your issue |
| 02:01.51 | russellb_ | i'm at home and don't have any phones set up, so i couldn't test it |
| 02:01.54 | russellb_ | i just compiled it, heh |
| 02:02.38 | rue_mohr | thats ok I'm happy to test this |
| 02:03.00 | rue_mohr | digital_milliwatt is a 8 char buffer!? (I just found the code) |
| 02:03.06 | russellb_ | yeah, haha |
| 02:03.07 | rue_mohr | ok, patch... |
| 02:03.23 | russellb_ | but it's actually a little off, which is why we did the switch to playtones |
| 02:06.01 | russellb_ | i got the 14844 from you, heh |
| 02:06.42 | rue_mohr | :) |
| 02:07.22 | rue_mohr | sorry, been a while since I used a diff... |
| 02:07.27 | russellb_ | no problem |
| 02:07.30 | russellb_ | so, download the file ... |
| 02:07.36 | russellb_ | then, cd asterisk-1.4-source-tree |
| 02:07.51 | russellb_ | patch -p0 < issue_15386.rev1.diff |
| 02:08.38 | rue_mohr | ;) |
| 02:14.15 | rue_mohr | ok, your at -3.7dbm the sample end isn't aligning with the begin quite right, and I had to add wait() after it |
| 02:16.08 | russellb_ | hm, ok ... |
| 02:16.13 | russellb_ | well, at least we're on the right track |
| 02:16.23 | russellb_ | i'll have to poke at it more later when i can do some testing myself |
| 02:16.32 | rue_mohr | k |
| 02:17.21 | rue_mohr | I'll say dahdi_monitor should come out to 14844 |
| 02:17.46 | rue_mohr | thankyou |
| 02:17.52 | russellb_ | gotcha, you're welcome! |
| 02:18.02 | russellb_ | that volume setting may not be right for that API call ... |
| 02:18.12 | russellb_ | i need to look at how it works a bit closer i guess |
| 02:18.39 | russellb_ | got to go for the night, cya! |
| 03:01.01 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) |
| 03:17.25 | seanbright | so is there a CEL() dialplan function or not? |
| 03:17.28 | seanbright | i can't find it |
| 03:21.12 | *** join/#asterisk-dev salzh (n=Administ@61.87.216.5) |
| 03:22.11 | salzh | hi, is there some patches for chan_ooh323/chan_h323 to support video? |
| 03:35.46 | *** join/#asterisk-dev dbrooks (n=dbrooks@nat/digium/x-1f954deacfd3eca6) [NETSPLIT VICTIM] |
| 03:35.47 | *** join/#asterisk-dev davevg (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 03:35.47 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) |
| 03:37.19 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 03:37.19 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 03:37.20 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 03:37.20 | *** join/#asterisk-dev destructure (n=mu@trollbooth.com) [NETSPLIT VICTIM] |
| 03:37.20 | *** join/#asterisk-dev wdoekes (n=walter@wjd.osso.nl) |
| 03:37.20 | *** join/#asterisk-dev RoyCrowder (n=roy@net-216-37-64-130.in-addr.worldspice.net) |
| 03:37.20 | *** join/#asterisk-dev unpaidbill (i=bill@shackjews.com) |
| 03:37.20 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 03:41.21 | *** part/#asterisk-dev rue_mohr (n=rue@h24-207-90-17.cst.dccnet.com) |
| 03:50.30 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 04:28.58 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 05:00.03 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.80) |
| 05:03.16 | salzh | dir |
| 05:12.30 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 06:52.55 | *** join/#asterisk-dev fiddur (n=fiddur@c042.rit.se) |
| 07:08.57 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:55.14 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 08:27.02 | *** join/#asterisk-dev sergey (n=sergey@sergey-home.iks.ru) |
| 08:36.54 | *** join/#asterisk-dev oej (n=olle@240.Red-83-33-40.dynamicIP.rima-tde.net) |
| 08:36.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:05.29 | *** part/#asterisk-dev sergey (n=sergey@sergey-home.iks.ru) |
| 09:57.21 | *** part/#asterisk-dev oej (n=olle@240.Red-83-33-40.dynamicIP.rima-tde.net) |
| 10:17.01 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 10:17.01 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 10:20.42 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 10:35.26 | *** join/#asterisk-dev oej (n=olle@240.Red-83-33-40.dynamicIP.rima-tde.net) |
| 10:35.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:42.56 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 10:42.56 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 10:47.54 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 11:14.35 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:22.42 | *** join/#asterisk-dev salzh (n=Administ@122.144.138.5) |
| 11:29.02 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:29.02 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:35.33 | leifmadsen | and then it was morning |
| 11:40.46 | snuff-home | ello leifmadsen |
| 11:42.51 | leifmadsen | snuff-home: yo yo! |
| 11:43.22 | snuff-home | is debating fix for non posix glob call |
| 11:49.15 | *** join/#asterisk-dev oej_ (n=olle@240.Red-83-33-40.dynamicIP.rima-tde.net) |
| 11:52.35 | *** join/#asterisk-dev oej (n=olle@240.Red-83-33-40.dynamicIP.rima-tde.net) |
| 11:52.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:53.47 | *** join/#asterisk-dev oej (n=olle@240.Red-83-33-40.dynamicIP.rima-tde.net) |
| 11:53.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:58.55 | snuff-home | ello oej |
| 11:59.20 | oej | hello from a poor network connection in Spain! |
| 11:59.30 | snuff-home | mm looks it too :) |
| 11:59.51 | snuff-home | i see your trying to get that packet modem sip thing working |
| 12:00.56 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 12:00.56 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 12:00.56 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 12:00.57 | *** join/#asterisk-dev destructure (n=mu@trollbooth.com) [NETSPLIT VICTIM] |
| 12:00.57 | *** join/#asterisk-dev wdoekes (n=walter@wjd.osso.nl) |
| 12:14.35 | *** join/#asterisk-dev yerwish (n=geekangl@gw.idis.com.sa) |
| 12:14.35 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 12:14.35 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 12:14.36 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 12:14.36 | *** join/#asterisk-dev destructure (n=mu@trollbooth.com) [NETSPLIT VICTIM] |
| 12:14.36 | *** join/#asterisk-dev wdoekes (n=walter@wjd.osso.nl) |
| 12:15.41 | yerwish | How does Asterisk handle Digital Singal Processing? Is it software/hardware-based? |
| 12:17.59 | *** join/#asterisk-dev ctooley (n=ctooley@12.230.123.195) |
| 12:17.59 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 12:36.22 | tzafrir_laptop | yerwish, main/dsp.c ? |
| 12:36.28 | tzafrir_laptop | that's software-based |
| 12:36.44 | tzafrir_laptop | Naturally hardware-based DSP can also be used, if available |
| 12:43.03 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:43.03 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:45.15 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:45.15 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:47.12 | snuff-home | ello eliel |
| 12:47.17 | snuff-home | ello kpfleming |
| 12:47.27 | kpfleming | morning |
| 12:48.28 | eliel | snuff-home: morning |
| 12:48.32 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:48.32 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:48.33 | snuff-home | http://pastebin.ca/1472495 |
| 12:48.57 | snuff-home | that's my dodgey fix that i think would work for the 'glob' and braces issue |
| 12:50.27 | eliel | snuff-home: thanks, i wont be able to test/check/commit right now i am with gsoc + exams + work, so please report an issue about this, i will try to review it as soon as possible! |
| 12:51.36 | snuff-home | yer.. there has to be a nicer way that i just pasted |
| 12:51.50 | snuff-home | but u'd still just need to use the GLOB_APPEND |
| 12:52.03 | eliel | snuff-home: i would like to come up with a way of avoiding those dynamic memory allocations to make the code clean, but looks good, yes i understand the problem |
| 12:52.23 | eliel | if you can report the issue number so it gets assigned to me |
| 12:52.39 | snuff-home | yer.. i'll make it soon in the next day or so |
| 12:54.48 | eliel | snuff-home: thanks! thanks!! :) |
| 12:55.39 | snuff-home | i dont see big issue with dynamic alloc.. its only done once on startup |
| 12:56.26 | eliel | snuff-home: yes, it is just that i don't like all the list of ast_free().. :-) but maybe is the only way, i need to think a little |
| 12:56.38 | snuff-home | u can use alloca.. |
| 12:56.55 | snuff-home | that way it 'self frees' on exit |
| 12:56.59 | snuff-home | of function |
| 13:02.30 | eliel | yes |
| 13:20.49 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:25.20 | seanbright | kpfleming: prepare for troll attack |
| 13:25.24 | seanbright | that is all. |
| 13:25.42 | kpfleming | thank you |
| 13:25.51 | kpfleming | i will repel the attack with my zombie armies |
| 13:26.01 | seanbright | good luck and god speed. |
| 13:26.09 | seanbright | someone review my libpri patch |
| 13:26.11 | leifmadsen | I have a flower power? |
| 13:26.13 | seanbright | like... now |
| 13:26.18 | seanbright | NOW |
| 13:26.19 | file | seanbright: no. |
| 13:26.22 | seanbright | damn. |
| 13:26.38 | seanbright | waves a shiny object to and fro |
| 13:26.42 | seanbright | you are getting very sleepy... |
| 13:26.54 | file | no time for sleep, tons of stuff to do! |
| 13:27.21 | seanbright | so true |
| 13:27.36 | jsmith-away | file: Isn't that the truth... |
| 13:27.38 | *** join/#asterisk-dev Victor_Yure_ (n=victor@unaffiliated/victoryure/x-837844) |
| 13:27.54 | snuff-home | mm.. is sleep is good.. bout time i got some.. |
| 13:28.17 | seanbright | no |
| 13:28.23 | seanbright | you need to finish res_jabber ao2 |
| 13:28.25 | seanbright | right now |
| 13:28.43 | snuff-home | mm but noone loves it.. tests it anyway.. |
| 13:28.54 | seanbright | continues waving aforementioned shiny object |
| 13:29.22 | seanbright | snuff-home: meh... just commit it. the users will test it. |
| 13:29.27 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 13:29.27 | leifmadsen | snuff-home: I'll test it! I like res_jabber |
| 13:31.34 | snuff-home | mm i think i have to resolve a conflict on my svn version.. but otherwise it should be still 'testable' |
| 13:36.22 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:36.22 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:36.32 | leifmadsen | putnopvut: ! |
| 13:36.44 | putnopvut | leifmadsen: Hi! |
| 13:36.51 | leifmadsen | putnopvut: so I'm getting ready to release 1.4.26-rc4 -- which were the changes that I should focus on in the release announcement? |
| 13:37.00 | leifmadsen | (it is ready for signing, fyi) |
| 13:37.09 | leifmadsen | putnopvut: sorry to pounce on you :) |
| 13:37.13 | putnopvut | Big one is probably the SIP fix I committed two days ago. Let me find the rev... |
| 13:37.53 | leifmadsen | the 487 and SDP loop? |
| 13:37.57 | putnopvut | leifmadsen: rev 202336 of 1.4 |
| 13:38.04 | leifmadsen | got it |
| 13:38.11 | putnopvut | Yeah, the SDP loop in particular |
| 13:38.17 | putnopvut | the 487 thing is a much smaller thing. |
| 13:38.22 | leifmadsen | ok, thanks! |
| 13:38.23 | putnopvut | thing thing thing |
| 13:38.30 | leifmadsen | thong. |
| 13:38.35 | *** join/#asterisk-dev kannan (n=kannan@121.246.242.95) |
| 13:40.06 | kannan | hello, can anyone point to me to example code on howto poll for originateresponse event using phpagi-asmanager? i am using this API to originate calls, but want to get the result of an originate action |
| 14:16.58 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:16.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:17.12 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:17.12 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:21.46 | *** join/#asterisk-dev kaldemar (n=kalde@vipunen.hut.fi) |
| 14:22.13 | kaldemar | hello |
| 14:23.40 | kaldemar | following came up in #asterisk: app documentation for Dial() option U() suggests that gosub calls "routine" x and arguments are delimited with ^. instead, x is a context and it calls for extension s and priority 1 in it, and arguments are delimited with a comma. |
| 14:25.30 | kaldemar | couldn't find an issue in issues.asterisk.org for that. would that inconsistency between documentation, functionality and GoSub already be noted somewhere? |
| 14:29.52 | *** join/#asterisk-dev moy (n=moy@74.12.123.90) |
| 14:41.30 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 14:41.40 | *** join/#asterisk-dev xpot-mobile (n=james@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 14:43.44 | leifmadsen | kaldemar: open an issue, and then I'll take a look at it |
| 14:43.50 | leifmadsen | probably a copy/paste error |
| 14:46.39 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:47.04 | kaldemar | a mere documentation error would be tolerable, but the gosub is not called in the same manner as the app, and that is a bit worse i think. i'll open an issue. |
| 14:50.28 | *** part/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:57.28 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:57.28 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:03.04 | kaldemar | leifmadsen: https://issues.asterisk.org/view.php?id=15390 |
| 15:03.18 | *** join/#asterisk-dev oej (n=olle@170.Red-88-2-166.staticIP.rima-tde.net) |
| 15:03.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:10.06 | *** join/#asterisk-dev oej_ (n=olle@240.Red-83-33-40.dynamicIP.rima-tde.net) |
| 15:18.07 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:18.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:29.50 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:29.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:30.16 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 15:31.47 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.97) |
| 15:48.41 | tzafrir_laptop | sruffell, I'd like to see how to merge the sysfs branch of dahdi |
| 15:49.03 | tzafrir_laptop | one chunk of code there is all of those debugging macros |
| 15:49.29 | sruffell | tzafrir_laptop: could you give me another couple of days to go through it one more time (assuming it's resynced with the trunk) before doing so? |
| 15:49.49 | tzafrir_laptop | It is automerged and should be synced |
| 15:50.19 | sruffell | ok...cool...I'll go through it one more time. Is there a mantis issue for it? |
| 15:51.20 | sruffell | I will say however, that I'm excited to get that merged in...I have information to export that I was waiting until after your branch is merged. |
| 15:51.36 | sruffell | rather..to see that merged in. |
| 15:55.31 | tzafrir_laptop | I guess https://issues.asterisk.org/view.php?id=7613 |
| 16:03.10 | tzafrir_laptop | BTW: I reported an issues with OSLEC and DAHDI on Monday |
| 16:03.46 | tzafrir_laptop | So just to correct the data point: it turned out that it is not a regression from Zaptel to DAHDI. Zaptel and DAHDI do behave the same |
| 16:04.51 | seanbright | mnicholson: "Philip"? |
| 16:05.03 | seanbright | mnicholson: ignore me. |
| 16:05.08 | seanbright | putnopvut: "Philip"? |
| 16:05.10 | seanbright | (heh) |
| 16:05.38 | putnopvut | seanbright: yeah, that's not his name. |
| 16:06.02 | seanbright | i got that |
| 16:06.04 | seanbright | what is his name? |
| 16:06.09 | seanbright | falves? |
| 16:06.14 | putnopvut | seanbright: yes |
| 16:06.16 | seanbright | ahhh |
| 16:07.11 | russellb | i think he had the record for most negative karma before negative karma was abolished |
| 16:07.23 | seanbright | still pissed we got rid of it |
| 16:07.26 | russellb | certainly the highest rate of descent in karma value |
| 16:07.28 | seanbright | we're too easy on the community |
| 16:07.31 | seanbright | they need to be punished |
| 16:07.42 | leifmadsen | so, I want to bring this up again, because I'm working on a text/documentation issue with the Dial() app, and I'm wondering.... would it be a really "bad thing(tm)" for us just to backport the astxml stuff to 1.6.0 and 1.6.1 so that we don't have to come up with crazy commit methods whenever we want to update the docs? |
| 16:07.43 | russellb | hey man, whatever you're in to... |
| 16:08.02 | russellb | leifmadsen: that would be a huge job, so no |
| 16:08.10 | leifmadsen | it would? darn |
| 16:08.11 | russellb | just leave the docs in those releases how they are |
| 16:08.18 | russellb | and make things better for 1.6.2 and beyond |
| 16:08.43 | leifmadsen | well, if the docs are updated (the text itself) it needs to be updated in the other releases |
| 16:09.09 | leifmadsen | it's just a major pain when committing since you have to create different patches for the two methods. Oh well, since it isn't trivial to backport, I guess we have no option |
| 16:09.51 | russellb | understood |
| 16:10.08 | russellb | backporting the code itself is a sizable task ... |
| 16:10.21 | russellb | checking _ALL_ docs to ensure we don't accidentally merge docs for a feature that doesn't exist in that version ... ugh |
| 16:10.35 | russellb | and aside from all of that, it violates the release policy :-) |
| 16:10.43 | putnopvut | Luckily, doc changes don't happen all that often. |
| 16:10.44 | leifmadsen | well ya, but we've violated it before :) |
| 16:11.05 | seanbright | because no one writes any |
| 16:11.05 | eliel | hides |
| 16:11.13 | eliel | he |
| 16:11.13 | putnopvut | especially doc changes that affect all versions. |
| 16:11.13 | seanbright | :) |
| 16:11.36 | russellb | eliel: you've got enough work to do already! |
| 16:11.42 | russellb | don't even think about it! |
| 16:11.43 | russellb | hehe |
| 16:12.16 | eliel | russellb: no! i wasn't! |
| 16:12.27 | eliel | i know my priorities :) |
| 16:12.40 | leifmadsen | lunch |
| 16:13.49 | seanbright | hmmm |
| 16:13.50 | seanbright | http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/ChangeLog-2.2.0+2.2.0 |
| 16:13.55 | seanbright | we may want to rethink how that is generated |
| 16:14.18 | russellb | heh |
| 16:14.28 | russellb | well, presumably if you download/untar that, you'll have changelogs within linux and tools |
| 16:15.14 | seanbright | you are correct. |
| 16:16.05 | russellb | So, adding a note in there to say, See linux/tools ChangeLog for more info, would be good i suppose |
| 16:19.09 | seanbright | ohhh |
| 16:19.14 | seanbright | tc400b just got here |
| 16:19.33 | seanbright | pretty light considering the $1400 |
| 16:19.39 | seanbright | ok, i've decided: |
| 16:19.55 | seanbright | if you have commit access, you get the employee discount |
| 16:20.01 | seanbright | tell your people |
| 16:20.06 | file | the price of the card should determine the size of it? |
| 16:20.12 | seanbright | no |
| 16:20.16 | seanbright | i was being funny, file. |
| 16:20.24 | file | you? funny? never. |
| 16:20.24 | seanbright | and clearly failing. |
| 16:21.20 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 16:26.41 | ctooley | seanbright, I concur with that statement about employee discounts, but only for personal use products, ie: not for my consulting customers or my full time gig. |
| 16:28.18 | russellb | that sounds great to me, but I'm not in sales :-) |
| 16:30.12 | *** join/#asterisk-dev thansen (n=thansen@c-24-10-236-153.hsd1.ut.comcast.net) |
| 16:30.59 | ctooley | seanbright, I'm assuming there might actually be said discount though. :-) |
| 16:50.37 | leifmadsen | russellb: are we in agreement that 14849 should be pushed to 1.6.0.12? |
| 16:50.40 | leifmadsen | M14849 |
| 16:50.47 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/T.38 0014849: [patch] SendFax function not working as expected on > 1.6.0.7 reported by afosorio (Karma: neutral) https://issues.asterisk.org/view.php?id=14849 |
| 16:55.18 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 16:55.18 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 16:56.45 | putnopvut | <PROTECTED> |
| 16:56.47 | putnopvut | dammit |
| 16:59.29 | leifmadsen | putnopvut: :) |
| 17:14.50 | *** join/#asterisk-dev davevg (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 17:19.17 | *** join/#asterisk-dev xpot-mobile (n=james@144.35.21.88) |
| 17:19.32 | seanbright | ctooley: right, for assisting in the development effort. |
| 17:29.11 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 17:50.55 | *** join/#asterisk-dev salzh (n=Administ@122.144.138.5) |
| 18:09.01 | russellb | leifmadsen: yeah, pushed until someone can get to it |
| 18:09.21 | leifmadsen | russellb: ok cool |
| 18:11.19 | leifmadsen | russellb: I may build 1.6.0.11-rc1 today then, pending anything you can think of that would cause me to not do that :) |
| 18:11.52 | russellb | sounds good |
| 18:25.09 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 18:27.27 | *** join/#asterisk-dev thansen (n=thansen@c-24-10-236-153.hsd1.ut.comcast.net) |
| 18:28.46 | *** join/#asterisk-dev salzh (n=Administ@122.144.138.5) |
| 18:32.48 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:51.04 | mnicholson | russellb, ok testing with chan_sip, everything seems to work properly, including bxfer and atxfer |
| 18:51.20 | mnicholson | russellb, i tested every backend except radius and tds |
| 18:51.26 | kpfleming | leifmadsen: what are we thinking regarding 1.6.2 moving from -beta to -rc? |
| 18:51.47 | leifmadsen | kpfleming: I am thinking I'd like to do that soon(ish) |
| 18:51.48 | mnicholson | russellb, there appears to be a problem with '#' transfer, in tha the proper transfer events don't get logged |
| 18:52.10 | mnicholson | linkedids are correct though |
| 18:52.10 | kpfleming | ok, once 1.6.2 reaches -rc stage, we'll have to review all our binary addons to see if 1.6.2-specific releases need to be made |
| 18:52.13 | leifmadsen | kpfleming: I am currently going through the issues in the tracker to see if there is anything additionally major that needs to go in |
| 18:52.19 | kpfleming | alright |
| 18:52.47 | leifmadsen | kpfleming: I only have 15363 and 8855 on the list |
| 18:53.03 | leifmadsen | 8855 could potentially be deferred to 1.6.2.1 if someone says so |
| 18:53.11 | leifmadsen | (or some future -rc release) |
| 18:53.25 | russellb | M8855 |
| 18:53.28 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/General 0008855: nat=no is not RFC 3261 compliant regarding sending responses reported by mikma (Karma: +19.75) https://issues.asterisk.org/view.php?id=8855 |
| 18:53.50 | russellb | I don't think that's a blocker since it's not a regression specific to that version |
| 18:53.54 | russellb | M15363 |
| 18:53.56 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0015363: 1.6.2.0_beta3 locks up in certain SIP scenario reported by klaus3000 (Karma: +21.50) https://issues.asterisk.org/view.php?id=15363 |
| 18:54.10 | russellb | that's something we should definitely figure before the final release ... |
| 18:56.22 | leifmadsen | russellb: okie -- I just removed 8855 from the roadmap page entirely (for now) -- I think 15363 is the only thing that would block a 1.6.2.0-beta4, and if no other blockers come up, we can do an RC |
| 18:56.31 | leifmadsen | that's my thinking anyways |
| 18:59.13 | leifmadsen | and looked through all the other issues -- that is the only one that is blocker |
| 18:59.21 | leifmadsen | s/blocker/blocking |
| 19:00.11 | mnicholson | CEL question, when should bridge start and end event's be generated? Should a caller pressing # for a transfer generate bridge start/end events? |
| 19:03.45 | *** join/#asterisk-dev fernando (n=fernando@189.88.64.36) |
| 19:04.42 | *** join/#asterisk-dev kn0x (n=pinochle@67.159.48.101) |
| 19:04.58 | kn0x | hey anyone know how the SIP channel ID is generated |
| 19:05.06 | kn0x | err channel name |
| 19:05.28 | kn0x | <PROTECTED> |
| 19:05.42 | kn0x | where is this hexadecimal number coming frmom |
| 19:05.58 | mnicholson | CEL question: should transferring to the parking extension generate a TRANSFER event in addition to a PARK event? |
| 19:06.45 | kn0x | I was thinking it was unique, but I'm getting tghat same channel name reused |
| 19:13.50 | putnopvut | kn0x: I think it's generated using the address of sip_pvt pointer associated with the channel. |
| 19:14.09 | putnopvut | It's unique during the time it exists, but it's certainly possible for the name to be re-used over time. |
| 19:15.56 | kn0x | putnopvut: okay. |
| 19:16.16 | kn0x | Any idea how I could get something unique to go in my debug logs? |
| 19:16.48 | putnopvut | kn0x: you could modify the code to use the current time (with something like microsecond resolution) instead of an address. |
| 19:16.59 | kn0x | sip.c that is? |
| 19:17.13 | kn0x | chan_sip.c? |
| 19:17.48 | putnopvut | correct. |
| 19:17.54 | kn0x | my next problem is with logger.c, it doesn't include the channel name on each line |
| 19:17.57 | putnopvut | Specifically, the sip_new function. |
| 19:18.06 | kn0x | putnopvut: okay, cook |
| 19:18.12 | putnopvut | cooks a steak |
| 19:19.46 | Qwell | kn0x: JunK-Y is working on something to allow filtering logs by channel. |
| 19:20.09 | kn0x | interesting, |
| 19:22.01 | kn0x | JunK-Y: you around? |
| 19:25.03 | putnopvut | kn0x: It's a holiday in Quebec today, so JunK-Y may be out having fun today :) |
| 19:26.45 | kn0x | haha, oh |
| 19:26.50 | kn0x | what holiday? |
| 19:28.58 | kn0x | putnopvut: any idea what porperty of sip_pvt its using? |
| 19:29.52 | putnopvut | Oh, it's st jean-baptiste in quebec today. What property are you talking about? You mean for the channel name? It just uses the address of the sip_pvt pointer passed to sip_new. |
| 19:30.22 | kn0x | const char *my_name; |
| 19:30.34 | kn0x | my_name = ast_strdupa(i->fromdomain); |
| 19:30.39 | kn0x | this here? |
| 19:31.38 | kn0x | I'm sorry for my ignorance. I knew a little C++, but I really only work with PHP :| this is way over my head |
| 19:32.06 | kn0x | const char *my_name; is a c-string? |
| 19:32.22 | kn0x | is the * indicating an array |
| 19:32.46 | putnopvut | The * indicates it's a pointer. |
| 19:33.20 | putnopvut | But a char * can be thought of as a string. |
| 19:33.38 | kn0x | ahh |
| 19:33.45 | kn0x | whoa i think i found it ! |
| 19:33.47 | kn0x | ast_channel_alloc(1, state, i->cid_num, i->cid_name, i->accountcode, i->exten, i->context, i->amaflags, "SIP/%s-%08x", my_name, (int)(long) i); |
| 19:34.49 | putnopvut | Yeah, that (int) (long) i at the end is what you'd need to change. |
| 19:34.51 | kn0x | where is %s formated? |
| 19:34.59 | kn0x | oh ok |
| 19:35.01 | kn0x | so |
| 19:35.17 | kn0x | because they are converting pointer i to an long integer? |
| 19:35.21 | kn0x | casting |
| 19:35.22 | kn0x | ? |
| 19:35.35 | putnopvut | Yeah, first it is converted to a long because that is safe on all systems. |
| 19:35.45 | putnopvut | Since a long is defined to be the width of a pointer. |
| 19:35.56 | putnopvut | Then the long is converted to an int since that can be safely done. |
| 19:37.20 | kn0x | cool. |
| 19:38.02 | kn0x | so will this break anything? |
| 19:38.36 | kn0x | so what is %08x |
| 19:38.45 | kn0x | "SIP/%s-%08x" |
| 19:40.49 | putnopvut | Are you familiar with printf-style formatting? |
| 19:40.58 | kn0x | for php, yes |
| 19:41.07 | kn0x | but I dont see the prinf call |
| 19:41.33 | kn0x | I just see this all being passed to ast_channel_allow |
| 19:41.36 | kn0x | *alloc |
| 19:41.47 | putnopvut | Right, but the syntax is the same as for printf, though. |
| 19:42.21 | putnopvut | So the quoted portion is a format argument. The first argument after corresponds to the %s and is a string. |
| 19:42.45 | putnopvut | %08x means a zero-padded eight-digit-width hexadecimal number. |
| 19:43.01 | putnopvut | And that is where the (int) (long) i is placed. |
| 19:45.01 | kn0x | so I could just replace (int) (long) xtm |
| 19:45.32 | putnopvut | What is xtm? |
| 19:46.21 | kn0x | but define: long int xtm = st_ctimensec(); |
| 19:46.44 | kn0x | im not sure if I have the right timestamp funtion |
| 19:47.30 | putnopvut | I've never seen that one. |
| 19:47.35 | kn0x | what would you use? |
| 19:48.04 | putnopvut | There is a function called ast_tv_now() that you can use. It returns a struct timeval. You can use the tv_usec field of the timeval returned. |
| 19:48.19 | putnopvut | sorry, it's ast_tvnow(), not ast_tv_now() |
| 19:49.36 | kn0x | oh boy |
| 19:49.47 | kn0x | im not sure on these structures |
| 19:49.57 | kn0x | this is like an object? |
| 19:50.26 | putnopvut | I suppose you can think of it that way, but it's a much more basic thing. |
| 19:50.34 | kn0x | like array? |
| 19:50.43 | putnopvut | Not really. |
| 19:50.49 | putnopvut | suggests reading up on C some :) |
| 19:51.14 | kn0x | I will. but I gues all i need to know for know is how to populate my xtm variable :) |
| 19:51.52 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 19:51.52 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:51.55 | kn0x | long int xtm = a->tv_usec |
| 19:52.07 | kn0x | long int xtm = ast_tvnow->tv_usec |
| 19:52.59 | putnopvut | kn0x: just a sec... |
| 19:53.10 | putnopvut | kn0x: http://pastebin.ca/1473117 |
| 19:53.20 | putnopvut | actually...that won't work. |
| 19:53.26 | kn0x | :\ |
| 19:53.53 | kn0x | whats wrong with that? |
| 19:54.07 | putnopvut | kn0x: http://pastebin.ca/1473119 |
| 19:54.20 | putnopvut | The problem was that just grabbing the microseconds does not guarantee uniqueness. |
| 19:54.29 | putnopvut | You need to have both the seconds and microseconds in the name. |
| 19:54.37 | kn0x | oh |
| 19:54.50 | putnopvut | Your SIP channels will have some really long names if you do that, but I don't think that's really a bad thing. |
| 19:55.29 | jameswf | I m going to see if I can make a TDM card do jingle bells via its ringer... |
| 19:55.40 | putnopvut | lol |
| 19:55.42 | putnopvut | good luck :) |
| 19:56.33 | kn0x | haha |
| 19:56.35 | kn0x | jameswf: |
| 19:56.36 | seanbright | is rmudgett on the IRC? |
| 19:57.48 | jameswf | filed under projects not to show your boss/// IS THIS WHAT I AM PAYING YOU FOR.... maybe :) |
| 19:58.46 | putnopvut | seanbright: not typically. |
| 19:59.24 | kn0x | putnopvut: can you think of a time this long string will be a problem? |
| 19:59.46 | putnopvut | kn0x: I can't. The only thing is that it just may look "ugly" |
| 20:00.18 | kn0x | I could setprecision on usecs tho, right? |
| 20:00.39 | kn0x | or even convert to hex |
| 20:00.54 | putnopvut | kn0x: Sure, you can do that if you'd like. |
| 20:00.59 | putnopvut | It's all software :) |
| 20:01.25 | kn0x | any function for calculating hex value? |
| 20:02.10 | putnopvut | nope |
| 20:05.48 | kn0x | or cant i do %x.32 for a 32-digit hex value? |
| 20:06.08 | kn0x | well really only %x.10 |
| 20:09.27 | putnopvut | %x.10 would force the printed value to show at least 10 digits, I believe. |
| 20:11.56 | kn0x | but it would truncate, correct? |
| 20:17.30 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.214) |
| 20:20.07 | putnopvut | I believe so. |
| 20:20.56 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 20:26.31 | mnicholson | hmm, asterisk froze then crashed after doing 'core restart now' with a sip call bridged |
| 20:27.03 | mnicholson | cel bug |
| 20:30.14 | seanbright | file: time for a question? |
| 20:30.20 | seanbright | file: REFER related |
| 20:30.23 | file | seanbright: ask! |
| 20:30.31 | seanbright | ok, we are testing SIP REFER with our provider |
| 20:30.47 | seanbright | we send them a REFER, followed by a BYE (Transfer app) |
| 20:30.58 | file | oh... the Transfer app |
| 20:31.20 | seanbright | we get back a 202 Accepted (for the REFER) and a 200 for the BYE |
| 20:31.30 | seanbright | but for some reason, asterisk keeps retransmitting the REFER |
| 20:32.09 | file | kick it. |
| 20:32.12 | putnopvut | oh crap that sounds familiar. |
| 20:32.22 | seanbright | super... |
| 20:32.25 | putnopvut | Are the REFER and BYE on the same dialog? |
| 20:32.54 | file | I defer to putnopvut |
| 20:33.02 | seanbright | dialog == call id? |
| 20:33.16 | putnopvut | call-id is good enough. If they're the same, then yes. |
| 20:33.19 | seanbright | yes |
| 20:33.21 | seanbright | then yes. |
| 20:33.29 | putnopvut | Okay, so here's what's happening. |
| 20:33.38 | putnopvut | Asterisk sends two requests, the REFER and the BYE. |
| 20:33.53 | putnopvut | It keeps track of the last outgoing CSeq number used. |
| 20:33.57 | putnopvut | Which is for the BYE. |
| 20:34.17 | mnicholson | deadlock :( |
| 20:34.29 | putnopvut | When the response to the REFER comes in, Asterisk sees that the CSeq for the 202 Accepted is less than the stored outgoing CSeq. |
| 20:34.35 | putnopvut | So Asterisk ignores the response. |
| 20:34.43 | kpfleming | i don't think Transfer() is supposed to be used for calls that have already been answered |
| 20:34.53 | kpfleming | at least, i've never seen it successfully used that way |
| 20:34.54 | putnopvut | Because it ignored the response, it did not cancel retransmission of the REFER. |
| 20:35.17 | putnopvut | So the REFER is retransmitted and the incoming 202 Accepted is continually ignored. |
| 20:35.29 | putnopvut | Until we have retransmitted the max number of times. |
| 20:35.39 | file | you might be able to call Wait after Transfer if Transfer doesn't stop pbx execution |
| 20:35.55 | kpfleming | file: cheeky |
| 20:36.13 | file | so that way you can let that transaction play out, and then have the BYE sent |
| 20:36.24 | putnopvut | file: sneaky |
| 20:47.17 | seanbright | file: that worked |
| 20:47.22 | seanbright | strangely enough |
| 20:48.20 | file | I'm rather curious that your provider is letting you do that |
| 20:48.26 | seanbright | do what? |
| 20:48.35 | file | send a REFER |
| 20:48.48 | seanbright | why's that? |
| 20:49.07 | file | shrugs |
| 20:49.32 | file | nothingggggg |
| 20:49.41 | file | Qwell: IT'S THE SMOKE! |
| 20:49.52 | Qwell | THE SMOOooOOooOOOOOKEE! |
| 20:50.02 | putnopvut | I won't ask |
| 20:50.04 | russellb | O.O |
| 20:50.39 | Qwell | http://www.youtube.com/watch?v=3eooXNd0heM |
| 20:51.16 | putnopvut | autotune is the worst invention ever. |
| 20:51.24 | seanbright | ok... so short of Wait()ing after Transfer() |
| 20:51.27 | Qwell | Then you sir, haven't seen autotune the news. |
| 20:51.31 | seanbright | what would the fix be? |
| 20:52.53 | seanbright | sip transaction support |
| 20:52.59 | putnopvut | That'd do it. |
| 20:53.12 | seanbright | short of that...? |
| 20:54.14 | putnopvut | In other cases where we need to keep track of specific CSeq numbers, we've just added them to the sip_pvt. |
| 20:54.23 | putnopvut | see lastinvite, glareinvite, pendinginvite, etc. |
| 20:54.32 | seanbright | okie |
| 20:54.33 | seanbright | thanks |
| 20:54.34 | putnopvut | But man is that hacky |
| 20:54.48 | file | I think I made it so that in trunk Transfer() blocks |
| 20:55.08 | seanbright | i can't run trunk |
| 20:55.08 | seanbright | :-/ |
| 20:55.08 | file | so that the result is actually useful |
| 20:55.08 | putnopvut | But you could backport that change. |
| 20:55.12 | seanbright | that is true |
| 20:55.18 | putnopvut | You have the smarts! |
| 20:55.19 | file | or just use Wait. |
| 20:55.25 | putnopvut | file: you're no fun |
| 20:55.45 | file | putnopvut: is it Friday yet? |
| 20:56.10 | leifmadsen | file: you've been asking that since Monday! :) |
| 20:56.26 | file | leifmadsen: well, yes |
| 20:56.28 | putnopvut | file: I already answered that on facebook |
| 20:57.45 | jsmith | file: Don't you think we need an autotune dialplan function? |
| 20:58.36 | file | jsmith: I told Qwell that! |
| 20:58.51 | putnopvut | jsmith: JACK_HOOK |
| 21:00.30 | jsmith | putnopvut: Yeah... if only JACK were more intuitive... |
| 21:01.08 | seanbright | file: is REFER bad? anymore than 2BCT? your initial reaction worried me |
| 21:01.17 | file | well, no |
| 21:01.38 | file | you are just the first person to use it like that that I know of |
| 21:01.53 | seanbright | really? that is scary as hell |
| 21:07.09 | seanbright | kpfleming: re: "i don't think Transfer() is supposed to be used for calls that have already been answered" |
| 21:07.28 | seanbright | there is code in chan_sip (sip_transfer) that says "if we're ringing, send a 302, otherwise a refer" |
| 21:07.35 | kpfleming | yeah, i know |
| 21:07.47 | kpfleming | i've just never seen anyone actually do that, and wouldn't have expected it to work :-) |
| 21:07.52 | seanbright | heh |
| 21:08.12 | seanbright | well it does :) assuming i Wait() after Transfer() |
| 21:08.16 | seanbright | powernet global |
| 21:08.30 | seanbright | using a veraz control switch |
| 21:08.38 | seanbright | whatever the hell that is |
| 21:10.39 | kpfleming | it's a fancy and expensive product that is quite good |
| 21:14.36 | jsmith | seanbright: For what it's worth, I've used Transfer() like that... but only once |
| 21:14.56 | jsmith | seanbright: You're figuring out all my secrets! |
| 21:20.35 | seanbright | well we got REFER to work, but redirects are hosed |
| 21:20.40 | seanbright | they just keep looping back |
| 21:20.55 | seanbright | and all i care about are the 302s really, i don't expect to use refer in production |
| 21:27.51 | seanbright | jsmith-away: happy to be learning from the master |
| 21:41.34 | tzafrir_laptop | M15391 |
| 21:41.36 | MuffinMan | [assigned] [DAHDI-tools] General 0015391: Configuration directive --prefix=/usr fails to apply to menuselect subdirectory reported by Hendrik Schaink (Karma: neutral) https://issues.asterisk.org/view.php?id=15391 |
| 21:42.25 | tzafrir_laptop | Qwell, the patch I apply is useful for Debian packaging. but not for debian installation-from-source |
| 21:43.36 | tzafrir_laptop | And frankly I don't understand why he made that change |
| 21:51.16 | mnicholson | ewww, if asterisk is shutdown while a call is up, no cel events are generated for the end of that call and asterisk crashes (two mostly unrelated things) |
| 22:15.50 | JunK-Y | kn0x: im there now |
| 22:17.19 | Qwell | tzafrir_laptop: I would say close then |
| 22:18.04 | tzafrir_laptop | I'll wait for him a day or so to give some rationale before that, though |
| 22:53.44 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 23:08.01 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 23:17.23 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:33.08 | *** join/#asterisk-dev xpot-mobile (n=james@144.35.21.88) |