| 00:04.14 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 00:12.37 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 03:51.27 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 03:51.27 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 04:13.14 | snuff-work | mm.. did somethin v wrong in my config work for named group.. blew up 4 times :) |
| 05:57.22 | wedhorn | snuff-work: you trying to do it through the dial plan or directly? |
| 05:58.49 | snuff-work | nah.. it didn't like me destroying my namedgroup.. |
| 05:59.16 | snuff-work | after i removed my 'unref' of named group fields it seems happy |
| 06:03.16 | snuff-work | http://pastebin.ca/2294191 |
| 06:04.39 | snuff-work | its weird though.. my crashes dont immediately point @ my unref.. lookin @ bt |
| 06:06.17 | snuff-work | so it may have been caused by doing stuff on my devices before they properly re-regged with * |
| 06:07.54 | wedhorn | okay, so just to confirm, that code is purely to add vars to a channel (based on skinny.conf) |
| 06:08.01 | snuff-work | yep |
| 06:08.32 | snuff-work | i think most my crashes were to being impatient and tryin to use device befor skinny was ready.. |
| 06:10.55 | snuff-work | http://pastebin.ca/2294193 |
| 06:11.05 | snuff-work | that was from 2 of my crashes |
| 06:13.12 | wedhorn | they don't seem to have anything to do with the patch |
| 06:13.53 | wedhorn | the question is why asterisk is rejecting the devices |
| 06:14.30 | snuff-work | trying to use non-existant line.. |
| 06:14.40 | snuff-work | aka the phones don't think they lost ccm connectivity |
| 06:14.43 | wedhorn | have you tried a clean start (including cycling the devices)? |
| 06:15.10 | snuff-work | so chan_skinny doesn't like em :) |
| 06:15.12 | snuff-work | i haven't |
| 06:15.19 | snuff-work | but i have tested since and it works fine |
| 06:15.22 | wedhorn | worth a try |
| 06:16.04 | snuff-work | ok tested full thing.. did a pickup with that unref in.. seems to work.. now to reload skinny see if it goes boom |
| 06:16.21 | snuff-work | nope.. stayed alive this time |
| 06:16.37 | snuff-work | must just have had bad timing |
| 06:16.47 | wedhorn | I wouldn't rely on the reload working all the time, I've had a couple "mishaps" |
| 06:16.58 | snuff-work | so i'm now running fine with the patch i posted including unref part |
| 06:17.41 | snuff-work | if ur interested in the bt fulls i can provide em |
| 06:19.16 | wedhorn | I assume you're talking about the ast_unref_namedgroups |
| 06:19.20 | snuff-work | yes |
| 06:19.36 | wedhorn | I've a hard time working out the logic there |
| 06:19.52 | wedhorn | why would you want to unref something you haven |
| 06:19.57 | wedhorn | 't reffed |
| 06:20.00 | snuff-work | u have.. |
| 06:20.07 | snuff-work | when u do a 'set' |
| 06:20.12 | snuff-work | it sets a ref of 1 |
| 06:20.40 | snuff-work | when u do the unref.. there is now 0 refs.. and ao2 will cleanup |
| 06:21.19 | wedhorn | okay, but the logic of leaving the ref (channel.c) escapes me |
| 06:21.26 | wedhorn | in channel.c |
| 06:21.59 | wedhorn | and for that matter, why can |
| 06:22.10 | wedhorn | 't you just unref after calling set? |
| 06:22.24 | snuff-work | if i unref.. it will destroy the object |
| 06:22.35 | snuff-work | as there is no ppl using it |
| 06:22.53 | snuff-work | see astobj2.c / astobj2.h |
| 06:23.05 | wedhorn | I'd prefer not to ;) |
| 06:23.12 | snuff-work | soon as ur refcount = 0 .. ur ded |
| 06:24.23 | snuff-work | but the named group does work :) |
| 06:24.43 | wedhorn | ah okay, think I get it |
| 06:25.13 | wedhorn | so the groups are stored in and ao2 object attached to the line |
| 06:25.14 | snuff-work | trying to think of any other feature i need on these phones.. conf button i guess.. which is more dialplan shortcut |
| 06:25.16 | snuff-work | yep |
| 06:25.59 | wedhorn | okay, makes sense then, brain had it as a text object that you were trying to get out of an ao2 object |
| 06:26.08 | snuff-work | :) |
| 06:28.02 | wedhorn | hangon, but you seem to be "setting" in skinny_new |
| 06:28.14 | wedhorn | which is per channel |
| 06:28.37 | wedhorn | and unreffing on module unload (which is once per many channels) |
| 06:29.24 | snuff-work | so where u kill channels? |
| 06:29.41 | wedhorn | ah hangon |
| 06:29.43 | snuff-work | i think i was looking for it at one stage.. all i found was the end |
| 06:29.53 | wedhorn | a lot further down |
| 06:30.17 | wedhorn | skinny_hangup |
| 06:30.56 | wedhorn | about line 4483 |
| 06:31.02 | snuff-work | yer i see it now |
| 06:33.24 | wedhorn | if you wanted to do it a bit earlier, you could include it in 'setsubstate' SKINNY_ONHOOK |
| 06:33.53 | wedhorn | about line 5206 |
| 06:34.02 | wedhorn | you probably be nicer there anyway |
| 06:35.05 | wedhorn | or maybe skinny_hangup is better given it's chan stuff |
| 06:35.11 | wedhorn | has no idea |
| 06:35.45 | snuff-work | mm |
| 06:36.19 | snuff-work | i think hangup is better.. since it does other channely stuff |
| 06:37.57 | snuff-work | so we'd add struct skinny_line *l = sub->line; l->named_callgroups = ast_unref_namedgroups(l->named_callgroups); |
| 06:38.06 | snuff-work | somethin like that yer? |
| 06:39.20 | snuff-work | sub->line->named_pickupgroups = ast_unref_namedgroups(sub->line->named_pickupgroups); |
| 06:40.03 | wedhorn | hang on |
| 06:40.30 | snuff-work | we'll find out.. it compiled :) |
| 06:40.48 | wedhorn | hehe, test of all tests |
| 06:41.01 | snuff-work | still works |
| 06:41.12 | wedhorn | not sure it's right though |
| 06:41.14 | snuff-work | not looking @ comand prompt :) |
| 06:41.33 | snuff-work | that 'sounds' right though.. |
| 06:41.43 | wedhorn | you call ast_get_namedgroups for the line |
| 06:41.59 | wedhorn | should the unref'd when you are finished or not? |
| 06:42.34 | wedhorn | you call ast_channel_named_callgroups_set on the chan |
| 06:42.38 | wedhorn | should the unref'd when you are finished or not? |
| 06:43.18 | wedhorn | my guess is that the chan cleanup will probably get rid of the ao2 stuff and so it's not required, but just a guess |
| 06:43.47 | wedhorn | if the get on the line doesn't ref, you shouldn't unref... |
| 06:46.41 | snuff-work | now i'm confused lol |
| 06:46.57 | wedhorn | makes two of us |
| 06:47.35 | snuff-work | yer.. if i call the 'unref' on a per chan basis.. my peer has lost its pickupgroup |
| 06:48.01 | wedhorn | line->named_callgroups appears to be an ao2 object so should be unref'd when unloading |
| 06:48.18 | wedhorn | you seemed to have that |
| 06:48.18 | snuff-work | yep which is what i do atm |
| 06:49.28 | wedhorn | each new chan gets it set, which I'm not sure whether it copies the object or just points to it |
| 06:49.55 | snuff-work | i have a feeling it.. (looks code) |
| 06:50.02 | wedhorn | if it just points, or chan cleanup deals with ao2 objects, you can ignore the cleanup |
| 06:50.41 | wedhorn | I think is just added a bunch of confusion that wasn't required |
| 06:51.34 | wedhorn | but I would say it's the get that creates the object that needs to be cleaned, not the set... |
| 06:52.09 | snuff-work | ok.. looking @ code.. |
| 06:52.33 | snuff-work | the callgroups_set does a unref on new temp channel to clear any data.. |
| 06:52.52 | snuff-work | then just adds a reference to the underlying line |
| 06:53.09 | snuff-work | see 1081 main/channel_internal_api.c |
| 06:57.59 | wedhorn | still don't know whether the channel cleanup does an unref |
| 06:59.51 | snuff-work | well i kinda proved if i put it in the hangup part (of a channel) it killed the value when i show my lines |
| 07:00.14 | snuff-work | after my 1st call |
| 07:00.40 | wedhorn | the chan destructor has 'ast_channel_named_callgroups_set(chan, NULL);' at the end |
| 07:01.09 | snuff-work | yep which means that it would kill its ref to the object |
| 07:01.16 | wedhorn | yep |
| 07:01.30 | snuff-work | so my original location still winner :) |
| 07:01.37 | wedhorn | so can ignore the chan cleanup, just have the line cleanup on unregister |
| 07:01.41 | wedhorn | yep |
| 07:02.06 | wedhorn | cool, an hour to end up back where you started.... |
| 07:02.51 | snuff-work | all good |
| 07:03.40 | wedhorn | so now you've just got to code the dialer stuff (and work out how to differentiate between numerical and named pickups) |
| 07:04.03 | snuff-work | nope don't need to do any of that |
| 07:04.22 | snuff-work | the ast_pickup_call does a check of the number ones then named |
| 07:04.43 | snuff-work | basically that patch i posted is all that's req for named call/pickup groups |
| 07:04.47 | wedhorn | ah okay, easy |
| 07:18.18 | snuff-work | i'm off.. enjoy ur evening ;) |
| 07:26.16 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 07:26.17 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 08:21.13 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:19c5:15a8:9476:34dc) |
| 08:22.07 | *** join/#asterisk-dev Jamess (43ff1776@gateway/web/freenode/ip.67.255.23.118) |
| 08:22.15 | Jamess | Good morning :D |
| 08:23.47 | Jamess | I'm not sure this is the right place to turn or not, though it does seem like a good place to start. I'm looking for someone to move my asterisk setup to a new host. I've got some custom configurations in place so I need someone relatively experienced. If anyone's interested in a bit of work, be sure to message me :) |
| 08:28.42 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 08:28.42 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 08:29.56 | Jamess | I've got to step out for a bit, if anyone is interested in performing the migration for me (it is of course a paid gig) please feel free to e-mail me directly: scott.stapley@gmail.com |
| 08:30.02 | Jamess | so long for now |
| 08:45.12 | *** join/#asterisk-dev Tim_Toady (~fuzzy@194.50.55.200) |
| 08:50.10 | *** join/#asterisk-dev schmidts (~schmidts@vie-086-059-105-021.dsl.sil.at) |
| 08:50.12 | schmidts | good morning |
| 10:15.35 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 10:54.41 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 10:54.42 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 13:06.46 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:06.46 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:48.29 | b3nt_pin | I was reading the comments in astobj2.h (gasp!) and the comment about OBJ_NODATA for ao2_t_callback seems like it has been the viction of an editor "twiddle"... |
| 13:49.28 | b3nt_pin | it reads "on match, do return an object Callbacks use OBJ_NODATA as a default functions such as find() do |
| 13:51.22 | b3nt_pin | probably should be "on match, do return an object. Functions such as find() use OBJ_NODATA as a default"...maybe? |
| 13:56.14 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-cvienvakradydvum) |
| 14:28.38 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:28.38 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:33.48 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ithraakdfgqefloh) |
| 14:33.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:02.40 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:02.40 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:24.05 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:24.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:32.57 | *** join/#asterisk-dev Sean-Der (~sean@64.31.78.5) |
| 15:42.39 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ryuflrnvtkxxsbjc) |
| 16:23.36 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:23.37 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:46.01 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:47.28 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:47.28 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 17:58.27 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 18:10.10 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:10.10 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:14.54 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 18:53.13 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ithraakdfgqefloh) |
| 22:38.16 | snuff-work | wonders what this 'sorcery' branch is.. |
| 22:39.20 | file | it's a generic data access layer initially for use by the new chan_sip, but it's generic in nature so it could be applied to other stuff |
| 22:39.40 | file | it unifies the configuration API, realtime API, and other stuff to allow object creation/retrieval/updating/deleting |
| 22:39.58 | snuff-work | ah apt name then for a branch :) |
| 22:40.03 | snuff-work | *the |
| 22:40.35 | file | :D |
| 22:47.35 | russellb | CRUD |
| 22:48.53 | snuff-work | evening russellb |
| 22:50.09 | russellb | hi |
| 22:50.24 | *** join/#asterisk-dev skirmisha (~vk@46.47.82.189) |
| 22:50.31 | snuff-work | how's the land of redhat? |
| 22:50.54 | russellb | very red |
| 22:50.57 | russellb | and hatty |
| 22:51.23 | snuff-work | the balance sheet is very black which is always a nice thing @ a place u work :) |
| 22:51.37 | *** join/#asterisk-dev skirmisha (~vk@46.47.82.189) |
| 22:52.39 | snuff-work | i'm trying to figure out something.. if i connect to asterisk via usual asterisk -r.. |
| 22:53.07 | snuff-work | do core set debug 5.. i never actually see any debug msgs |
| 22:53.52 | snuff-work | but in my asterisk log file for debug msg i see stuff.. |
| 22:53.58 | snuff-work | but i could be 'doin it wrong' |
| 22:54.03 | snuff-work | been a while |
| 22:56.24 | snuff-work | mm i think i doing somethin wrong.. nm |
| 22:59.03 | putnopvut | Do you have a "console" line in your logger.conf that has "debug" as one of the values? |
| 22:59.10 | putnopvut | That's usually the issue. |
| 22:59.29 | snuff-work | nope |
| 23:00.26 | snuff-work | if i turn that on though.. does it restrict the levels correctly |
| 23:00.42 | snuff-work | like verbose does |
| 23:00.44 | putnopvut | If I understand your question, yes. |
| 23:00.48 | snuff-work | i guess i should try it :) |
| 23:01.02 | putnopvut | In other words, putting "debug" in logger.conf will not automatically make debug level messages appear. |
| 23:01.08 | snuff-work | k |
| 23:01.11 | putnopvut | You have to also set "core set debug 5" or whatever. |
| 23:01.28 | snuff-work | i thought that should be the case |
| 23:03.15 | *** join/#asterisk-dev skirmisha (~vk@46.47.82.189) |
| 23:03.35 | skirmisha | hi guys |
| 23:03.47 | skirmisha | how can i use sin_addr in pbx.c? |
| 23:04.03 | skirmisha | can i use it directly without defining it |
| 23:05.22 | putnopvut | skirmisha: I don't understand the question, specifically "without defining it" |
| 23:07.00 | skirmisha | i see in chan_sip.c sin_addr is used, but i am not sure whether i have to invoke or include some function/header |
| 23:07.19 | skirmisha | i just want to use it in same way as in chan_sip.c |
| 23:07.42 | skirmisha | is that possible or i have to some extra work before that |
| 23:08.34 | putnopvut | Okay, well, sin_addr is a field in struct sockaddr_in. I'd be willing to bet that struct sockaddr_in is included in some header that pbx.c includes already, so you should be able to use it directly. |
| 23:08.55 | putnopvut | However, I would discourage its use and instead encourage the use of ast_sockaddr in include/asterisk/netsock2.h |
| 23:09.20 | putnopvut | That way, you get some nice methods to be able to print, compare, look up, etc. Plus it supports IPv6 |
| 23:09.26 | putnopvut | sockaddr_in is IPv4 only. |
| 23:12.55 | skirmisha | great, thanks a lot. Let me test it |
| 23:43.33 | skirmisha | ok i am a bit new to programing, but is there a way to get the ip address from given channel? Or at least to pass it to pbx.c |
| 23:44.06 | skirmisha | i see in pbx.c i can use - c->exten, c->context, c->name |
| 23:44.17 | skirmisha | but how can i get the ip of that msg |
| 23:45.48 | putnopvut | Since an ast_channel can come from any technology, including non-VoIP ones, it's not possible to get an IP address of a channel outside of a specific channel driver that has a tech_pvt that has IP address information. |
| 23:48.24 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:48.24 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:49.32 | skirmisha | ok, then in other words, from a given channel is it possible to pass it to ast_channel struct? |
| 23:53.25 | putnopvut | I don't really understand the question. What are you trying to pass to the ast_channel struct? |
| 23:56.35 | skirmisha | from chan_sip.c i want to pass to ast_channel struct the ip of the call so in pbx.c when i call that struct to have like c->ip (ast_channel *c) |
| 23:57.07 | putnopvut | Why do you want that information in pbx.c? Why not just use what's already in chan_sip.c? |
| 23:57.41 | skirmisha | because pbx.c reports when there is no route or invalid number in context |
| 23:58.16 | skirmisha | so i have call to ext c->ext in pbx.c etc... |
| 23:58.25 | skirmisha | and i want to see src ip of that call |
| 23:58.39 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:58.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:59.35 | skirmisha | the exact log is - Channel '%s' send into invalid extension.... |
| 23:59.39 | skirmisha | that is in pbx.c |
| 23:59.45 | skirmisha | and i want to see that call ip |