| 00:38.14 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 00:38.15 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 00:52.42 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 01:34.35 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 02:02.09 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:02.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:16.56 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 07:41.18 | *** join/#asterisk-dev irroot (~gregory@197.168.169.129) |
| 07:49.04 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:49.05 | schmidts | good morning |
| 08:08.08 | *** join/#asterisk-dev irroot (~gregory@197.175.54.225) |
| 08:09.09 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 08:35.42 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:37.59 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:37.59 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:00.31 | *** join/#asterisk-dev irroot (~gregory@197.172.253.129) |
| 09:50.35 | schmidts | anyone awaken allready? |
| 09:50.47 | schmidts | does ao2_find even work against a container without a compare function? |
| 09:51.23 | schmidts | sorry forget it, i mixed the hash funciton with the compare function |
| 10:22.25 | *** join/#asterisk-dev merbanan (~benjamin@h217-27-188-82.cust.tyfon.se) |
| 10:27.20 | schmidts | normally is it better to change the parameter of an allready used function or to write a new one which act like a wrapper to it? |
| 10:29.20 | wdoekes2 | *where the original acts as a wrapper? |
| 10:30.12 | wdoekes2 | if it's in the header files (i.e. non-static), you cannot simply change function parameters at will |
| 10:31.50 | schmidts | wdoekes2 i know it was a more general question, for example there is an ast_change_something function also included in a header file and in two channel files |
| 10:32.56 | schmidts | if i want to change the behavior of this function is it a good idea to change the header and the two channel files (even when its only necessary in one channel file for exmaple) or as i said write a wrapper function which will be used only in this one channel file |
| 10:33.48 | schmidts | for me it would make more sense to change the function on every places it is called but i can understand that its not a good idea to do this, cause this could break "backwards compatibilty" |
| 10:34.22 | schmidts | or selfwritten modules using this function |
| 10:34.46 | wdoekes2 | indeed: ast_original(int parameter1) { ast_new(parameter1, default_parameter2); } is the way to go |
| 10:35.28 | schmidts | ok that was my question ;) |
| 10:35.29 | schmidts | thanks |
| 10:41.20 | schmidts | and another thing ;) |
| 10:41.41 | schmidts | static const int VS define ? imho its the same or does this make problems with older c compilers? |
| 10:44.53 | wdoekes2 | (1) there should be no problem with static const int and old compilers, (2) code is C99+, so old compilers are not considered, (3) const int adds type checking |
| 10:46.18 | wdoekes2 | having said that, I added a DEFAULT_UDPTLSTART #define instead of a static const int, for which I got no complaints |
| 10:47.28 | schmidts | i am only asking cause in an actual review it is changed back from static const to define |
| 10:50.00 | wdoekes2 | which? |
| 10:50.37 | schmidts | https://reviewboard.asterisk.org/r/1635 |
| 10:50.43 | schmidts | row 952 of pbx.c |
| 10:53.26 | wdoekes2 | I think that's the wrong fix to a signed-unsigned warning |
| 10:53.50 | wdoekes2 | although I don't like non-defines that are all-uppercase |
| 10:54.25 | schmidts | ;) |
| 10:54.26 | wdoekes2 | my fix would be to s/const int HASH_EXTENHINT_SIZE/const unsigned hash_extenhint_size/ |
| 10:56.41 | schmidts | sounds good to me ;) |
| 11:27.08 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:27.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:43.19 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:43.19 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:56.23 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 12:05.18 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 12:19.39 | merbanan | how do I close a channel if ast_queue_control(p->owner, AST_CONTROL_HANGUP) doesn't work ? |
| 12:22.39 | schmidts | merbanan why doesnt it work like expected? |
| 12:23.21 | merbanan | because the channel is started with ast_autoservice_start() |
| 12:24.37 | schmidts | then you should do ast_autoservice_stop() before queuing the hangup |
| 12:25.13 | schmidts | but AFAIK even in autoservice the channel should handle a queue control frame for hangup |
| 12:29.36 | merbanan | didn't work |
| 12:29.42 | merbanan | still get a stale channel |
| 12:30.11 | schmidts | hmm wrong refcounter values maybe |
| 12:31.43 | merbanan | no, the control frame is not processed correctly |
| 12:32.13 | merbanan | the hangup callback is never triggered |
| 12:32.30 | merbanan | is there some other way to get rid of a channel ? |
| 12:32.56 | schmidts | not a clean and proper one |
| 12:33.07 | schmidts | do you see something in core show locks? |
| 12:35.18 | merbanan | I don't have that command |
| 12:37.02 | merbanan | so to hangup I start the pbx in a hangup extension, that should work ... |
| 12:40.56 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:40.56 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 12:50.15 | merbanan | sort of worked, still got an active call refcounter |
| 13:09.38 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:09.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:22.44 | *** join/#asterisk-dev luckman212_ (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 13:38.10 | schmidts | to the guys at digium, i dont know if this is ok but it looks like a not working auto replacement in your news letter mailing: http://pastebin.com/wmnmX462 |
| 13:39.26 | blitzrage | schmidts: you'll need to email marketing about that I guess |
| 13:39.33 | blitzrage | none of which will be hanging out here |
| 13:40.05 | blitzrage | schmidts: probably via here: http://www.digium.com/en/company/contact/ |
| 13:40.38 | schmidts | blitzrage thanks ;) i allready thought nobody of them weill be on here, i was just wondering if this should look like this or not |
| 13:42.15 | blitzrage | probably not... |
| 13:42.36 | schmidts | as i thought ;) |
| 13:44.38 | blitzrage | schmidts: is it just me, or is the link to remove myself from the email list missing? |
| 13:44.46 | blitzrage | it is pretty early... I could just not be seeing it |
| 13:45.58 | schmidts | out of this mailing? |
| 13:46.26 | schmidts | blitzrage hehe :D i guess they dont want us to unsubscribe :D |
| 13:46.33 | schmidts | you are right, its not there |
| 13:48.21 | blitzrage | schmidts: oh wait -- it is there (just not immediately below the line like everything else) -- very bottom. I didn't see it, because it's below the signature... |
| 13:48.30 | schmidts | yes i also found it now ;) |
| 14:03.36 | *** join/#asterisk-dev vrban (~kris@2001:6f8:9c8:0:224:e8ff:fe20:d141) |
| 14:05.16 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-zdnoapfxokpucmtk) |
| 14:13.03 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 14:17.50 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-msnqnhmyfxedojca) |
| 14:17.50 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:21.14 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 14:24.49 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-plznwpqidfovrzgr) |
| 15:04.49 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:14.00 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:14.00 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:27.21 | *** join/#asterisk-dev joshaidan (~brianj@24.109.210.41) |
| 15:33.07 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:33.08 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:33.42 | schmidts | are there any known problems with moh when a call is set on hold with 1.8? |
| 15:34.44 | schmidts | channel(musicclass) is set and i also get the message Started music on hold class xyz on SIP/xxx |
| 15:34.59 | schmidts | but even with rtp debug on i dont see any rtp packets from asterisk to the phone which is on hold |
| 15:35.34 | jsmith | schmidts: Have you answered the channel yet? If not, you may need to call Progress() first |
| 15:36.21 | schmidts | jsmith ONHOLD the music before the calls is answered works fine, but when i put it on hold there is only silence |
| 15:36.44 | jsmith | Weird... |
| 15:36.54 | schmidts | with debug enabled i see a lot of these messages: |
| 15:36.55 | schmidts | [Dec 21 16:36:39] DEBUG[1161]: res_rtp_asterisk.c:2009 bridge_p2p_rtp_write: Remote address is null, most likely RTP has been stopped |
| 15:43.22 | schmidts | hmm i am just not sure but for sendonly is it ok to set c=IN IP4 to 0.0.0.0? imho yes? |
| 15:43.59 | jsmith | That looks right to me |
| 15:44.08 | jsmith | But I'll admit I haven't played with it in quite some time |
| 15:44.15 | *** part/#asterisk-dev vrban (~kris@2001:6f8:9c8:0:224:e8ff:fe20:d141) |
| 15:45.09 | schmidts | hm ok |
| 15:46.35 | schmidts | hmmm looks like something is broken |
| 15:49.01 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.29.44) |
| 15:58.41 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:58.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:03.13 | *** part/#asterisk-dev joshaidan (~brianj@24.109.210.41) |
| 16:03.41 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 16:03.47 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:03.47 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:04.19 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 16:42.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 16:45.57 | otherwiseguy | So, asterisk ignores SDP for a re-INVITE where the o= line has a version number that doesn't change. I just read through a capture that shows a BroadWorks device sending back a response with the session-id changing, but not the session-version. It should be easy enough to support even though I think it's wonky. Any opinions? |
| 16:46.32 | file | I think there's an option for that |
| 16:46.59 | otherwiseguy | file: there is an option to ignore sdp version for a peer in newer versions of Asterisk. |
| 16:47.44 | file | yay I'm not completely crazy |
| 16:47.45 | otherwiseguy | This is more a question of whether it makes since to check id and version to detect a change instead of just relying on version. |
| 16:48.23 | otherwiseguy | It seems wonky to change the session-id in the SDP when the purpose of a re-INVITE is to modify an existing session. |
| 16:48.40 | otherwiseguy | But, I can't find anything that says that you *can't* do that. |
| 16:48.42 | merbanan | if I do a ast_pbx_start() in context "test", how do I send it to another context afterwards ? |
| 16:54.27 | kpfleming | merbanan: ast_async_goto() |
| 16:56.51 | kpfleming | otherwiseguy: does RFC3264 (IIRC) even allow changes in the session-id? |
| 16:57.35 | file | I pointed him to that RFC (he was looking at SDP itself) |
| 16:57.42 | otherwiseguy | kpfleming: I was looking at the SDP rfc, and not the 3264 rfc. file pointed out ot me that 3264 does not allow it. |
| 16:57.56 | file | (I actually pasted a blob to him, did not want to flood the channel) |
| 16:58.19 | kpfleming | yay for great minds |
| 16:58.39 | file | I know that RFC more than I would like |
| 17:24.42 | Corydon76-work | pokes kpfleming |
| 17:25.33 | kpfleming | ouch |
| 17:25.40 | kpfleming | noogies Corydon76-work |
| 17:26.10 | Corydon76-work | Are you at work this week, and did you see my cert request? |
| 17:26.28 | kpfleming | i am, and i have that, but i need to forward it to Qwell, because he handles those now |
| 17:27.34 | kpfleming | and i am surprised it expired, as we generated new ones earlier this year (or late last year), with 3 year expirations |
| 17:28.26 | Corydon76-work | Ah, okay |
| 17:28.51 | Corydon76-work | SSL handshake failed: SSL alert received: Certificate is expired (https://origsvn.digium.com) |
| 17:29.14 | Corydon76-work | I forget the openssl command line to lookup the cert info |
| 17:29.14 | kpfleming | well, yeah |
| 17:29.28 | kpfleming | openssl pcks12 -text -in <file> -noout |
| 17:29.32 | Qwell | 12/14 |
| 17:30.18 | kpfleming | Qwell: if we've got certs expiring, i guess we need to pre-renew the ones that we know are being used and get them out to people, so they don't end up inconvenienced |
| 17:30.44 | Qwell | kpfleming: yes |
| 17:31.14 | otherwiseguy | grabs popcorn and watches the inconvenienced |
| 17:31.18 | Qwell | Corydon76-work: toss me a quick email, if you wouldn't mind |
| 17:32.19 | Corydon76-work | Sent |
| 17:41.01 | Corydon76-work | Qwell: much appreciated |
| 18:16.09 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:38.01 | tzafrir | sruffell, any news on DAHDI 2.6 ? |
| 18:54.16 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:54.16 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:12.20 | sruffell | tzafrir: umm..yes... |
| 19:12.43 | sruffell | anything you need to add to the release announcement, otherwise I can pull the trigger today (had intended to do it yesterday). |
| 19:33.06 | Corydon76-work | mjordan: ping |
| 19:33.26 | mjordan | Corydon76-work: pong |
| 19:33.52 | Corydon76-work | Remember that Heisenbug with the main/stdtime test? |
| 19:33.57 | mjordan | yup |
| 19:34.03 | Corydon76-work | It was a 3-line fix. |
| 19:34.25 | Corydon76-work | team/tilghman/verbose is the branch |
| 19:34.34 | mjordan | excellent |
| 19:34.58 | mjordan | what ended up being the problem? |
| 19:35.27 | Corydon76-work | I switched the notify which started the daemon to wait until Asterisk was fully booted, and it disappeared. |
| 19:35.50 | Corydon76-work | The problem was that the internal thread structure was getting reused for some odd reason |
| 19:36.14 | Corydon76-work | So since the thread structure was reused, the inotify thread wasn't getting any additional process time |
| 19:36.27 | Corydon76-work | Move it to the end of the boot cycle, and it's fine. |
| 19:36.43 | Corydon76-work | And no, nothing else is colliding when I do that. |
| 19:37.56 | Corydon76-work | I also verified that it was nothing to do with the taskprocessor code, because when I rearranged the init order, I got the thread collision to occur with another thread. |
| 19:38.19 | Corydon76-work | AND.... after talking this through, I know EXACTLY what happened. |
| 19:38.43 | mjordan | does it also resolve the problem with the remote asterisk no longer being updated with message output? |
| 19:39.40 | Corydon76-work | The time code is called with every log message, including log messages which are called before daemon(). When you call fork(), as daemon() does, only the calling thread remains active in the child process. So the inotify daemon was running in the parent, but not the child |
| 19:40.25 | Corydon76-work | And that's why the reuse occurred... because libc knows that only the calling thread remained. |
| 19:41.08 | Corydon76-work | mjordan: yes, that's only due to CLIs not returning control until the CLI invoked returns |
| 19:42.29 | Corydon76-work | And if the console continues to run, daemon is not called, no fork, so the thread remained active, because there is no parent-child in that case. |
| 19:43.09 | anonymouz666 | in a simple SIP call p->owner is the calling channel, right? |
| 19:44.29 | mjordan | Corydon76-work: my only concern is having something in the code that notes what has to occur before what, and what shouldn't be moved in the boot up sequence to prevent that from happening again. Other then that, since the patch was well reviewed already, I don't see any reason to go through the cycle again |
| 19:45.11 | Corydon76-work | mjordan: it's changed in main/stdtime/localtime.c, not in any part of the boot sequence |
| 19:47.15 | mjordan | right, but changing when / how things were logged - and depending on whether or not things were forked - caused a rather and nasty subtle bug that no one caught. While that's an artifact of the localtime daemon, that obviously wasn't a clear side effect of your changes |
| 19:47.37 | tzafrir | sruffell, sorry for the delay. |
| 19:48.10 | sruffell | np |
| 19:48.18 | tzafrir | I now notice that that span assignment / unassiggnment is a bit verbose |
| 19:48.29 | Corydon76-work | I'm adding a note to the code, now that I understand why it fixed the problem. |
| 19:50.42 | mjordan | cool, sounds good |
| 19:51.06 | tzafrir | oh well, we'll leave it for this release and demote it on the next one |
| 19:58.58 | tzafrir | I can't see many changges. A few more tickets should appear there |
| 19:59.17 | tzafrir | (the rhino one in dhadi-tools as well) |
| 20:01.45 | sruffell | hmm...ok |
| 20:23.45 | anonymouz666 | if p->owner is the parent channel, which one is the child channel ? |
| 20:24.34 | anonymouz666 | SIPA calls SIPB. p->owner is SIPA-001 |
| 20:25.03 | anonymouz666 | I wanna access SIPB->002 |
| 20:28.27 | kpfleming | from the SIPA channel you have no direct access to that, because there is no parent-child relationship |
| 20:28.47 | kpfleming | you can call ast_bridged_channel() to find out which channel you are bridged to, if any, but it's a bit risky as it can disappear |
| 20:30.12 | anonymouz666 | so if there is a variable set in a child channel after answer, how can parent channel be aware of that? |
| 20:30.40 | kpfleming | by doing what i just said... getting a pointer to the bridged channel, and inspecting its variable list |
| 20:33.01 | anonymouz666 | alright thanks, I will search for examples of ast_bridged_channel() |
| 20:36.33 | pabelanger | Q: setting SIP_PAGE2_FAX_DETECT means fax detect is off? |
| 20:37.21 | kpfleming | that doesn't seem logical |
| 20:37.56 | kpfleming | pabelanger: wait... setting it to *what*? |
| 20:37.58 | pabelanger | indeed, I don't see a flag to disable it. We default to SIP_PAGE2_FAX_DETECT, which according to sip.conf is the off |
| 20:38.03 | pabelanger | detectfax |
| 20:38.06 | pabelanger | err |
| 20:38.16 | kpfleming | it's a flag, it can have either a value of one or zero |
| 20:41.03 | pabelanger | Right, something is wrong in chan_sip.c because we change the value of faxdetect for both ast_true() and ast_false(), then process to set the flag as SIP_PAGE2_FAX_DETECT_BOTH |
| 20:41.20 | pabelanger | atleast in 1.8 |
| 20:42.03 | kpfleming | i think you are misreading the code |
| 20:42.08 | kpfleming | what lines are you referring to? |
| 20:42.22 | pabelanger | I see now |
| 20:42.47 | pabelanger | My eyes were not processing the ast_clear_flag() function |
| 20:43.28 | anonymouz666 | ooh, you have another thinking device |
| 20:52.47 | anonymouz666 | is it safe to: struct ast_channel *test; test = ast_bridged(channel(p->owner); if (test) { myvar = pbx_builtin_getvar_helper(test->name, "DIALPLANVAR"); } |
| 20:52.58 | anonymouz666 | then I can use myvar in p->owner |
| 20:54.29 | file | it won't be bridged. |
| 20:56.12 | anonymouz666 | this snippet will be inside sip_answer will be called when the channel is bridged... you mean even in that case if (test) will not be true? |
| 20:56.33 | file | probably not |
| 20:57.01 | mjordan | anonymouz666: read the description of ast_bridged_channel. It tells you what needs to be locked. |
| 20:57.57 | anonymouz666 | ended up locked |
| 21:01.34 | anonymouz666 | this code will not work because the logic is totally wrong, or I need to add some lock stuff to avoid deadlock? Just wanna to know if I am in the right way |
| 21:04.57 | mjordan | disregarding file's points about whether or not you'll actually have a bridged channel at that point, the function tells you that you have to have the channel (in this case p->owner) locked before calling ast_bridged_channel and that you have to keep it locked during the entire time you're using the bridged channel. As far as the bridged channel goes, if you're going to obtain mutable state from it as well, I would imagine you would a |
| 21:06.20 | anonymouz666 | it cuts after "would a" |
| 21:06.31 | mjordan | I would imagine you would also want to lock it. Otherwise, deadlocks aside, you have no guarantee that anything you attempt to get will be there in any deterministic fashion |
| 21:06.39 | mjordan | sorry, need to use less verbosity |
| 21:07.52 | anonymouz666 | thanks |
| 21:07.57 | anonymouz666 | I will try something this evening |
| 21:10.17 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 21:51.16 | *** join/#asterisk-dev schmidts (~sst@86.59.31.4) |
| 21:51.19 | schmidts | Hi folks |
| 21:51.44 | schmidts | i am just about to loose my mind, could someone with 1.8 please try if normal Music on hold is working? |
| 21:51.58 | schmidts | i really hope this is only my system but something looks just wrong |
| 21:52.10 | schmidts | i mean Moh as really when a call is set on hold |
| 21:54.40 | *** join/#asterisk-dev Tim_Toady (~fuzzy@188.4.57.16.dsl.dyn.forthnet.gr) |
| 21:58.10 | schmidts | btw moh when waiting for a channel to be answered works just as expacted but not when a call is put on hold??? |
| 22:03.05 | Corydon76-work | schmidts: there's more than one way to put a call on hold |
| 22:06.05 | schmidts | Corydon76-work For example invite with sendonly and IP4 set to 0.0.0.0 |
| 22:08.03 | schmidts | i will pastebin what happens |
| 22:08.05 | Corydon76-work | Right, so that one confines it to the SIP channel drive |
| 22:08.08 | Corydon76-work | +r |
| 22:08.16 | schmidts | yes |
| 22:08.42 | schmidts | and i see atleast that the call is put on hold (started moh class on channel xyz) state update ... |
| 22:08.42 | Corydon76-work | as opposed to call parking |
| 22:15.34 | schmidts | http://pastebin.com/G1HabPuY this is the sip debug of this problem |
| 22:16.38 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:16.38 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:19.24 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 22:19.24 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:22.00 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:22.00 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 22:22.22 | *** join/#asterisk-dev joshaidan (~brianj@24.109.210.41) |
| 22:22.34 | schmidts | any ideas anyone? |
| 22:35.19 | schmidts | ok its getting strange now :( with asterisk 1.8.7.1 it works |
| 22:50.10 | *** join/#asterisk-dev _schmidts (~schmidts@86.59.31.4) |
| 22:50.14 | _schmidts | damn mirc client :( |
| 22:51.22 | WIMPy | I remember someone saying: Even on Windows mirc is max 4th choice. |
| 22:52.00 | opticron | where is telnet on that list? |
| 22:52.17 | WIMPy | :-) |
| 22:53.36 | _schmidts | above it opticron, above! |
| 22:53.43 | Corydon76-work | has actually used telnet to IRC... |
| 22:54.24 | WIMPy | Did you at least have some F-key for PONG? |
| 22:56.54 | Corydon76-work | WIMPy: that's cheating |
| 22:59.57 | Corydon76-work | WIMPy: you were one of the people having problems with the verbose patch, correct? |
| 23:00.29 | WIMPy | yes |
| 23:01.06 | Corydon76-work | It's now in a team branch, and the problem that mjordan found has now been fixed. Would you care to try it out? |
| 23:01.16 | Corydon76-work | It's in /team/tilghman/verbose |
| 23:05.25 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-msnqnhmyfxedojca) |
| 23:12.20 | WIMPy | Not looking too good. |
| 23:13.51 | WIMPy | Hmm. Not exactely sure what it does. |
| 23:15.12 | WIMPy | Looks like the verbose cannot be changed frm CLI above the configured level. |
| 23:17.46 | WIMPy | Partially. |
| 23:18.27 | WIMPy | Some things like dialplan execution seem to use the smaller of the configured and the interactively ser verbose. |
| 23:18.55 | Corydon76-work | Your local CLI verbosity level is changed with 'remote set verbose' |
| 23:19.12 | WIMPy | But the Playing messages seem to only care about the configured verbose and not care about the interactively set value at all. |
| 23:19.24 | WIMPy | Oh. |
| 23:19.26 | WIMPy | ok. |
| 23:19.30 | Corydon76-work | Which messages are those? |
| 23:19.58 | WIMPy | <channel> Playing <sample> (language) |
| 23:20.27 | Corydon76-work | Local verbosity level defaults to 0 and increments with each -v specified on the command line, but also can be tweaked with the above CLI. |
| 23:20.58 | WIMPy | Hmm. No the seems to be a random element to it. |
| 23:21.36 | Corydon76-work | There may be some verbose messages that are at level 0 |
| 23:21.51 | Corydon76-work | Because they have no prefix and are still using the old syntax |
| 23:23.19 | WIMPy | ist still a little confused abotu the core vs remote set verbose thing. |
| 23:23.36 | WIMPy | But apart from that 'sip show peers' produces no output. |
| 23:23.39 | Corydon76-work | core verbose is the verbosity on the core console |
| 23:24.05 | Corydon76-work | Odd, because 'sip show peers' uses ast_cli, not ast_verbose() |
| 23:24.22 | WIMPy | So that should only make a differenc if you start asterisk -c? |
| 23:24.33 | Corydon76-work | Right |
| 23:24.53 | WIMPy | restarte the remote console and now I get sip show peers. |
| 23:25.10 | WIMPy | Let's see if I find out how to break it. |
| 23:25.15 | Corydon76-work | Oh, were you still running the old console? |
| 23:25.47 | WIMPy | Ok, but core set verbose did make a difference. See the beginning. |
| 23:26.07 | WIMPy | No, I restarted it multiple times changing verbose in asterisk.conf. |
| 23:26.38 | Corydon76-work | Ah, yes, because that file affects both core and remote consoles |
| 23:28.26 | WIMPy | Ugh |
| 23:28.50 | Corydon76-work | It gets read on startup in either case |
| 23:29.15 | Corydon76-work | Basically, those are implicitly passed command line options |
| 23:30.19 | WIMPy | I had 'sip show peers' working. then I did 'core set verbose 0', thereafter 'sip show peers' remains silent. |
| 23:30.41 | WIMPy | oops wrong. |
| 23:30.50 | WIMPy | I had 'sip show peers' working. then I did 'remote set verbose 0', thereafter 'sip show peers' remains silent. |
| 23:30.54 | Corydon76-work | Yeah, I just tried it and it worked for me |
| 23:30.55 | WIMPy | That way. |
| 23:31.31 | WIMPy | Now after 'remote set verbose 4', 'sip show peers' still didn;t produve output, but after a call it did again. |
| 23:32.10 | WIMPy | Now it seems to work straight after increasing verbose, even without a call. |
| 23:32.34 | Corydon76-work | That's weird and unexpected. I have no idea why that would be the case, because ast_cli output goes through a different medium than ast_verbose() |
| 23:33.24 | Corydon76-work | That is, ast_verbose() has a prefix, but ast_cli does not |
| 23:33.51 | WIMPy | What I can tell you is that with the previous version, things like 'sip show peers' or 'core show application ...' worked until the first call came in and never after. |
| 23:35.02 | WIMPy | But I don't see any relation to calls now. Or only that one time. |
| 23:36.15 | Corydon76-work | That's just bizarre |
| 23:36.50 | WIMPy | I have more random features recently. |
| 23:37.29 | WIMPy | Since a few days, I have one (and only one as far as I can see) SIP peer where the caller ID gets garbled. |
| 23:37.53 | WIMPy | The name is set to the first word of the name and the number is set to the account name. |
| 23:38.00 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 23:38.50 | WIMPy | But all users use templates, so it's only [user];secret=...;callerid=... and even that part is auto-generated. |
| 23:39.07 | WIMPy | So I have absolutely NFI why only one of them behaves differently. |
| 23:39.41 | WIMPy | sip show peer shows the correct value. |
| 23:41.27 | Corydon76-work | That should be fun to track down |
| 23:41.51 | WIMPy | has no doubts about that. |
| 23:42.22 | WIMPy | Ok, F*** |
| 23:43.14 | WIMPy | I just did 'remote set verbose 0' again and then 'sip show peers' and it worked. Then I immediately did 'sip show peers' again and it didn't/ |
| 23:43.31 | WIMPy | So there seems to be some sort of delay. |
| 23:44.10 | WIMPy | well, probably some certain other thing that happens frequently. |
| 23:44.17 | Corydon76-work | That sounds more like you have deadlock issues in chan_sip |
| 23:44.55 | Corydon76-work | When the CLI doesn't respond, it's usually because it's waiting for some kind of lock (or for the previous output to complete) |
| 23:45.00 | WIMPy | Well, 'remote set verbose 3' and it works again. |
| 23:45.15 | WIMPy | It did respond. |
| 23:45.31 | WIMPy | The prompt cam immediately. Just no output from the command. |
| 23:45.58 | Corydon76-work | Yes, but the prompt is generated locally. The command is run remotely |
| 23:46.41 | WIMPy | ok, but increasing verbose makes the output visible again. |
| 23:47.41 | WIMPy | Yikes. |
| 23:48.12 | WIMPy | Mometimes verbose 3 in enough to make it work. But I just had to go from 3 to 4 to make it work. |
| 23:48.22 | WIMPy | This is very strange. |
| 23:48.39 | Corydon76-work | Actually I suspect doing nothing will make it work, and the commands you're running are just happenstance |
| 23:49.24 | WIMPy | But it only fails after decreasing verbose. |
| 23:51.00 | Corydon76-work | I suspect that's happenstance, as well |
| 23:51.03 | WIMPy | Oh, and BTW: I find using "remote" on a remote console confusing. That would impy changing the core to me. "local" seems more apropriate to me. |
| 23:51.22 | Corydon76-work | "local" is already taken for the Local channel commands |
| 23:51.27 | WIMPy | So any idea what I should try? |
| 23:52.00 | WIMPy | Hmm, yes. |
| 23:52.32 | Corydon76-work | I need to duplicate your results in order to find a fix |
| 23:52.57 | Corydon76-work | So far, I haven't seen any of this stuff |
| 23:52.58 | WIMPy | cli set verbose? |
| 23:53.27 | Corydon76-work | Are you starting Asterisk with or without a console? |
| 23:53.38 | WIMPy | without |
| 23:53.44 | Corydon76-work | Same here |
| 23:54.19 | WIMPy | Started by hand with 'asterisk -g'. |