| 00:54.19 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 00:54.59 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-xabrwmvgvalbpaji) |
| 01:15.18 | alecdavis | when will app_mysql be removed. in 1.8 it says deprecated. Thus I thought it would be gone in 10, or trunk, but it's still there in both? |
| 01:34.36 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:34.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:07.38 | snuff-work | alecdavis: we stopped 'removing' stuff because it was affecting too many ppl |
| 02:08.29 | snuff-work | mm i shouldn't say 'we' but.. it was decided to leave it as many ppl still programmed with it at the time |
| 02:30.38 | alecdavis | Thanks. A site I maintain has a bit of mysql in the dialplan. Need to swat up on func_odbc. |
| 02:30.52 | alecdavis | But I don't need to hurry... |
| 02:45.26 | jsmith | alecdavis: Once you learn func_odbc, it's really hard to go back to using app_mysql |
| 02:54.05 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:54.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:56.17 | Kobaz | mm, back |
| 02:59.42 | Kobaz | soooo |
| 02:59.57 | Kobaz | what's a good way to debug this mixmonitor recording timing mismatch |
| 03:01.40 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 03:01.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:01.05 | alecdavis | does wearing an '* Geek' teeshirt help with func_odbc. Or does it mean I should know all this stuff already. |
| 04:13.41 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 04:35.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 04:41.18 | Kobaz | sure |
| 08:06.28 | *** join/#asterisk-dev hrolf (7514166e@gateway/web/freenode/ip.117.20.22.110) |
| 08:06.35 | hrolf | In console, the error shows that "Didn't get a frame from SIP/100-000000b" (which is the caller) |
| 08:06.40 | hrolf | and hangups |
| 08:06.53 | hrolf | http://pastie.org/3443251 is the log |
| 08:09.17 | wdoekes2 | hrolf: are you in a conversation with someone? |
| 08:17.47 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 09:24.43 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 10:20.25 | *** part/#asterisk-dev hrolf (7514166e@gateway/web/freenode/ip.117.20.22.110) |
| 11:04.04 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 12:31.44 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:31.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:28.36 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 13:52.19 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 14:05.58 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-qptyvwrfydggqhwi) |
| 14:09.24 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-tnlisfggudlvhiqp) |
| 14:09.24 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:19.43 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-npwnsknrplcckzwu) |
| 14:19.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:33.09 | *** join/#asterisk-dev manitou_ (~manitou@93.170.30.243) |
| 14:33.32 | wdoekes2 | file: ping |
| 14:33.39 | file | pong |
| 14:34.03 | wdoekes2 | file: re: no valid transports: so I can just commit that in 1.8? |
| 14:34.15 | wdoekes2 | since it alter undocumented behaviour |
| 14:34.18 | wdoekes2 | *alters |
| 14:35.30 | file | I'd wait to get a second ship it |
| 14:38.05 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:38.35 | wdoekes2 | :) |
| 14:38.46 | file | (do you guys have a policy on that? we did in SCF) |
| 14:38.51 | file | or do |
| 14:39.26 | mjordan | file: no policy for that, unfortunately |
| 14:39.41 | mjordan | right now its a single ship it sends the patch in |
| 14:39.55 | file | that's wrong imo |
| 14:40.12 | mjordan | wrt that particular change, I think the no valid transports message got added in 1.8 anyway, so its not like we're changing long established behavior |
| 14:40.31 | mjordan | file: I agree, but we haven't had a good enough of a mechanism to enforce multiple reviews |
| 14:40.33 | wdoekes2 | mjordan: well.. it's not the message that's changed |
| 14:40.46 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 14:40.49 | wdoekes2 | it's the fact that transport=new_transport flushes ealier transports |
| 14:40.54 | wdoekes2 | *earlier |
| 14:41.14 | mjordan | ah, I see |
| 14:41.18 | mjordan | hm. |
| 14:41.29 | wdoekes2 | documentation says to put all transports on a single line, but someone out there might have figured it looks nice one indivual lines or something |
| 14:41.35 | wdoekes2 | *individual |
| 14:41.36 | wdoekes2 | jezus |
| 14:41.53 | wdoekes2 | it's not a good day for typing |
| 14:42.07 | wdoekes2 | *on |
| 14:42.14 | file | that's called using an undocumented and undefined method |
| 14:43.23 | mjordan | that's true. Unfortunately, this one piece of undocumented and undefined behavior is something that a not insignificant portion of the user base probably does "rely" on. |
| 14:43.38 | mjordan | I can see the JIRA issue flood now |
| 14:44.17 | file | I doubt it actually |
| 14:45.23 | mjordan | you don't think that there are people who have put transport=udp in the [general] section, then put transport=tcp in a peer definition, and later decided to communicate with that peer over UDP? |
| 14:46.12 | mjordan | I'm not saying that they're doing a good job of maintaining their system, by the way |
| 14:46.23 | mjordan | or paying attention to the flood of WARNING messages |
| 14:46.47 | mjordan | but if it previously treated that peer's transport as udp,tcp; and now we change it to be tcp, that could cause a problem |
| 14:47.55 | file | that's not how it works |
| 14:48.28 | file | it's if you do multiple transport lines within the peer |
| 14:48.57 | mjordan | ah |
| 14:49.23 | mjordan | objection overruled |
| 14:49.54 | mjordan | I'd say go with it then. When 1.8.11 gets put together, I'll make sure that change is at the top of the list |
| 15:04.46 | manitou_ | hi guys, i'm trying to modify a module for asterisk to communicate with CDMA modems (chan_dongle), I already talked with main developer, but got some white spots in module interface. Can you help me with asterisk interaction, which asterisk function is responsible for informing asterisk about call state change (dialing, ringing, freeing)? |
| 15:06.16 | seanbright | when is asterisk 11 being branched? |
| 15:08.18 | russellb | the day after yesterday |
| 15:08.25 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:08.25 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:08.29 | mjordan | you didn't get the memo? |
| 15:08.50 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions |
| 15:09.02 | mjordan | based on the dotted line, half-way through this year |
| 15:09.32 | russellb | wishes the LTS versions were even numbers :-p |
| 15:09.46 | mjordan | or, as it says on the table below the picture, 3rd Wednesday of July |
| 15:09.49 | file | russellb, YOU HAVE NO POWER |
| 15:09.56 | seanbright | well then |
| 15:09.57 | russellb | i know. |
| 15:10.07 | seanbright | so what you're saying is... RTFW |
| 15:10.10 | seanbright | got it! |
| 15:10.11 | file | except the power of love |
| 15:10.12 | mjordan | :-D |
| 15:10.12 | russellb | i don't work at digium so i don't have power, i get it |
| 15:10.21 | WIMPy | throws in a feature: Support for disconnected calls. It's a real PITA with cahn_dahdi. |
| 15:10.25 | file | russellb, :P |
| 15:12.15 | russellb | file: *rolls eyes* |
| 15:15.14 | *** join/#asterisk-dev pnlarsson (~niklas@212-181-95-218.customer.telia.com) |
| 15:18.25 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:18.25 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:33.56 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:33.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:41.59 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 15:57.22 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:57.23 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:01.59 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:01.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:11.45 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 16:14.05 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:14.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:25.57 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 16:25.57 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 17:01.53 | acidfoo | I asked yesterday, but since I havent found yet I'll reask: Is there a way to _manually_ poke the voicemail to get the number of old and new message ? (Asterisk 1.8..., and from a channel perspective) |
| 17:02.26 | acidfoo | thanks in advance |
| 17:03.41 | kpfleming | what does 'poke the voicemail' mean? |
| 17:05.09 | acidfoo | I explain ;) |
| 17:06.16 | acidfoo | now I can subscribe to the event AST_EVENT_MWI and I get called everytime something change.... Everytime I receive an event I can call ast_event_get_ie_uint(event, AST_EVENT_IE_NEWMSGS and OLDMSGS |
| 17:06.45 | kpfleming | right |
| 17:06.59 | acidfoo | What i'd like is to be able to know how much old and new message a given voicemail box has |
| 17:07.05 | acidfoo | without waiting for an event |
| 17:07.17 | kpfleming | when you subscribe, you will receive an 'initial' |
| 17:07.21 | acidfoo | ah! |
| 17:07.28 | kpfleming | doh... 'initial' event telling you the current state |
| 17:08.58 | acidfoo | do I need to add a parameter to receive an "initial" ? |
| 17:09.22 | kpfleming | no |
| 17:09.48 | acidfoo | or it's by default, because I have the feeling that I'm not receiving anything. What I tried is to leave a message in the box, I get an event. Restart asterisk, reload my module... register ... and expect an Initial |
| 17:10.20 | kpfleming | you should be getting one |
| 17:10.39 | kpfleming | when the event subscription is forwarded to app_voicemail, it should respond by generating an event |
| 17:11.35 | acidfoo | http://pastebin.com/0KFt1Jni |
| 17:11.49 | acidfoo | I hardcoded value to test |
| 17:12.32 | kpfleming | and you are not seeing your event callback get called? |
| 17:13.06 | acidfoo | not after I register |
| 17:13.13 | acidfoo | if I leave a new message, I do |
| 17:13.34 | kpfleming | is app_voicemail loaded when you do the registration? |
| 17:15.01 | mjordan | acidfoo: you can also use ast_app_inboxcount |
| 17:15.16 | acidfoo | yes, what I did to test is: asterisk is started, I check that app_voicemail is started(yes), then I do module reload mymodule |
| 17:15.37 | acidfoo | kpfleming, i'll do another test to see if app_voicemail is present |
| 17:15.41 | acidfoo | im not sure my test is ok |
| 17:15.50 | kpfleming | it should be |
| 17:16.10 | kpfleming | i would double-check the event system docs, and if you have to, poke russellb for some advice, as he was the author of that stuff :-) |
| 17:18.14 | acidfoo | I'll dig deeper, thanks |
| 17:18.19 | acidfoo | mjordan, ok, i'll have a look |
| 17:19.50 | mjordan | that isn't to say that it shouldn't be sending you the event by the way - but if manually need to grab the inbox counts, that function lets you do it. It will also tell you if app_voicemail isn't loaded when your module attempts to do that, as the newmsgs/oldmsgs will both return 0 |
| 17:20.22 | kpfleming | well, that's not an accurate indication, as the mailbox could in fact be empty :-) |
| 17:21.27 | acidfoo | just an example with chan_sip... you get a new messsage.. you led flash.. you reboot your phone.. what happen ? |
| 17:21.37 | Qwell | afaik, you have to subscribe to multiple events, otherwise you won't get the initial thingie. or something. |
| 17:21.42 | acidfoo | I tried with two phone here just to see... and the led doesn't flash after reboot |
| 17:21.49 | mjordan | yup. I was surprised we don't return something else when app_voicemail hasn't registered its callbacks. But you could contrive a test where you would have voicemails sitting in the old folder, and make a new one, and then start Asterisk to see if it gives you accurate counts |
| 17:21.57 | acidfoo | but might be constructor specific |
| 17:22.13 | Qwell | acidfoo: FYI, see start_poll_thread() in app_voicemail.c |
| 17:22.18 | kpfleming | acidfoo: if you reboot a sip phone, and it is sending a SUBSCRIBE for MWI, it will get updated when it subscribes |
| 17:22.39 | Qwell | kpfleming: the pastebin hints that it's skinny.. |
| 17:22.43 | kpfleming | if it is not subscribing, then it won't get told about MWI until chan_sip gets around to sending an unsolicited NOTIFY |
| 17:22.54 | kpfleming | Qwell: yes, i know. i was referring to his question about a SIP phone. |
| 17:22.57 | Qwell | ahh |
| 17:23.20 | file | chan_sip uses the cached event or queries the mailbox directly if there is no cached event |
| 17:23.44 | acidfoo | file, so it doesn't get a initial event when it re-subscribe ? |
| 17:23.58 | acidfoo | file, it used the latest cached event value ? |
| 17:24.01 | acidfoo | use* |
| 17:24.13 | file | it always uses the cached event value if available from the event core |
| 17:24.40 | kpfleming | ahh, but it has to ask for it. |
| 17:24.44 | kpfleming | this i did not remember. |
| 17:24.49 | file | correct |
| 17:25.00 | acidfoo | how does it ask for it ;) |
| 17:25.11 | file | ast_event_get_cached |
| 17:25.30 | file | and if none available then it falls back to ast_app_inboxcount |
| 17:25.51 | acidfoo | this is exactly what I need :) |
| 17:25.53 | acidfoo | thanks |
| 17:26.06 | acidfoo | with those function name i'll grep in the code and see how it's implemented |
| 17:26.13 | acidfoo | thank you for you time guys |
| 17:26.21 | file | sip_send_mwi_to_peer may be useful as a base |
| 17:26.46 | acidfoo | good |
| 19:05.51 | *** join/#asterisk-dev Devon_ (~chatzilla@63.214.236.169) |
| 19:36.57 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 20:03.36 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 20:04.41 | *** join/#asterisk-dev ccesario (~ccesario@187.17.166.162) |
| 20:19.09 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 21:03.57 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 21:10.25 | *** join/#asterisk-dev ccesario (~ccesario@201-42-146-167.dsl.telesp.net.br) |
| 21:54.07 | Corydon76-work | I suspect res_fax_digium is not paying attention to some of the config settings |
| 21:54.21 | kpfleming | orly? |
| 21:54.27 | kpfleming | make_me_a_sammich=yes? |
| 21:54.40 | Corydon76-work | I told it to limit the max speed to 2400 and then received a fax at 14400 |
| 21:55.22 | kpfleming | there have been a number of changes in that area over the last few releases, as matt found various problems |
| 21:55.38 | kpfleming | some of that stuff is actually the responsibility of res_fax as well |
| 21:55.56 | seanbright | ast_log(LOG_ERROR, "Unable to register channel class %s\n", "IAX2"); |
| 21:55.57 | seanbright | heh. |
| 21:56.07 | kpfleming | nice |
| 21:56.22 | Corydon76-work | Right, res_fax.conf is where it's located. The CLI says the max speed is recognized (read in), but... yeah... |
| 21:56.26 | kpfleming | there's actually a reason for that, though |
| 21:56.57 | kpfleming | well, i'm wrong. it's friday and my brain is tired. |
| 21:57.14 | kpfleming | Corydon76-work: usually what works the most reliably is to restrict the modem types that are allowed to be used, not the bitrate. |
| 21:57.22 | Corydon76-work | Ah... |
| 21:57.45 | Corydon76-work | So I should kill v29 to get rid of the top speeds? |
| 21:59.10 | kpfleming | i think so |
| 22:01.32 | Corydon76-work | And there are no standard ports for T.38, right? Wireshark says 6004, but I can't find that defined anywhere in the source. |
| 22:01.45 | russellb | seanbright: it's more efficient that way. |
| 22:03.03 | kpfleming | you mean for UDPTL? no, there are no standard ports, just like there are no standard ports for RTP. |
| 22:08.11 | seanbright | russellb: naturally |
| 22:25.50 | *** part/#asterisk-dev sustav (~alfa@nat/digium/x-wewwslifyvnebhjg) |
| 23:02.55 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-npwnsknrplcckzwu) |
| 23:04.31 | Corydon76-work | jrose_atDigium: thought of another problem with rwlocks (and specifically rdlocks) in res_odbc from one of your prior patches... |
| 23:05.44 | Corydon76-work | If you only obtain a read lock for running queries and need to escalate to a write lock for the disconnect/reconnect mambo, then if you have multiple queries running concurrently, you're going to disconnect/reconnect multiple times any time there's a problem. |
| 23:05.58 | Corydon76-work | Even if the first disconnect/reconnect solved the issue |
| 23:06.13 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 23:06.36 | Corydon76-work | If you use a mutex around it, serializing the queries (as in your current patch), that won't happen |
| 23:14.25 | *** join/#asterisk-dev tamiel (~tamiel@85-171-171-179.rev.numericable.fr) |
| 23:58.44 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |