| 00:10.24 | *** join/#asterisk-dev Jacke (jacke@212.180.164.196) |
| 00:35.49 | *** join/#asterisk-dev ecrane (~ecrane@o1-69-19-166-10.static.o1.com) |
| 00:39.12 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:39.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 00:57.29 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:57.29 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 01:00.03 | *** join/#asterisk-dev mbranca (~matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 01:08.22 | *** join/#asterisk-dev lmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:08.22 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 01:51.08 | *** part/#asterisk-dev korihor (~korihor@190.205.251.97) |
| 03:00.29 | *** join/#asterisk-dev snuff-work (~aaa@120.17.114.209) |
| 03:00.30 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:14.47 | mvanbaak | mornin |
| 05:15.14 | mvanbaak | for those working on the autoconf shizzle in asterisk: http://undeadly.org/cgi?action=article&sid=20100310215559&mode=expanded |
| 05:17.20 | snuff-work | heh |
| 06:29.21 | *** join/#asterisk-dev JT (~j@unaffiliated/jt) |
| 07:03.39 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:03.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:05.47 | tzafrir_laptop | mvanbaak, autoconf provides tests because people use them |
| 07:05.59 | tzafrir_laptop | For instance, asterisk requires gnu make |
| 07:06.23 | tzafrir_laptop | this is because of using home-brewed makefiles rather than using gnu automake |
| 07:07.33 | tzafrir_laptop | Can you give a specific example where the asterisk autoconf script checks for a gnu version where it does not need to? |
| 07:09.02 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 07:09.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:09.29 | *** join/#asterisk-dev alecdavis (~alec@202-78-149-14.cable.telstraclear.net) |
| 08:09.59 | alecdavis | just got "[Bamboo] Asterisk - trunk - OpenBSD build 19 has FAILED. Change made by Alec Davis" |
| 08:10.37 | alecdavis | it appears menuselect.makeopts need to be deleted. |
| 08:11.10 | alecdavis | how does a commit to trunk cause this error? |
| 08:18.32 | *** join/#asterisk-dev Gugge (~gugge@vlan2.dlxhosting.dk) |
| 08:18.32 | *** join/#asterisk-dev felipe_ (~felipe@my.nada.kth.se) |
| 08:26.32 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:29.54 | alecdavis | relief! OPENBSD trunk build was failing before I commited :) |
| 08:43.39 | *** part/#asterisk-dev alecdavis (~alec@202-78-149-14.cable.telstraclear.net) |
| 08:47.06 | tzafrir_laptop | "menuselect.makeopts needs to be deleted", oh nice. See the option LIVE_AST_FORCE_DEF_CONF of live_ast |
| 08:47.18 | tzafrir_laptop | (contrib/scripts/live_ast) |
| 09:13.23 | *** join/#asterisk-dev sgimeno (~chatzilla@226.Red-80-33-64.staticIP.rima-tde.net) |
| 09:14.36 | *** join/#asterisk-dev TommyBotten (tommy@broken.pipe.no) |
| 09:21.41 | TommyBotten | Is the 1.6.2.6 release far away? Are there some parts that could use extra testing? |
| 09:51.34 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-155-51.cinci.res.rr.com) |
| 10:12.21 | *** join/#asterisk-dev pyite (~dschreibe@unaffiliated/pyite) |
| 10:53.35 | *** join/#asterisk-dev mono000333 (~mono00033@host-50.GROUPB.212.5.107.48.0xfffffff0.macomnet.net) |
| 10:53.49 | *** part/#asterisk-dev mono000333 (~mono00033@host-50.GROUPB.212.5.107.48.0xfffffff0.macomnet.net) |
| 10:55.23 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 11:46.11 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 12:15.18 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:16.46 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:16.46 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:07.46 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 13:37.06 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 13:49.01 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 13:50.40 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@c-68-34-116-180.hsd1.md.comcast.net) |
| 13:57.15 | jmls | ok, what's happening ? |
| 13:57.30 | jmls | Just tried joining -users, got The topic for #asterisk-users is: Welcome to Asterisk-Users || http://www.asterisk.org |
| 13:57.40 | jmls | but there is *no-one* in the room ... |
| 13:58.15 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:58.39 | jmls | do all channels have the "c" option like chan_zap ? |
| 13:58.48 | jmls | on the dial string, that is .. |
| 14:04.24 | *** join/#asterisk-dev niekvlessert (~niek@92.70.112.34) |
| 14:04.42 | niekvlessert | hello! what is the way to go if i want keepstats=yes in 1.4 |
| 14:04.44 | niekvlessert | ? |
| 14:05.14 | file | jmls: umm it's #asterisk |
| 14:05.57 | file | jmls: and nope. |
| 14:06.08 | niekvlessert | yeah well, i know 1.4 does not support keepstats |
| 14:06.18 | file | niekvlessert: if it's not in 1.4 then you backport it yourself, find a patch floating around, or pay someone to backport it |
| 14:06.25 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:06.25 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:06.31 | niekvlessert | i'm willing to pay someone, who can do this? |
| 14:06.42 | niekvlessert | couldn't find any patches? |
| 14:06.47 | file | the asterisk-biz mailing list would be the place to ask that |
| 14:08.55 | niekvlessert | aha this one is new for me, thanks |
| 14:18.04 | *** join/#asterisk-dev hugorebelo (~hugo@200-171-132-124.completo.com.br) |
| 14:19.35 | *** join/#asterisk-dev zerohalo (~zerohalo@173-13-92-17-NewEngland.hfc.comcastbusiness.net) |
| 14:26.39 | tzafrir_laptop | any idea who's op at #asterisk-users? to change the topic to redirect to #asterisk ? |
| 14:35.10 | *** join/#asterisk-dev Corydon76-dig (two@c-69-137-80-31.hsd1.tn.comcast.net) |
| 14:35.10 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 14:44.27 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:44.27 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:53.21 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 15:11.21 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:11.21 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:16.07 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:16.07 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:18.06 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-riyrgojexyfzmxxu) |
| 15:19.44 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@c-68-34-116-180.hsd1.md.comcast.net) |
| 15:26.40 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 15:40.44 | *** join/#asterisk-dev ManxPower-work (~manxpower@216.186.151.147) |
| 15:41.05 | ManxPower-work | can anyone think of a reason that Asterisk would send an empty SDP when doing a transfer? |
| 15:41.27 | kpfleming | no |
| 15:41.38 | kpfleming | afaik, asterisk will never send an empty SDP |
| 15:41.41 | ManxPower-work | want a wireshark capture showing it. |
| 15:42.09 | kpfleming | no, that only proves it happened, it doesn't provide any context as to how it may have occurred |
| 15:42.41 | *** join/#asterisk-dev codefreeze-lap (~murf@mail.parsetree.com) |
| 15:42.41 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 15:43.07 | ManxPower-work | we have a capture of a single call start to finish |
| 15:43.20 | kpfleming | with a console capture include maximum debug, verbose and 'sip set debug'? |
| 15:43.25 | ManxPower-work | ah, only one leg, however. |
| 15:44.08 | ManxPower-work | I'll spend the hour or so to tease out the data from all the other crap going on in the system and see if I can get it for you. |
| 15:44.31 | kpfleming | not for me specifically... but that's what would be required to have any chance to figure out how that result occurred |
| 15:44.35 | ManxPower-work | I see we are at am impass. |
| 15:44.43 | ManxPower-work | Thank you for your ideas. |
| 15:44.55 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:44.55 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:45.09 | ManxPower-work | I wish this stuff would not happen on servers that handle 1,000+ calls a day. |
| 15:45.16 | kpfleming | agreed |
| 15:45.29 | ManxPower-work | I guess we'll try reverting. |
| 15:45.56 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:45.57 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:58.42 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:07.17 | leifmadsen | seanbright: did that HD version of the swarm get updated? |
| 16:12.05 | seanbright | leifmadsen: yessir |
| 16:12.14 | seanbright | i agree with putnopvut though. needs music. |
| 16:12.23 | leifmadsen | seanbright: have a link to the HD version? |
| 16:12.33 | leifmadsen | yes, some sort of music would be cool :) |
| 16:12.43 | seanbright | same as the old link. just need to switch the res. hold on |
| 16:14.15 | seanbright | http://www.youtube.com/watch?v=5EdZMcxa3Rk |
| 16:14.31 | leifmadsen | seanbright: ya, I just didn't have the old link :) |
| 16:15.13 | seanbright | its super awesome in 11/2005 |
| 16:15.25 | seanbright | when kpfleming changes like 30000 files at once |
| 16:15.36 | seanbright | that took a while to render |
| 16:16.12 | kpfleming | that's the CVS->Subversion migration |
| 16:16.51 | seanbright | the different colors are different sub folders |
| 16:16.58 | seanbright | res, channels, codecs, etc. |
| 16:16.59 | russellb | heh, when I rendered it, I hacked the source to not process that day |
| 16:17.25 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:20.34 | leifmadsen | It looks like a supernova :) |
| 16:20.56 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 16:26.06 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 16:26.56 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 16:36.11 | Kobaz | poor qwell |
| 16:36.19 | Qwell | O.o |
| 16:36.23 | Kobaz | he got my ael bug |
| 16:36.39 | Kobaz | i'm pasting, i'm pasting |
| 16:37.08 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@c-68-34-116-180.hsd1.md.comcast.net) |
| 16:44.10 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 16:50.53 | Kobaz | Qwell: okay, bug still exists in trunk |
| 16:57.14 | philipp64 | howdy all. I was looking at the sla.tex and a few other documents, and noticed that the context name itself often ends up appearing in examples where a template is used, and the unique parts of the context that can't be duplicated (i.e. the parts that change) are 90% of the time derived from the context itself. so what about letting templates do in-place expansion of the invoking context name? |
| 16:57.32 | *** part/#asterisk-dev ManxPower-work (~manxpower@216.186.151.147) |
| 16:58.00 | kpfleming | philipp64: i don't understand your proposal |
| 16:58.15 | philipp64 | wait... I'll find an example... |
| 16:59.09 | Kobaz | Qwell: allright, you got your logs for M16618 |
| 16:59.17 | Kobaz | time to go ski |
| 16:59.24 | Qwell | Kobaz: You still need to load res_config_odbc.. |
| 16:59.31 | philipp64 | kpfleming: ok, look at doc/tex/sla.tex ... |
| 16:59.44 | Qwell | (preload => res_odbc, load => res_config_odbc) |
| 16:59.52 | Qwell | actually, probably preload both |
| 17:00.00 | philipp64 | ... [station1](station) \n device=SIP/station1 as my example |
| 17:00.15 | kpfleming | ok |
| 17:00.18 | kpfleming | so i see your point |
| 17:00.42 | kpfleming | i don't think anyone would be opposed to some magic value that could be used to refer to the top-level context that is using the template |
| 17:00.46 | philipp64 | if in that example, we could add the line "device=SIP/${CONTEXT}" to station(!) then you could invoke the template with no addition lines. |
| 17:01.12 | philipp64 | ok, cool. |
| 17:01.14 | kpfleming | no, ${CONTEXT} would be a terrible choice, it already has a definition that people are used to |
| 17:01.43 | philipp64 | well, what about some magic sequence, like... ummm.... $! |
| 17:01.48 | Corydon76-dig | More likely a different expansion syntax, even, such as %(CONTEXT) |
| 17:02.04 | philipp64 | ok, whatever. I can code it up and see how much work it is. |
| 17:02.09 | Corydon76-dig | Otherwise, you have a conflict between expansion times |
| 17:02.12 | philipp64 | what else could we reasonable expand in place? |
| 17:02.20 | philipp64 | *reasonably |
| 17:02.35 | kpfleming | there isn't anything else |
| 17:02.50 | Kobaz | Qwell: i don't need to preload both for it to work |
| 17:02.58 | Corydon76-dig | %(TEMPLATE), perhaps |
| 17:03.04 | Qwell | Kobaz: Documentation says you do. |
| 17:03.06 | philipp64 | and that would be? |
| 17:03.10 | Qwell | (ie; you should be doing that) |
| 17:03.22 | kpfleming | no, it's not the name of the template |
| 17:03.33 | kpfleming | it's the name of the context that is using the template |
| 17:03.37 | Kobaz | Qwell: well res_config_odbc has a symbol error in trunk, so i can't load it anyway |
| 17:03.46 | Qwell | because it's loading before res_odbc |
| 17:03.59 | Kobaz | oh okay |
| 17:04.02 | Kobaz | so you want that log too? |
| 17:04.02 | Qwell | You can't count on module load order. You have to force it |
| 17:04.32 | philipp64 | Corydon76-dig: sorry, %(TEMPLATE) as an alternative to %(CONTEXT)? or do they represent different values? |
| 17:04.38 | Corydon76-dig | kpfleming: I'm thinking the template name might be useful in certain situations, too |
| 17:05.05 | kpfleming | i suppose it could be |
| 17:05.13 | philipp64 | Corydon76-dig: sure... like in multiple inheritance, for debugging. |
| 17:05.48 | Kobaz | Qwell: so putting that in modules.conf also works |
| 17:06.15 | Qwell | So now that it's correctly configured.. are you still seeing the bug? |
| 17:06.23 | Kobaz | oh |
| 17:06.27 | Corydon76-dig | In fact, I could see allowing certain dialplan functions to be used there, as well, as long as you preloaded them before configuration parsing took place |
| 17:06.42 | Kobaz | Qwell: i figured it was a bug since it works fine in earlier versions |
| 17:06.49 | kpfleming | Corydon76-dig: let's not get crazy |
| 17:06.53 | Qwell | No, earlier versions would have only worked "sometimes". |
| 17:06.55 | philipp64 | Corydon76-dig: is that a modularity violation? |
| 17:06.59 | Qwell | load order is non-deterministic |
| 17:07.04 | kpfleming | if you want a dynamic configuration, use #exec |
| 17:07.04 | Kobaz | yeah okay |
| 17:07.11 | Corydon76-dig | kpfleming: Well, %(SET(foo=bar)) might be helpful |
| 17:07.13 | Kobaz | so i guess this isn't a bug :P |
| 17:07.16 | Qwell | somebody correct me if I'm wrong.. |
| 17:07.43 | Corydon76-dig | Qwell: you are entirely correct. It's based upon directory entry order, if not explicitly set |
| 17:07.52 | philipp64 | kpfleming: I'll start with the context name, and see where that gets us... |
| 17:08.01 | Qwell | Kobaz: good with closing then? |
| 17:08.07 | *** join/#asterisk-dev Tim_Toady (~moi@77.49.114.31.dsl.dyn.forthnet.gr) |
| 17:08.13 | Kobaz | sure |
| 17:08.24 | Kobaz | Qwell: should this be added to the documentation i suppose? |
| 17:08.32 | Qwell | it's in the documetnation :p |
| 17:08.37 | Qwell | but spelled correctly. |
| 17:08.37 | Kobaz | oh really |
| 17:08.38 | Tim_Toady | i get this when try to compile from svn: error: âstruct dahdi_spaninfoâ has no member named âbpvcountâ what am i missing? |
| 17:10.24 | kpfleming | Tim_Toady: what are you compiling? you didn't tell us |
| 17:10.39 | Tim_Toady | asterisk 1.6.2 |
| 17:10.46 | Tim_Toady | svn |
| 17:11.00 | kpfleming | sounds like it is missing a guard to check for updated dahdi... but you can workaround it by updating dahdi first |
| 17:11.05 | philipp64 | say, question for all you telephony heads out there. how does purely digital SMS work in today's SS7 and ISDN networks? what's the standard? obviously you don't do FSK over a DS0 channel... |
| 17:11.16 | Tim_Toady | ok kpfleming let me try this |
| 17:11.20 | kpfleming | it's done on the SS7 network, or over IP |
| 17:11.35 | philipp64 | what's the relevant standard, I guess, is my question? |
| 17:11.38 | philipp64 | SNPP? |
| 17:11.39 | kpfleming | don't know |
| 17:12.24 | philipp64 | I was thinking that a resource to add google-talk like voicemail-to-texting functionality would be coooool. |
| 17:12.43 | kpfleming | google voice, you mean |
| 17:12.46 | kpfleming | google talk is jabber |
| 17:12.53 | philipp64 | um, yeah. google-* |
| 17:14.44 | philipp64 | I think I mentioned SMS 2-3 years ago, but a lot of people felt that tighter integration of text with Asterisk would not be a good thing. |
| 17:14.56 | philipp64 | or maybe I just misunderstood what they were saying. |
| 17:15.47 | kpfleming | asterisk is not well designed for lightweight messaging |
| 17:15.52 | kpfleming | it's session-based, not message-based |
| 17:15.53 | philipp64 | my iPhone has the option of replying by text saying "I'm on a call right now" to incoming calls if I'm busy... |
| 17:16.23 | philipp64 | ok... what about adding a dialplan resource that RPC's into another process? |
| 17:17.44 | *** join/#asterisk-dev murdock_ut (~chatzilla@mail.kimballequipment.com) |
| 17:19.52 | Tim_Toady | kpfleming updating dadhi did the trick, thx :) |
| 17:20.20 | datachomper | yay, go dahdi |
| 17:22.28 | kpfleming | Tim_Toady: please enter an issue on issues.asterisk.org. the changes in chan_dahdi that use those new features in dahdi itself should have been done in a way that allows it to be compiled against older dahdi versions if the user does not want to upgrade. |
| 17:23.25 | Tim_Toady | kpfleming thers already this but its totaly misleading: https://issues.asterisk.org/view.php?id=16902 |
| 17:23.41 | Tim_Toady | maybe u can re-open it or something? |
| 17:24.16 | kpfleming | leifmadsen: please reopen 16902.. the comments there were wrong, the reporter's 'fix' was not at all related |
| 17:24.32 | leifmadsen | M16902 |
| 17:24.34 | MuffinMan | [closed] [Asterisk] Channels/chan_dahdi 0016902: Compile fails in dahdi_show_status with kernel 2.6.33 reported by colbec https://issues.asterisk.org/view.php?id=16902 |
| 17:24.52 | kpfleming | the kernel version is completely irrelevant, what is important is the dahdi version |
| 17:25.05 | leifmadsen | done! |
| 17:26.36 | jpeeler | apparently i need to stop trusting what people say |
| 17:26.44 | jpeeler | is there an actual compile problem then? |
| 17:26.47 | leifmadsen | trust no one |
| 17:26.47 | kpfleming | yes |
| 17:27.02 | jpeeler | ok, sorry for the oversight |
| 17:27.11 | kpfleming | the references to bpvcount are not protected by a configure script test to ensure that the installed dahdi version provides bpvcount |
| 17:27.47 | jpeeler | and crc4count then as well i presume |
| 17:27.54 | kpfleming | i dont know... probably |
| 17:28.07 | kpfleming | whatever new fields were added in dahdi_spaninfo |
| 17:28.08 | Tim_Toady | yes both |
| 17:29.40 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.24.141.138) |
| 17:34.23 | philipp64 | just saw this in astlinux 1.6.2.5: |
| 17:34.24 | philipp64 | Mar 11 10:04:34 pbx user.info kernel: asterisk[8933]: segfault at 40 ip 4040b10c sp ba7fb7b0 error 4 in app_meetme.so[403fd000+18000] |
| 17:34.27 | philipp64 | known issue? |
| 17:38.25 | Corydon76-dig | Wow, that's... a completely useless message |
| 17:39.35 | Corydon76-dig | That could be literally anything, from a bug to a power surge |
| 17:41.07 | philipp64 | except that I'm on a UPS. :-) |
| 17:42.41 | Corydon76-dig | That only makes it a bit less likely, not impossible. |
| 17:48.18 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 18:16.47 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:22.34 | murdock_ut | May I ask a question here a bout a potential bug? |
| 18:28.37 | Corydon76-dig | ~ask |
| 18:28.38 | infobot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 18:33.06 | murdock_ut | Haha.. my bad "Don't ask if you can ask a question first" |
| 18:35.15 | murdock_ut | Ok, running 1.6.1.18-rc2 A call B B answers A does an attended transfer or a blind transfer to 700. The parking slot is announced and then dial plan execution continues past the dial application which I thought it should not. |
| 18:35.59 | murdock_ut | To see dialplan and console output. http://pastebin.com/hqJSvgF0 |
| 18:36.35 | murdock_ut | checking in 1.6.1 svn to see if issue remains. |
| 18:45.00 | murdock_ut | Hey, it may be fixed. |
| 18:49.05 | murdock_ut | Ok, should a ticket be made if the bug is in 1.6.1.18-rc2 but not in svn? |
| 18:50.36 | leifmadsen | murdock_ut: no |
| 18:50.51 | leifmadsen | murdock_ut: if it is in the 1.6.1 branch (fixed) then it will be part of the next release process |
| 18:50.59 | leifmadsen | (1.6.1.19-rc1 for example) |
| 18:51.22 | murdock_ut | Great! Thanks guys for all you do! |
| 18:56.57 | *** join/#asterisk-dev ecrane (~ecrane@o1-69-19-166-10.static.o1.com) |
| 19:14.30 | seanbright | subversion is part of the apache project now? i officially live under a rock |
| 19:16.22 | leifmadsen | wow, I had no idea |
| 19:17.24 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:17.44 | seanbright | this is still my favorite 1.6 feature that i haven't used yet: |
| 19:17.46 | seanbright | http://subversion.apache.org/docs/release-notes/1.6.html#file-externals |
| 19:27.47 | *** join/#asterisk-dev Netgeeks (~chris@173-11-68-157-SFBA.hfc.comcastbusiness.net) |
| 19:29.22 | *** join/#asterisk-dev Madoc (~Madoc@bas8-toronto63-1177708113.dsl.bell.ca) |
| 19:30.32 | Madoc | If im writing an app and want to set/retrieve a variable attached to a channel, what functions should I be reading on. only thing I can find in channel is ast_channel_setvariables which sets a bunch of them, I only need one and I dont see a way to retrieve them after |
| 19:31.07 | Madoc | is there some standard 'working with channel variables' doc I should be reading? |
| 19:31.29 | Madoc | Google keeps pointing me at variable handling in dialplans |
| 19:31.49 | Madoc | or AGI, neither of which I'm using |
| 19:31.55 | seanbright | pbx_builtin_getvar_helper() |
| 19:31.57 | seanbright | i think |
| 19:31.58 | file | pbx_builtin_setvar_helper? pbx_builtin_getvar_helper? |
| 19:32.14 | Madoc | thanx, I'll read up on those |
| 19:33.08 | Madoc | Looks like exactally what I'm looking for, thank you! |
| 19:34.42 | Corydon76-dig | also pbx_builtin_pushvar_helper |
| 19:41.17 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 19:43.13 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 19:44.44 | Deeewayne | can someone please tell me why the ast_generic_bridge is broken when the monitored channel receives DTMF ? |
| 19:46.17 | Deeewayne | broken as in 'unlink', not as in a bug |
| 19:46.20 | seanbright | cannot |
| 19:47.14 | Deeewayne | I originally thought it was due to variable length dtmf, but I believe that functionality has been there since before variable length dtmf was supported |
| 19:47.32 | tzafrir_laptop | Bah. I don't get along well with post-review |
| 19:47.45 | tzafrir_laptop | anyway, to understand it better, I wrote it a man page: |
| 19:48.15 | tzafrir_laptop | http://git.tzafrir.org.il/?p=rbtools.git;a=blob;f=debian/post-review.1;h=28b217ccf496593a117b38fdcc0e79f620ac58d9;hb=refs/heads/debpack |
| 19:48.38 | Corydon76-dig | Deeewayne: I think it's a temporary break, to allow a featuremap to take an action, then it's rebridged |
| 19:49.35 | wedhorn | russellb: the readq stuff |
| 19:49.41 | wedhorn | M14998 |
| 19:49.44 | MuffinMan | [ready for review] [Asterisk] Core/Channels 0014998: [patch] Change readq locking reported by wedhorn https://issues.asterisk.org/view.php?id=14998 |
| 19:50.00 | Deeewayne | Corydon76-dig, it is a temporary break. I'm using dynamic_features (features.c) and I can see a 2 unlink/bridge ami events per dtmf |
| 19:50.27 | Deeewayne | thanks |
| 19:50.33 | wedhorn | russellb: what do you think about progressing the readq stuff and leaving the softhangup until later? |
| 19:56.26 | russellb | I never gave you feedback, I'm sorry :-( |
| 19:56.59 | russellb | but yeah, that sounds reasonable |
| 20:00.33 | wedhorn | russellb: ok, I'll have a look through the patch and see if I can't get something up on the review board |
| 20:07.40 | seanbright | hmm |
| 20:08.02 | seanbright | why is build-asterisk-openbsd.sh needed in testsuite? |
| 20:08.18 | Qwell | because BSD is dumb |
| 20:08.30 | seanbright | the only diffs are 'bash' -> 'sh' and 'make' -> 'gmake' |
| 20:08.36 | seanbright | which would work fine on linux |
| 20:08.42 | Qwell | gmake doesn't always work on Linux |
| 20:08.52 | seanbright | ah |
| 20:08.58 | Qwell | gmake: command not found |
| 20:09.05 | seanbright | gotcha |
| 20:09.09 | seanbright | thought that was standard |
| 20:09.09 | russellb | they should be the same script |
| 20:09.16 | russellb | that alter their behavior based on what platform it's running on |
| 20:09.21 | russellb | but they are not yet. |
| 20:09.28 | seanbright | patches welcome. |
| 20:09.32 | russellb | pretty much |
| 20:09.39 | seanbright | meritocracy |
| 20:09.41 | seanbright | and all that. |
| 20:09.42 | seanbright | heh |
| 20:09.44 | file | nap instead, it's nicer |
| 20:09.49 | seanbright | good call |
| 20:10.05 | russellb | I also want to have another script that bamboo actually runs that checks out testsuite and installs the latest build scripts before actually running build-astersik |
| 20:10.15 | russellb | so logging into each slave isn't required when changes are made |
| 20:10.57 | seanbright | we need to autoconf up asttest at some point as well |
| 20:11.01 | russellb | yes. |
| 20:11.07 | russellb | I also have a menuselect related problem ... |
| 20:11.19 | seanbright | menuselect blows |
| 20:11.30 | russellb | I need a way, from a script, to enable TEST_FRAMEWORK and all test_* modules that have dependencies met |
| 20:11.34 | russellb | I don't know how to do it |
| 20:11.42 | russellb | turns out, menuselect does such from automated build scripts |
| 20:11.48 | russellb | runs from tzafrir |
| 20:11.56 | seanbright | heh |
| 20:11.57 | russellb | s/such/suck/ |
| 20:12.26 | Qwell | mmm, can a category be defaultenabled=no? |
| 20:12.30 | russellb | anyway, yeah ... until I get that figured out, I can't run the unit tests on non-linux |
| 20:12.47 | russellb | (or a linux slave that wasn't capable of just building everything) |
| 20:13.13 | russellb | seanbright: annnnnnd GO |
| 20:13.19 | seanbright | heh |
| 20:13.21 | seanbright | riiiiiiiight |
| 20:13.30 | russellb | I was thinking some more command line options to menuselect, maybe .. |
| 20:13.37 | russellb | like ... menuselect --enable TEST_FRAMEWORK |
| 20:13.47 | russellb | and then, menuselect --enable_category TESTS |
| 20:13.55 | seanbright | hmmm |
| 20:13.59 | russellb | that wouldn't be hard |
| 20:14.05 | russellb | and would let menuselect do the "right" things |
| 20:14.29 | russellb | enabling a category would just be short for "enable everything in a category (that is possible)" |
| 20:14.43 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@c-68-34-116-180.hsd1.md.comcast.net) |
| 20:14.48 | seanbright | well good luck |
| 20:14.52 | seanbright | :-) |
| 20:14.53 | russellb | awww |
| 20:15.11 | russellb | your menuselect maintainer title is dead to me |
| 20:15.33 | seanbright | i had forgotten that |
| 20:15.47 | seanbright | it was honorary anyway |
| 20:15.52 | Qwell | maintenance != new features :p |
| 20:15.58 | seanbright | thank you, Qwell |
| 20:16.01 | seanbright | always looking out |
| 20:16.41 | russellb | yeah, I'll do it |
| 20:16.47 | russellb | will you at least code review it? heh |
| 20:16.52 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 20:16.54 | seanbright | of course |
| 20:19.26 | russellb | but first ... I really need to do our GSoC application |
| 20:19.51 | Qwell | Just ask for like 40 students. They'll approve it. |
| 20:19.51 | file | yes, you do |
| 20:20.02 | russellb | we only have 4 mentors |
| 20:20.08 | russellb | 40 students seems a bit unreasonable |
| 20:20.12 | Qwell | pfft |
| 20:20.14 | *** join/#asterisk-dev moy (~chatzilla@74.12.129.100) |
| 20:22.37 | russellb | unless seanbright wants 37 students |
| 20:22.43 | Qwell | he does |
| 20:22.55 | tzafrir_laptop | ITP of rbtools posted. the one from my repo should be buildable with git-buildpackage. |
| 20:22.55 | Qwell | he can have a small army |
| 20:23.10 | tzafrir_laptop | any interest in me posting the deb? |
| 20:26.49 | Corydon76-dig | I wouldn't mind trying to work with 2 students |
| 20:31.12 | *** part/#asterisk-dev Madoc (~Madoc@bas8-toronto63-1177708113.dsl.bell.ca) |
| 20:33.26 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:44.30 | *** join/#asterisk-dev ctooley (~ctooley@c-98-193-232-154.hsd1.tn.comcast.net) |
| 20:44.31 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 20:46.09 | *** join/#asterisk-dev davidbrillert (~aragon125@h216-235-8-130.host.egate.net) |
| 20:47.10 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 20:56.48 | seanbright | he does not |
| 20:56.52 | seanbright | i can assure you |
| 21:07.26 | *** join/#asterisk-dev murdock_ut (~chatzilla@mail.kimballequipment.com) |
| 21:10.59 | philipp64 | kpfleming: would it make sense to add an option to the SLA stuff so that if you pick up a trunk that's already in use, that it puts you into a N-way conference (i.e. emulating a party line). |
| 21:22.48 | tzafrir_laptop | http://svnview.digium.com/svn/dahdi?view=rev&rev=8333 |
| 21:23.14 | tzafrir_laptop | Is it reasonable to have a device appear in e.g. dahdi_hardware as 'HA8-0000'? |
| 21:23.22 | tzafrir_laptop | Isn't this name slightly too cryptic? |
| 21:24.40 | *** join/#asterisk-dev ebroad (~EB@72.11.213.195) |
| 21:24.59 | ebroad | mnicholson, ping |
| 21:25.56 | ebroad | kpfleming, ping |
| 21:31.05 | seanbright | ebroad: ping |
| 21:31.14 | seanbright | tzafrir_laptop: what device is that? |
| 21:31.17 | ebroad | seanbright, pong |
| 21:31.23 | seanbright | ebroad: just pinging you. |
| 21:31.25 | ebroad | ah |
| 21:31.26 | seanbright | hiiiii |
| 21:31.29 | seanbright | heh |
| 21:31.39 | ebroad | now that i have your attention |
| 21:31.42 | ebroad | :) |
| 21:32.00 | seanbright | how can i lead you astray today? |
| 21:32.03 | ebroad | answer() before receivefax() using res_fax, yes or no? |
| 21:32.21 | tzafrir_laptop | seanbright, not really sure |
| 21:32.26 | ebroad | playing around with the shiny new res_fax_spandsp |
| 21:33.21 | niekvlessert | ebroad: we are too, look here, overhere they don't answer: http://www.teamforrest.com/blog/156/integrating-fax-for-asterisk/ |
| 21:33.33 | seanbright | ebroad: it will answer the channel if it's not already answered |
| 21:33.38 | ebroad | ok |
| 21:33.44 | seanbright | based on line 1215 of res_fax.c |
| 21:34.29 | ebroad | testing with zoiper and we aren't even getting to t.38 negotiation |
| 21:35.28 | ebroad | niekvlessert, looks like you are discussing res_fax_digium |
| 21:35.34 | seanbright | any warning messages on the cli? |
| 21:35.40 | seanbright | or the logs |
| 21:35.46 | ebroad | <PROTECTED> |
| 21:36.04 | ebroad | im looking at the ced code commit that mnicholson made |
| 21:38.35 | niekvlessert | ebroad: sorry about that, well i suggest you use that :) 1 free channel 4 everybody :) |
| 21:39.21 | niekvlessert | ebroad: if you install this one also you have 2 ways to test it |
| 21:39.29 | ebroad | true |
| 21:39.49 | ebroad | though i think im gonna revert back to app_fax for now |
| 21:39.57 | ebroad | until i can sort this out |
| 21:40.23 | niekvlessert | ebroad: that doesn't support t-38 right? |
| 21:40.36 | ebroad | i believe is does |
| 21:40.38 | ebroad | *it |
| 21:42.27 | niekvlessert | ebroad: why would you go through the hassle when you can use the res_fax_digium? faxing is SOOOO annoying |
| 21:42.45 | ebroad | because app_fax worked for me in the past |
| 21:44.26 | niekvlessert | ok |
| 21:47.33 | ebroad | app_fax works |
| 21:48.36 | seanbright | in trunk? |
| 21:49.14 | ebroad | yup |
| 21:49.44 | seanbright | yeah, it's not doing the ced generation |
| 21:51.29 | ebroad | hmm |
| 21:51.37 | ebroad | it is calling ast_tonepair_start |
| 21:51.42 | seanbright | so that's buggy i guess |
| 21:52.11 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 21:54.46 | seanbright | is that bad? |
| 21:54.52 | seanbright | it's failing on the ast_read() |
| 21:56.45 | seanbright | hmmm |
| 21:56.47 | seanbright | i have a theory |
| 21:57.05 | seanbright | ebroad: |
| 21:57.07 | seanbright | This signal may be sent by the Terminating FAX machine anywhere between 1.8 to 2.5 seconds AFTER answering the call. |
| 21:57.11 | seanbright | (referring to CED) |
| 21:57.56 | ebroad | right |
| 21:58.02 | ebroad | so we generate for 3 seconds |
| 21:58.26 | ebroad | then we wait |
| 21:58.34 | jpeeler | Tim_Toady: ping |
| 21:58.35 | ebroad | ast_wait retursn right away |
| 21:58.48 | ebroad | s/ast_wait/ast_waitfor |
| 21:59.03 | Tim_Toady | jpeeler pong |
| 21:59.09 | ebroad | and ast_read fails |
| 21:59.16 | seanbright | tzafrir_laptop: http://tinyurl.com/yjcxkp6 |
| 21:59.38 | seanbright | ebroad: we generate for 3 seconds, but we don't wait 1.8 to 2.5 |
| 21:59.46 | ebroad | right |
| 21:59.52 | ebroad | in app_fax we do |
| 21:59.55 | ebroad | looking at it now |
| 22:00.08 | jpeeler | Tim_Toady: what version of dahdi were you using earlier to compile against 1.6.2? those member variables have been around since zaptel |
| 22:00.11 | ebroad | while (timeout > 0) |
| 22:00.12 | seanbright | just curious... put an Answer(2000) before calling ReceiveFax from res_fax |
| 22:00.26 | ebroad | gotta rebuild |
| 22:00.27 | ebroad | 1 sec |
| 22:01.19 | Tim_Toady | jpeeler both * and dahdi where compiled from svn |
| 22:01.26 | seanbright | i didn't find that from the most authoritative source, for what it's worth. |
| 22:01.41 | Tim_Toady | dahdi was a bit older compiled at feb 23 when updated my kernel |
| 22:02.16 | Tim_Toady | i still have the same eror on my other pc when i havent updated dahdi yet |
| 22:02.24 | philipp64 | tzafrir_laptop: when is the next version of dahdi-tools due out? |
| 22:02.31 | tzafrir_laptop | seanbright, well, if this will be a good (intuitive) identifier, fine by me |
| 22:02.32 | Tim_Toady | s/when/where |
| 22:03.02 | tzafrir_laptop | philipp64, not really sure. I see 2.2.1.1 has been tagged |
| 22:03.12 | tzafrir_laptop | philipp64, anything specific? |
| 22:03.31 | jpeeler | i don't know what's going on then... |
| 22:04.03 | Tim_Toady | kpfleming might know, he pointed it out in the first place |
| 22:04.23 | kpfleming | ugh... people talking to me when i'm not here |
| 22:04.28 | Tim_Toady | :> |
| 22:04.58 | jpeeler | kpfleming: both bpvcount and crc4count have been around since 2005 |
| 22:05.28 | seanbright | ebroad: i don't think that is going to fix it... but you can test anyway |
| 22:05.44 | tzafrir_laptop | Tim_Toady, can you build with NOISY_BUILD=yes and pastebin the failing build command as well as the error? |
| 22:05.54 | ebroad | seanbright, its worth a try |
| 22:06.03 | kpfleming | jpeeler: didn't they move into a new structure or something? |
| 22:06.04 | philipp64 | tzafrir_laptop: just the various build fixes, like # 15477 and 16597... |
| 22:06.32 | seanbright | ebroad: according to T.30 the CED should start after 0.2s |
| 22:06.46 | seanbright | (at least 0.2s, rather) |
| 22:06.49 | ebroad | 200ms |
| 22:06.52 | seanbright | yeah |
| 22:06.58 | ebroad | answer(200)? |
| 22:07.01 | jpeeler | kpfleming: looks like they've been there at least since the initial dahdi split |
| 22:07.15 | seanbright | sure |
| 22:07.27 | Tim_Toady | tzafrir_laptop sure, wait a min to reach the other machine |
| 22:08.18 | philipp64 | tzafrir_laptop: is see that both got committed into trunk, but I didn't look to see what timestamp on trunk 2.2.1.1 was pulled from. |
| 22:09.41 | seanbright | tee thirty hate |
| 22:09.48 | kpfleming | jpeeler: Tim_Toady: i think i know what it was... for a short time, dahdi_spaninfo was changed, and asterisk was changed to match. then i complained that the change broke compatibility, so it was reverted... so, there is no current problem. however, what this means for Tim_Toady is that if he's going to use SVN snapshots, he should always update all of them at once, not only one of them |
| 22:10.14 | Tim_Toady | true :) |
| 22:10.16 | Qwell | philipp64: it wasn't pulled from trunk |
| 22:10.34 | Tim_Toady | tzafrir_laptop still want that errors? |
| 22:10.47 | kpfleming | philipp64: SLA already has the exact feature you are talking about... that's why it was implemented inside app_meetme.c |
| 22:11.34 | tzafrir_laptop | Tim_Toady, do you have up-to-date SVN? |
| 22:12.07 | Tim_Toady | yes, but the dahdi modules i have installed where a bit out of date, that caused the prob |
| 22:12.18 | Tim_Toady | so as kpfleming thers no current issue |
| 22:12.25 | Tim_Toady | said* |
| 22:12.32 | jpeeler | kpfleming: thanks that saved me a ton of time |
| 22:13.55 | kpfleming | sorry.. it was a short-term problem. |
| 22:14.21 | kpfleming | 'svn annotate' on dahdi/user.h would give you the clues though, because you can see that those lines were changed recently |
| 22:15.38 | seanbright | ebroad: any luck? |
| 22:16.47 | ebroad | seanbright, fixing my broken fax2email script, will test in a minute |
| 22:27.56 | tzafrir_laptop | Tim_Toady, the dahdi modules can't break compilation |
| 22:28.08 | tzafrir_laptop | <dahdi/user.h> can |
| 22:28.49 | ebroad | seanbright, no go |
| 22:28.51 | philipp64 | kpfleming: ok, wasn't sure. sla.tex seems to imply that only one user can be on the trunk at a time... maybe the doc is out of date. |
| 22:29.16 | kpfleming | or just plain wrong. |
| 22:29.25 | russellb | it has always been able to do it |
| 22:29.37 | russellb | the docs just aren't good enough, i suppose |
| 22:30.08 | russellb | i probably just assumed it didn't need to be said, since that was so fundamental to the functionality |
| 22:30.09 | russellb | shrugs |
| 22:30.51 | Tim_Toady | tzafrir_laptop im afraid its already late to investigate it further, i ve just updated both my boxes that had this prob |
| 22:31.46 | *** join/#asterisk-dev mspiceland (~mike@nat/digium/x-lxwmbdolxszkorpy) |
| 22:37.38 | ebroad | seanbright, you are correct, no CED tones are going across the wire |
| 22:37.44 | ebroad | confirmed it with wireshark |
| 22:38.04 | kpfleming | are you receiving audio from the caller? |
| 22:38.09 | ebroad | 1 frame |
| 22:38.25 | ebroad | all 0xf |
| 22:38.30 | kpfleming | then you need internal timing enabled to be able to generate outbound audio since you are not receiving inbound audio |
| 22:38.32 | ebroad | then 488 |
| 22:39.09 | ebroad | internal_timing is set to yes in asterisk.conf |
| 22:39.44 | ebroad | this is with res_fax/res_fax_spandsp |
| 22:39.48 | ebroad | app_fax works fine |
| 22:40.05 | kpfleming | we have an open issue internally that may be related, where tones are not being generated without an incoming audio stream... so it's being looked at. |
| 22:40.12 | ebroad | ah |
| 22:40.37 | kpfleming | but if your other endpoint supports T.38, it shouldn't be responding with a 488 |
| 22:40.49 | ebroad | asterisk is responding with 488 |
| 22:41.51 | kpfleming | that makes no sense, to be honest. if it's receiving a T.38 re-invite during the initial setup phase, it should accept it unless the parameters are wacky or T.38 is disabled. |
| 22:42.06 | ebroad | asterisk: 100 trying, client: 1 rtp frame, asterisk: 448, asterisk: some (according to wireshark - corrupt) udptl frames, asterisk: bye |
| 22:42.13 | ebroad | *488 |
| 22:42.27 | kpfleming | umm... hang on |
| 22:42.37 | kpfleming | does the initial invite include only T.38, and not audio? |
| 22:42.42 | ebroad | yes |
| 22:42.45 | kpfleming | that's broken |
| 22:42.50 | kpfleming | that will not work with asterisk |
| 22:42.56 | ebroad | its the zoiper classic client |
| 22:43.01 | kpfleming | then it needs to be reconfigured |
| 22:43.07 | kpfleming | it *must* provide an audio stream during call setup |
| 22:43.19 | ebroad | 1 sec ill double check |
| 22:43.23 | kpfleming | of course you aren't seeing any CED tones, there is no audio stream for them to appear on! |
| 22:44.13 | ebroad | actually it does |
| 22:44.26 | ebroad | the first invite has standard voice sdp payload |
| 22:44.41 | kpfleming | and then asterisk answers with 200 OK? |
| 22:45.01 | ebroad | yup |
| 22:45.04 | kpfleming | ok |
| 22:45.08 | ebroad | the reinvite is t.38 only |
| 22:45.13 | kpfleming | ok, that makes sense |
| 22:45.26 | ebroad | 100 trying, then 200 ok |
| 22:45.26 | kpfleming | does reinvite come after ReceiveFAX is running? |
| 22:45.35 | kpfleming | now you're confusing me |
| 22:45.41 | kpfleming | you said asterisk responded 488 to that invite |
| 22:46.48 | ebroad | client: invite with voice sdp, asterisk: 100, asterisk: 200, client: ack, client: reinvite - t.38 only, asterisk: 100, asterisk: 488 |
| 22:47.11 | kpfleming | ok, that's what you said the first time, not the second time |
| 22:47.16 | ebroad | sorry |
| 22:47.25 | kpfleming | so the relevant question is whether that reinvite occurs when ReceiveFAX is running, or before |
| 22:47.40 | ebroad | well, im not calling answer first |
| 22:48.02 | ebroad | though i believe it does |
| 22:48.54 | ebroad | receivefax is after the reinvite |
| 22:52.47 | kpfleming | then that is expected. if receivefax is not running, asterisk cannot accept the t.38 reinvite, because there is no application running that supports t.38 on that channel. |
| 22:59.11 | *** join/#asterisk-dev xpot-mobile (~xpot@66.60.101.91) |
| 23:01.01 | kpfleming | so it sounds like you are answering the channel before running receivefax. if so, there is no need to do that, and in this case it's harmful, so stop doing that :-) |
| 23:05.11 | ebroad | i took answer() out |
| 23:05.17 | ebroad | still no go |
| 23:06.06 | kpfleming | then you need to post a log file with 'core set verbose 10', 'core set debug 10' and 'sip set debug on' so we can see exactly what is happening |
| 23:07.07 | ebroad | this is the only error i get |
| 23:07.08 | ebroad | <PROTECTED> |
| 23:07.20 | kpfleming | that is not at all what i asked you |
| 23:07.39 | ebroad | 1 sec |
| 23:07.51 | kpfleming | that is probably because by that time zoiper has hung up, and is only a side effect, not the actual problem |
| 23:17.33 | ebroad | kpfleming, http://pastebin.ca/1834704 |
| 23:17.50 | kpfleming | looks |
| 23:20.01 | kpfleming | yeah... so zoiper is sending the reinvite as soon as the call is answered, which is really not very friendly |
| 23:20.14 | jmls | why would exten => foo,2,Playback(somefile) play sound to the caller |
| 23:20.33 | jmls | but exten => foo,2,MusicOnHold() just have silence ? |
| 23:23.08 | ebroad | which chan_sip is handling before receivefax kicks in |
| 23:23.18 | kpfleming | no, not quite |
| 23:23.21 | kpfleming | still looking, hang on |
| 23:24.35 | jmls | crap, sorry, wrong tab |
| 23:24.47 | jmls | knew he had #asterisk open for something .. :P |
| 23:24.59 | kpfleming | ebroad: you do have t38udptl_pt = yes set for this peer in sip.conf, right? |
| 23:25.09 | ebroad | yup |
| 23:25.36 | ebroad | isnt that t38pt_udptl? |
| 23:25.41 | kpfleming | yes |
| 23:25.46 | ebroad | thats set |
| 23:25.46 | kpfleming | please post the output of 'sip show peer 206' |
| 23:26.09 | ebroad | and t38pt_usertpsource is set to no |
| 23:26.53 | ebroad | done, its ways down it pastebin |
| 23:28.03 | kpfleming | i don't understand |
| 23:28.06 | kpfleming | where is it? |
| 23:28.12 | ebroad | same id |
| 23:28.15 | ebroad | at the bottom |
| 23:28.23 | ebroad | line 699 |
| 23:28.37 | kpfleming | it stops at 692, even if i refresh |
| 23:28.45 | ebroad | argh |
| 23:28.54 | ebroad | new post, new id |
| 23:28.55 | ebroad | http://pastebin.ca/1834723 |
| 23:29.46 | kpfleming | well... i have no idea why, but something is badly broken, because chan_sip is responding immediately with 488, which it shouldn't do for 4-5 seconds unless the application tells it to (which it is not doing) |
| 23:30.10 | ebroad | i inserted some ast_verbose |
| 23:32.04 | ebroad | and the 488 is coming from line 5253 |
| 23:32.08 | ebroad | chan_sip.c |
| 23:32.22 | kpfleming | that's clear |
| 23:32.27 | ebroad | something is setting AST_T38_REQUEST_TERMINATE |
| 23:32.32 | kpfleming | yeah |
| 23:32.34 | ebroad | the question is what |
| 23:32.39 | kpfleming | it's normally a timer if the application does not respond |
| 23:33.02 | kpfleming | i see another bug in res_fax, though |
| 23:33.03 | kpfleming | grr |
| 23:35.24 | ebroad | the only place inside of chan_sip where we call interpret_t38_parameters in sip_indicate |
| 23:36.25 | ebroad | kpfleming, i gotta head out, much thanks for the help, sorry for making you crazy with this |
| 23:36.36 | kpfleming | no problem |
| 23:36.42 | ebroad | my hunch is the generator code in channel.c |
| 23:36.55 | ebroad | but the few ast_verbose i put in haven't turned anything up |
| 23:37.15 | ebroad | zoiper works with app_fax btw |
| 23:37.48 | ebroad | and i believe app_fax doesnt use ast_tonepair* |
| 23:39.13 | kpfleming | it does not |
| 23:39.32 | kpfleming | it lets the spandsp stack generate the CED tone, and then kills the audio fax session if the switch to t.38 happens |
| 23:53.34 | russellb | seanbright: review posted! |