| 06:07.25 | *** join/#asterisk-dev jbot (i=ibot@rikers.org) |
| 06:07.25 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and Tier 3.14159265 support is in #asterisk -=- Leif Madsen is now the Open Source Release and Issue Tracker Manager. Blame all problems you find on him. That is all. -=- http://xkcd.com/303/ |
| 06:22.33 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 06:44.15 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 06:54.54 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:54.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:13.22 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 07:33.21 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:33.21 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:01.31 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:01.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:06.04 | oej | Morning, folks |
| 08:11.43 | *** join/#asterisk-dev Dovid (n=annon@tony09-118-62.inter.net.il) |
| 08:27.48 | mvanbaak | mornin oej |
| 08:42.20 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 08:43.00 | philipp64 | Corydon76-dig: howdy. |
| 08:43.58 | philipp64 | smurf: do you know tilghman's handle? |
| 08:46.30 | oej | They're propably asleep |
| 08:46.42 | philipp64 | as I should be. sigh. |
| 08:47.03 | oej | It's morning, Philipp64. And a good one too! |
| 08:47.32 | philipp64 | that was a really handy thing he did... with the Makefile that allows 3rd party modules built out-of-tree. |
| 08:47.43 | philipp64 | well, it's 0:44 where I am. |
| 08:48.05 | philipp64 | new moon... but it's below the horizon anyway. |
| 08:48.18 | oej | Yes, Corydon is a very clever man |
| 08:48.36 | oej | And a very nice person |
| 08:49.03 | philipp64 | it was Tilghman that did it... |
| 08:49.27 | philipp64 | I was wondering if Corydon knew (obviously) Tilghman's handle, in case he was online... |
| 08:50.02 | philipp64 | this is what the fuss is about: http://svncommunity.digium.com/view/tilghman/branches/1.4/Makefile?revision=11&view=markup |
| 08:52.11 | philipp64 | makes it a lot easier for us to build custom embedded images with only the apps/resources the user wants. |
| 08:52.44 | oej | Corydon == Tilghman |
| 08:52.58 | philipp64 | ah... well... that was a coincidence, then. |
| 08:53.05 | oej | :-) |
| 08:53.18 | philipp64 | I remember he answered a query I had here a couple of months ago... |
| 08:53.23 | oej | Yes |
| 08:53.25 | philipp64 | SIP/NAT interaction, I think... |
| 08:54.22 | oej | <PROTECTED> |
| 08:54.24 | philipp64 | the unpleasant thing about owning a distro is you get to scratch the surface of about 200 packages... but never become an expert in any of them. |
| 08:54.37 | oej | What distro do you work with? |
| 08:54.38 | philipp64 | you just dig deep enough to fix things (sort of) and move on. |
| 08:54.42 | philipp64 | Astlinux. |
| 08:54.52 | philipp64 | Yeah, the NAT thing is. |
| 08:54.55 | philipp64 | it's weird. |
| 08:55.03 | oej | Kristians old project |
| 08:55.11 | philipp64 | If I use the iptables NAT conntrack helper, then incoming/outgoing calls work fine. |
| 08:55.13 | oej | Well, if you have SIP issues, I'm the man :-) |
| 08:55.17 | philipp64 | 2-way voice... |
| 08:55.33 | oej | SIP audio and iptables is ... hard. |
| 08:55.43 | philipp64 | if I enable voice menus, then the outside calling party can't hear me when I pick up. |
| 08:55.56 | philipp64 | at least, not on my testbed. |
| 08:56.38 | philipp64 | it could be a defect in the Coppercom we're terminating SIP into the PSTN with... (we use SIP phones behind our Astlinux box which serves as PBX and firewall/router). |
| 08:57.00 | philipp64 | (and yes, Kris has let me take a bigger role in this, since he's got his plate full...) |
| 08:57.27 | philipp64 | it could also be a problem with the way that the Telco has their SBC configured... |
| 08:57.54 | philipp64 | they might not be equipped to handle multiple invites in the same call. |
| 08:58.10 | philipp64 | any of this sound plausible? or am I talking out of my hat? |
| 09:02.24 | philipp64 | I was thinking of adding code to channel/chan_sip.c to diddle the NAT tables directly... using the iptc library to do this directly. |
| 09:02.59 | philipp64 | in our situation, having asterisk be co-resident with the NATting firewall is quite common. |
| 09:03.10 | philipp64 | don't know how handy it would be for everyone else, though. |
| 09:05.46 | oej | philipp64: we discussed that in depth and wrote a proposal at astridevcon |
| 09:06.05 | oej | We used to have a special version of Asterisk that did some of that stuff with the midcom protocol |
| 09:06.54 | oej | Check http://astridevcon.pbwiki.com/Network-Security-Framework |
| 09:06.57 | philipp64 | I looked at that paper... that's a lot more complexity than what I'm trying to do. |
| 09:08.06 | oej | Well, if you want to control audio, it's not chan-sip, it's more rtp.c - but I would say a combination of them. |
| 09:08.11 | philipp64 | if I wanted a "skinny" fix, would it be easier to add it as functionality to chan_sip.c... or make it a cooperating resource than can be compiled-out? and which is more likely to be accepted back into the tree? |
| 09:08.51 | philipp64 | we don't actually need to diddle with rtp, as I understand it. |
| 09:08.53 | oej | I wouldn't know at this point. I would say that anything inline with that document would happily be accepted. |
| 09:09.04 | oej | But anything else, it depends on the architecture and severity. |
| 09:09.16 | philipp64 | just make sure that the mappings in the INVITES gets correctly reflected back to the kernel so it knows where to send the streams. |
| 09:09.34 | oej | the streams are RTP audio, so you care about that. |
| 09:09.36 | oej | :-) |
| 09:09.57 | philipp64 | right... but I think I can get by without modifying the RTP data itself. |
| 09:10.16 | philipp64 | I just need to peek into the SDP info in the SIP messages to keep track of the associations. |
| 09:10.25 | oej | Yes, but you need to know which ports to open, and rtp.c is the only place that knows that. |
| 09:11.15 | philipp64 | if the ports are open locally, then NATting isn't an issue, right? because we'll be talking on the public interface to the PSTN. |
| 09:11.54 | philipp64 | it's the case where the Asterisk box isn't in the media stream that it needs to be able to manipulate the NATting tables. |
| 09:12.39 | oej | Asterisk is always in the media stream at start, and will be back if the call goes on hold |
| 09:12.45 | philipp64 | (well, of course the box is in the path... but only as a router... the packets are addressed between the PSTN SIP switch, and the handsets on the NATted LAN...) |
| 09:12.52 | philipp64 | sure. |
| 09:12.53 | oej | So you will always need to manipulate iptables back and forth |
| 09:13.15 | philipp64 | it's the moment that the call is directly between the handset and the PSTN that the audio seems to go south. |
| 09:13.34 | oej | I guess that the provider doesn't do symmetric RTP then |
| 09:13.46 | philipp64 | and INVITE's will clue me in to whether I'm in the path or not, right? |
| 09:13.52 | philipp64 | or am I missing something? |
| 09:14.14 | philipp64 | ("symmetric RTP?") |
| 09:14.40 | oej | Well, INVITEs say bit of the truth, but not always. |
| 09:15.27 | oej | Like if you have NAT=yes, Asterisk will not bother with the SDP much, since the device behind NAT will send us audio from somewhere else. As soon as we receive it, we will start sending to that IP address and port. |
| 09:15.29 | philipp64 | I always thought that RTP was two simplex streams... |
| 09:15.37 | oej | That's why you need to be aware of what's going on inside rtp.c |
| 09:15.48 | oej | RTP is two streams in each direction - RTP and RTCP. |
| 09:16.10 | oej | RTCP will in the case of NAT go on any port, otherwise it's common to send it on the RTP port + 1 |
| 09:17.14 | oej | But we generally listen on the port we send in the SDP and on the same port as we send from, so there are multiple choices for where incoming audio is arriving. |
| 09:17.23 | philipp64 | ok. well, I haven't had time to look into this in depth (still waiting on my Telco to provide me an extra DID for testing). |
| 09:18.00 | philipp64 | other than the RFC's, is there a handy description of the flows? |
| 09:18.02 | oej | SIP and NAT is black magic. |
| 09:18.16 | oej | Hmm. Good question. |
| 09:18.33 | philipp64 | (I'm hoping to fix that and make it idiot proof... at least in the co-resident case of Asterisk sitting on the edge device.) |
| 09:18.54 | philipp64 | and can I follow up on this with you via email as I dig deeper? |
| 09:18.56 | oej | There are many, many documents out there. I am not the right person to help you find a document. I look at the source... |
| 09:19.08 | oej | Feel free to contact me. |
| 09:19.14 | philipp64 | what's your email? |
| 09:19.31 | oej | oej at edvina.net |
| 09:20.33 | philipp64 | ok, thanks. I'm philipp at redfish-solutions.com |
| 09:23.39 | philipp64 | hmmm... http://www.newport-networks.com/cust-docs/33-NAT-Traversal.pdf |
| 09:23.56 | oej | Good luck digging then. If you have time, take a look at the old -firewall stuff (midcom) that will alert you about the hooks needed and where those are |
| 09:24.22 | philipp64 | where is it? |
| 09:33.30 | oej | http://svn.digium.com/view/asterisk/branches/1.2-netsec/ |
| 09:33.39 | oej | Seems like I've deleted my branch 1.4-netsec |
| 10:00.41 | synthetiq | ast_safe_sleep locks the channel? I am looking for an internal asterisk function to have a channel sleep (but still do audio, sip packet processing etc) that does something after x seconds |
| 10:10.36 | *** join/#asterisk-dev c0rnoTa (n=c0rnoTa@80.251.113.56) |
| 10:18.58 | oej | Means that you don't want to sleep at all, but schedule something in the future |
| 10:36.44 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:41.06 | wedhorn | mvanbaak: when you get a chance. What was the idea behind |
| 10:41.10 | wedhorn | M14325 |
| 10:41.16 | MuffinMan | Failed to retrieve issue page for 14325. Try again later. |
| 10:41.42 | wedhorn | ok, the reordering of skinny device and lines and skinny.conf.sample |
| 10:42.12 | wedhorn | the skinny code already parses the line stuff first, regardless of the order in the conf file. |
| 10:42.57 | wedhorn | And the reload stuff, noticed russelb's comments, may be worth waiting till we get the new locking working |
| 10:43.33 | synthetiq | hmm when i use ast+safe_sleep the channel does nothing |
| 10:44.58 | synthetiq | basicly when i have an invite comes in, i set my operations on __ast_pbx_run() (pbx.c) but when i use ast_safe_sleep, the channel is not able to be processed furthur |
| 10:45.41 | synthetiq | debates if he has to run a detached thread |
| 11:01.02 | *** part/#asterisk-dev c0rnoTa (n=c0rnoTa@80.251.113.56) |
| 11:20.49 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:16.51 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:16.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:19.44 | file | nods to kpfleming |
| 12:23.11 | seanbright | i sense file's presence within our borders |
| 12:23.17 | seanbright | contacts the INS |
| 12:23.34 | file | you sense nothing |
| 12:24.52 | seanbright | a presence i've not felt since... |
| 12:37.20 | kpfleming | seanbright: s/INS/ICE/ |
| 12:38.26 | seanbright | kpfleming: whichever, i'm not really calling |
| 12:39.32 | oej | Hmm. Did bugs just die? |
| 12:39.49 | seanbright | works for me |
| 12:39.54 | oej | Just came back... |
| 12:39.59 | seanbright | i fixed it |
| 12:40.04 | seanbright | fairy dust, ftw. |
| 12:45.01 | oej | Thanks, Sean! |
| 13:33.58 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:36.36 | *** join/#asterisk-dev ctooley (n=ctooley@mo-71-1-123-189.dhcp.embarqhsd.net) |
| 13:36.36 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 13:36.38 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:36.38 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:37.33 | lmadsen | morning develonomicons! |
| 13:41.41 | seanbright | waves to mr. lmadsen |
| 13:43.30 | lmadsen | waves back... cautiously |
| 13:43.57 | seanbright | oh, does my lack of pants trouble you? |
| 13:44.07 | seanbright | it's just how i roll, baby! |
| 13:45.38 | lmadsen | no, that doesn't trouble me. It's that fake moustache. |
| 13:45.49 | seanbright | it's my monday porn stache |
| 13:45.50 | seanbright | don't hate |
| 13:45.53 | file | all of this greatly concerns me |
| 13:46.03 | seanbright | file: you'll live |
| 13:46.03 | lmadsen | it's not so much the stache that concerns me... it's where it is placed |
| 13:46.16 | seanbright | looks |
| 13:46.21 | file | seanbright: will I? how can you be sure? |
| 13:46.44 | seanbright | file: i am all knowing |
| 13:46.50 | file | seanbright: lies |
| 13:46.51 | seanbright | omniscient, as it were. |
| 13:48.52 | seanbright | points to his face |
| 13:48.59 | seanbright | i'm up HERE, lmadsen. |
| 13:49.01 | seanbright | up HERE. |
| 13:49.47 | lmadsen | lol |
| 13:53.14 | *** join/#asterisk-dev c0rnoTa (n=c0rnoTa@80.251.113.56) |
| 13:53.26 | *** part/#asterisk-dev c0rnoTa (n=c0rnoTa@80.251.113.56) |
| 14:03.58 | *** join/#asterisk-dev c0rnoTa (n=c0rnoTa@80.251.113.56) |
| 14:06.36 | *** join/#asterisk-dev sasargen (n=chatzill@70-4-14-19.pools.spcsdns.net) |
| 14:07.47 | *** part/#asterisk-dev c0rnoTa (n=c0rnoTa@80.251.113.56) |
| 14:12.52 | *** join/#asterisk-dev sasargen_ (n=chatzill@70-4-14-19.pools.spcsdns.net) |
| 14:19.01 | *** join/#asterisk-dev dbailey (n=doug@nat/digium/x-7344cfb51ea1ed0b) |
| 14:23.23 | *** join/#asterisk-dev mcargile (n=mikec@rrcs-24-173-156-170.se.biz.rr.com) |
| 14:24.52 | mcargile | was there any change from 1.4.21.2 to 1.4.23 that would cause an error saying the you should only use a DeadAGI on an inactive channel when I am using the DeadAGI in the h extension? or is this a bug I should report? |
| 14:27.58 | lmadsen | mcargile: that could be part of the changes murf was doing with the 'h' extension |
| 14:28.01 | lmadsen | codefreeze-lap: ping |
| 14:28.20 | lmadsen | mcargile: get with codefreeze-lap and see if you should open a bug. I'd more than likely say you will probably need to open one. |
| 14:28.46 | *** join/#asterisk-dev DarkRift (n=dark@bas1-sthubert21-1096611958.dsl.bell.ca) |
| 14:29.35 | mcargile | lmadsen: thanks |
| 14:29.55 | codefreeze-lap | returns a ping |
| 14:30.08 | tzanger | morning |
| 14:30.36 | codefreeze-lap | tzanger: and a return g'mornin' to you! |
| 14:30.50 | tzanger | heh someone's in a good mood |
| 14:31.03 | jmls | lmadsen: the patch already on 14241 may fix the h problem .. |
| 14:31.19 | jmls | it fixed mine ;) |
| 14:31.21 | lmadsen | M14241 |
| 14:31.26 | MuffinMan | Failed to retrieve issue page for 14241. Try again later. |
| 14:31.29 | lmadsen | gah! |
| 14:31.44 | jmls | muffinMan has baked his last muffin |
| 14:31.52 | lmadsen | mcargile: http://bugs.digium.com/view.php?id=14241 |
| 14:32.24 | mcargile | thanks |
| 14:32.25 | codefreeze-lap | mcargile: are you calling a macro there or something? |
| 14:32.36 | jmls | has muffinman joined jbot in the great MIA in the sky |
| 14:33.04 | mcargile | would have to check. DeadAGI was written a while ago |
| 14:33.32 | codefreeze-lap | at least humans have mechanisms to self-heal. Bots scratch a fingernail and fall to pieces |
| 14:34.14 | jmls | definately does _not_ have the ability to self-heal. Alcohol works for him ... |
| 14:34.25 | mcargile | I will see if 14241 fixes this issue cause this sounds very similar to what we are doing. |
| 14:35.16 | codefreeze-lap | mcargile: wouldn't hurt to try.... at least, wouldn't hurt much! |
| 14:35.43 | mcargile | if not I will get back to you |
| 14:36.08 | jmls | mcargile: should get back to codefreeze-lap either way ... |
| 14:36.27 | lmadsen | ya, let us know if it fixes for you! |
| 14:36.33 | lmadsen | then we can get it in for 1.4.24 |
| 14:36.53 | *** join/#asterisk-dev sasargen (n=chatzill@70-4-14-19.pools.spcsdns.net) |
| 14:36.58 | codefreeze-lap | mcargile: OK. and if you still have probs, turn up verbose on asterisk, show me the logs at the time; have the relevant chunks of the dialplan ready, etc. |
| 14:38.09 | mcargile | will do |
| 14:40.39 | *** join/#asterisk-dev moy (n=chatzill@bas1-unionville55-1177733953.dsl.bell.ca) |
| 14:45.18 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@nat/digium/x-2694429e1f61d8e5) |
| 14:56.07 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:56.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:56.27 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 14:56.27 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:58.43 | russellb | good morning, -dev! |
| 14:58.53 | lmadsen | russellb: morn! |
| 15:03.38 | *** join/#asterisk-dev shido6 (n=shido6@74-132-200-214.dhcp.insightbb.com) |
| 15:07.31 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 15:09.18 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-5cc8ed000f376ea4) |
| 15:09.18 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:14.58 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 15:18.38 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-129c820c5174bb90) |
| 15:18.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:18.38 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-23f799c10e0e5af3) |
| 15:31.29 | seanbright | i really should adopt a better naming convention for some of my temporary files |
| 15:31.38 | seanbright | foobaryay just isn't that descriptive |
| 15:36.56 | synthetiq | is there a safe function Rem|uiring no locking to see if a channel exists? |
| 15:37.15 | synthetiq | Ren|uring i meant requring |
| 15:37.19 | kpfleming | umm... ast_channel_find? |
| 15:37.39 | kpfleming | there is no way to do it lock free, the channel list lock has to be held |
| 15:38.07 | seanbright | i prefer ast_search_channel_locked |
| 15:38.12 | seanbright | heh |
| 15:38.35 | synthetiq | well im looking at ast 1.4 code and dont see ast_channel_find |
| 15:39.39 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-4b974adff8657284) |
| 15:39.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:39.56 | seanbright | synthetiq: how are you looking up the channel? by name? |
| 15:40.07 | russellb | any channel search is quite expensive ... |
| 15:40.10 | russellb | be careful how you use it, heh |
| 15:40.38 | synthetiq | by name |
| 15:40.41 | lmadsen | we're in a recession you know... |
| 15:40.44 | seanbright | struct ast_channel *ast_get_channel_by_name_locked(const char *chan); |
| 15:40.55 | synthetiq | yes |
| 15:41.04 | seanbright | the documention isn't clear, but i assume it returns NULL when the channel isn't found |
| 15:41.27 | seanbright | oh, but that locks the channel |
| 15:41.39 | seanbright | yeah, you'd need to roll your own function for that i guess |
| 15:42.16 | synthetiq | thats what iw as hoping to avoid |
| 15:42.27 | seanbright | but just because you lock the channel list, find the channel, unlock the list and return true or false, doesn't mean the channel will exist anymore |
| 15:42.47 | synthetiq | cruddy crud |
| 15:43.02 | seanbright | think of it as playing russian roulette with a shotgun |
| 15:43.05 | seanbright | heh |
| 15:46.27 | seanbright | why do you want to avoid the lock? performance reasons? |
| 15:51.01 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-6fa536f807133f81) |
| 15:51.01 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:51.25 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:51.25 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:53.17 | synthetiq | yes |
| 15:53.47 | synthetiq | i have threads that sleep for x seconds, every second polling if the channel exists |
| 15:53.54 | seanbright | yikes |
| 15:54.31 | seanbright | i would just hook into the channel destruction code and notify your other thread |
| 15:54.56 | seanbright | less overhead i would think |
| 16:00.50 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 16:02.06 | seanbright | unless you are purely writing a module, in which case i there is no way for you to hook into said channel destruction (that i am aware of) |
| 16:02.18 | ctooley | Corydon76-dig, I'm looking at manager.c and &reason is there. I am assuming that's the integer version of the release cause in the event that a call does not get answered? |
| 16:04.24 | oej | russellb: Time for a question? |
| 16:05.06 | mvanbaak | oej: it's 5PM, go home and have dinner ! |
| 16:05.39 | russellb | oej: as long as it's kind of quick, yeah |
| 16:05.56 | mvanbaak | wedhorn: Dan was seeing issues if he had the devices before the lines in his configuration file. |
| 16:07.18 | oej | russellb: it's an issue raided in bug 13385. We have a logic error in 1.4 and up in regards to adding cause codes to Bye's. |
| 16:07.48 | oej | russellb: We disconnect early from the AST channel in sip_hangup, then send bye with cause-headers where we check for the owner. |
| 16:08.17 | russellb | is the BYE sent within the call to sip_hangup? |
| 16:08.34 | oej | russellb: Now, to make this work in 1.4 requires changes to sip_pvt to temporarily store the hangupcause. I don't know if it's worth it, since it's only X-headers, but on the other hand, a lot of people seems to use them. |
| 16:08.35 | russellb | we _have_ to remove the owner pointer in there |
| 16:08.45 | oej | ruseellb: yes, we have to. |
| 16:08.55 | russellb | hm, well, adding to sip_pvt is ok |
| 16:08.58 | russellb | i mean, it's already huge ... |
| 16:09.02 | oej | russellb: So in order to get the x-headers with causes to work, I need to change stuff. |
| 16:09.02 | russellb | but it's not a public data structure |
| 16:09.07 | russellb | so it's not an API change problem |
| 16:09.10 | russellb | I think that sounds reasonable |
| 16:09.27 | oej | russellb: Yes, but I don't like adding stuff like that without discussion, we need to keep 1.4 changes minimal... |
| 16:09.33 | russellb | or use a local variable to sip_hangup |
| 16:09.45 | russellb | but then you might get stuck adding a bunch of function parameters ... |
| 16:09.59 | oej | russellb: A local variable won't really work with all the timeouts where we leave sip_hangup and come back later and stuff. |
| 16:10.02 | russellb | so, yeah, sticking it in the sip_pvt sounds fine to me. |
| 16:10.06 | russellb | ah, yes |
| 16:10.28 | oej | It's only the cause code. |
| 16:10.44 | russellb | nods |
| 16:10.57 | oej | Ok, so I will go ahead and change that in all releases and trunk.. |
| 16:11.02 | russellb | there's nsounds good |
| 16:11.06 | russellb | o.O |
| 16:11.08 | oej | We have two bug reports that touches this. |
| 16:11.14 | oej | Ok, thanks. |
| 16:11.15 | russellb | thanks for working on it |
| 16:12.37 | oej | np |
| 16:13.37 | tzanger | heh |
| 16:13.58 | tzanger | using a macro to define a function wrapper leads to some unexpected errors when I invoke it wrong |
| 16:14.37 | tzanger | e.g. #define foo_getreg(a,b) blah_getreg(a->wc, b) |
| 16:14.53 | tzanger | then argle = foo_getreg(ooga) |
| 16:15.32 | tzanger | says foo_getreg doesn't exist, when I'm using it a bazillion times elsewhere int he file. after some digging the facepalm moment usually ends up "ah, the macro with one parameter doesn't exist, now I understand." |
| 16:23.25 | tzafrir_laptop | tzanger, do { blah_getreg(...); } while (0) ? |
| 16:24.09 | tzanger | it'd be the same error, wouldn't it? |
| 16:24.16 | tzafrir_laptop | sorry, misreading |
| 16:24.34 | tzafrir_laptop | too strong a typing for macros? |
| 16:25.01 | tzanger | nah it's fine, it just catches me by surprise when it says a well-used function doesn't exist |
| 16:25.38 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:25.38 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:27.53 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 16:32.24 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 16:32.36 | Corydon76-lap | wields his hockey stick and looks for zombies |
| 16:35.09 | mcargile | drops his brains and hobbles toward the door |
| 16:35.14 | *** join/#asterisk-dev ctooley_ (n=ctooley@doc-72-47-32-189.maryville.mo.cebridge.net) |
| 16:35.20 | *** part/#asterisk-dev mcargile (n=mikec@rrcs-24-173-156-170.se.biz.rr.com) |
| 16:35.22 | oej | putnopvut: around? |
| 16:35.44 | putnopvut | oej: yes, sir! |
| 16:36.02 | oej | putnopvut: what do we do with that port number patch in register= |
| 16:36.14 | oej | putnopvut: I feel it does need to be reverted |
| 16:36.45 | putnopvut | oej: I can understand that. If the functionality that the reporter was trying to use already exists without that patch, then reverting seems like a good idea. |
| 16:36.49 | oej | I'm discussing alternative solutions with Nick |
| 16:36.55 | putnopvut | Ah, gotcha. |
| 16:37.19 | oej | Well, we can't really handle separate registrars nicely now, but he actually read the docs and understand what we are doing now. |
| 16:37.40 | oej | He wasn't aware of the register=yes in a peer section, neither that you could refer to a peer in the register= |
| 16:37.50 | oej | So the whole patch was based on lack of knowledge really |
| 16:38.08 | russellb | register=yes doesn't actually exist, though, right? |
| 16:38.12 | oej | And we need to find a better way to handle a separate registrar |
| 16:38.15 | russellb | it's not in trunk when i looked the other day ... |
| 16:38.25 | oej | russellb: It does, Luigi put that in a long time ago |
| 16:38.30 | oej | checks |
| 16:38.38 | russellb | I think you took it back out when he added it |
| 16:39.08 | russellb | brb |
| 16:39.10 | oej | Not that, it was something else |
| 16:39.19 | oej | Hmm. |
| 16:39.24 | oej | I can't find it. |
| 16:40.50 | oej | ha ha. Me bad. |
| 16:41.16 | oej | Anyway, overloading the register= in the general section won't help. I will fix a solution. |
| 16:41.50 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 16:41.54 | oej | Ok with you, putnopvut? If Nick agrees? |
| 16:42.14 | putnopvut | oej: yeah, I'm fine with it. I like agreement :) |
| 16:42.42 | jmls | Corydon76-dig: you haven't been watching Shaun of the Dead, have you ? |
| 16:42.48 | oej | Oh, found it. It's not called "register=yes" in the peer section, it's called "callbackextension" - that enables registration for a peer |
| 16:43.29 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 16:43.29 | oej | heards lmadsen inside my head and goes away to create yet another oej branch. Blame Leif! |
| 16:44.12 | russellb | oh, interesting |
| 16:45.01 | lmadsen | oej: and a bug! :) |
| 16:45.22 | Corydon76-lap | jmls: No zombie movies in the recent past |
| 16:45.29 | russellb | man, i missed that "callbackextension" option |
| 16:45.36 | russellb | and I went looking for how to register with a peer section |
| 16:45.37 | russellb | oh well |
| 16:45.41 | russellb | thanks for pointing it out. |
| 16:46.14 | russellb | it's not the most obvious option, but I'll take it ;-) |
| 16:46.18 | lmadsen | ya... :) |
| 16:46.34 | lmadsen | is it documented in sip.conf.sample? If not, might be a good idea to add some information there ;) |
| 16:46.38 | russellb | yeah, it is |
| 16:46.41 | lmadsen | sweet |
| 16:46.47 | russellb | It doesn't have a huge section or anything, but it's in there |
| 16:46.52 | lmadsen | that's all the matters |
| 16:47.15 | lmadsen | one of these days we'll get a docs project again and we can break up sip.conf.sample and write verbose sections for each option |
| 16:47.27 | lmadsen | dreams a little deam |
| 16:47.31 | lmadsen | s/deam/dream |
| 16:47.52 | oej | russellb: It's a bad name. It is documented in sip.conf.sample, Leif |
| 16:48.29 | lmadsen | needs lunch... |
| 16:53.55 | sruffell | tzafrir_laptop: question regarding the change in the DAHDI_VMWI ioctl. We're getting ready to make a new release of dahdi-linux, and it looks like the new version will require an update to an as of yet unreleased branch of asterisk and I wanted to confirm with you that this is ok. Since, as I understand it, your customers are the primary consumer of that call. |
| 16:54.03 | sruffell | this is related to issue: http://bugs.digium.com/view.php?id=14104 |
| 16:54.22 | Corydon76-lap | Mama Leif and 'Deam a Little Deam of Me' |
| 16:54.52 | russellb | putnopvut: thanks for looking at my sched mods |
| 16:55.36 | putnopvut | russellb: I hadn't understood why you had written the sched_thread stuff until I saw that it was manually implemented in chan_iax2.c |
| 16:55.43 | sruffell | The other option would be to make a 2.1.1 release that does not include those changes. |
| 16:55.45 | tzafrir_laptop | sruffell, I wonder if the name of the ioctl should not be simply changed, so the breakage will be obvious at compile time |
| 16:55.56 | russellb | putnopvut: yeah, and I used it in chan_sip, too |
| 16:56.01 | russellb | (not committed, just testing) |
| 16:56.05 | putnopvut | russellb: neat |
| 16:56.12 | russellb | so i figured while I was adding it, might as well make it portable |
| 16:56.19 | russellb | chan_sip was what the main inspiration for doing it was ... |
| 16:56.27 | russellb | and I just happened to notice bugs in chan_iax2 in the process of removing it from there |
| 16:56.29 | putnopvut | chan_sip's do_monitor thread? |
| 16:56.34 | sruffell | tzafrir_laptop: What about supporting both the old way and the new way? So that existing code will still work if they just update dahdi...at least for a time? |
| 16:56.46 | russellb | well, removing sched processing from do_monitor, and putting it in its own thread |
| 16:56.56 | russellb | file tested it, got some really impressive numbers |
| 16:57.18 | sruffell | Or is it ok that updating dahdi causes the ripple that someone move off of the asterisk branch they are on if they are using the VMWI feature. |
| 16:57.20 | tzafrir_laptop | sruffell, the asterisk source has ioctl of VMWI: what does that do? |
| 16:57.37 | tzafrir_laptop | Old meaning? New meaning? |
| 16:57.52 | tzafrir_laptop | (yes, I know that there are size differences) |
| 16:57.58 | sruffell | The old one uses a bit-stuffed integer to contain the parameters, the new one has a structure with two ints. |
| 16:58.09 | sruffell | but the meaning is the same as far as I am aware. |
| 17:02.38 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 17:03.41 | *** join/#asterisk-dev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 17:03.57 | oej | russellb: I thought murphy did a lot of changes to the scheduler earlier. But to make it even faster is a good thing. |
| 17:04.17 | russellb | It's not very invasive to chan_sip from a lines of code point of view ... |
| 17:04.24 | russellb | from an architecture point of view, it's a little bit scary |
| 17:04.25 | oej | chan_sip has a massive amount of scheduled items going in a large system |
| 17:04.28 | russellb | nods |
| 17:04.48 | russellb | if locking of sip_pvt structs is done perfectly, it would be fine :) |
| 17:04.55 | russellb | but I'm not sure that is the case ... |
| 17:05.01 | oej | Dream on... |
| 17:05.12 | oej | Locking done perfectly in chan_sip. Wow. |
| 17:05.13 | russellb | putting the scheduler in it's own thread means we would have 2 threads working on the dialog where there was only the monitor thread doing it before |
| 17:05.23 | russellb | so, in that respect, it's scary |
| 17:05.38 | russellb | and yes, I did some load testing and it crashed :) |
| 17:05.56 | oej | Well, yes. But we still need to make those changes as we move to more sockets, so you might as well go ahead and cause damage now |
| 17:06.16 | russellb | I also wrote some code to do UDP packet processing with a thread pool |
| 17:06.23 | russellb | but that's even more scary |
| 17:06.24 | oej | I need to debug the manager bridge command btw, that you committed. Can't use it without crashes. |
| 17:06.31 | russellb | oh dear ... |
| 17:06.49 | russellb | any newer code that adds more masquerading is scary, heh |
| 17:06.53 | oej | russellb: There's an old branch written by File in pisa that implements threads in chan_sip |
| 17:07.10 | russellb | nods |
| 17:07.19 | file | it doesn't take into account all of the fun... aspects of chan_sip |
| 17:07.20 | oej | To summarize: Asterisk is scary. Might as well go ahead and mess it up a bit more ;-) |
| 17:07.23 | russellb | the way I did it, it was pretty non-invasive to chan_sip as far as lines of code ... |
| 17:07.29 | oej | file: it was a test |
| 17:07.32 | file | probably would explode |
| 17:07.45 | oej | What would explode? file or chan_sip or the muffin? |
| 17:07.46 | russellb | but ... the biggest thing I ahd not handled yet was ensuring that only one thread was processing packets for a dialog at a time |
| 17:07.49 | tzafrir_laptop | sruffell, now it uses an extra byte in a struct for flags |
| 17:07.50 | russellb | it's tricky |
| 17:08.10 | oej | yes, that's tricky |
| 17:08.21 | russellb | we have similar logic in chan_iax2 for it's multi-threaded magic |
| 17:08.25 | russellb | but it took us a while to get it just right |
| 17:08.34 | oej | I started with some of those issues, but not with threads. I wanted to have multiple processing queues from sipsockread |
| 17:08.45 | russellb | yep, that's a good start |
| 17:08.50 | oej | And couldn't really do it, since I had to match dialogs so early so it was no use |
| 17:09.13 | oej | I wanted to change the way we handle subscriptions and registrations, to prioritize call-related signalling. |
| 17:09.38 | sruffell | tzafrir_laptop: so if we want to allow someone on say the 1.6.0 branch to update dahdi without needing to goto asterisk-trunk, we either need to move that change of just the DAHDI_VMWI into all the branches, or support both forms of the IOCTL, otherwise, because that change is also includes the DAHDI_VMWI_SENDTYPE, which is a new feature and cannot go into the branches....just trying to figure out what the best thing to do here is. |
| 17:09.43 | russellb | yeah, we could potentially break it up that way |
| 17:10.13 | oej | Yes, but we still have to solve the dialog-matching very early on, then hand off the packet to one queue and send it to a processing thread |
| 17:10.49 | oej | Mostly UDP, for TCP it's a bit different, but can still be done so we can have the same queues. |
| 17:11.03 | tzafrir_laptop | sruffell, support just the new form |
| 17:11.20 | russellb | oej: right ... TCP is sort of already thread-pooled anyway, since there is a thread per TCP connection |
| 17:11.28 | oej | Anyway, gotta go. Family taxi time. Leave and fetch family members in multiple places. Separate threads, but only one car. |
| 17:11.36 | russellb | cya! |
| 17:11.44 | tzafrir_laptop | at least in future versions. The old form is only supported by xpp, and not enabled by default |
| 17:11.59 | oej | russellb: yes, that's kind of scary, since the locking is the way it is. We could very well get two TCP connections for one dialog. |
| 17:12.20 | russellb | yeah, that might make things explode ... |
| 17:12.27 | russellb | s/might/would/ |
| 17:12.28 | russellb | heh |
| 17:12.49 | russellb | oej: you'll be at FOSDEM, right? |
| 17:12.59 | oej | I don't think so, maybe. Why? |
| 17:13.06 | russellb | oh, sorry, thought you were for some reason ... |
| 17:13.12 | russellb | just curious, I just made some last minute plans to go |
| 17:13.15 | sruffell | hmm....so if your customers use anything greater than dahdi-linux 2.1.0.3, they will also need to update asterisk, and the new form will need to be ported into branches 1.6.0 and 1.6.1 (or we just wait until 1.6.2 is released and don't worry about back porting it just yet) |
| 17:13.32 | russellb | oej: let me know if you decide to go and we'll catch up. |
| 17:13.33 | tzafrir_laptop | single threaded task. Though the car has locks (mutexes?) |
| 17:13.48 | oej | Ok, that adds to it. I discussed with jtodd, but according to him no one was coming and I thought that it was a lot of money for nothing. |
| 17:14.04 | oej | russellb: I'll check with the travel agency tomorrow and will let you know. |
| 17:14.11 | russellb | oej: yeah, I wasn't going a week ago, heh, but found out I had a bunch of airline credit that was about to expire |
| 17:14.24 | oej | Me too, lots of credit. |
| 17:14.25 | russellb | no problem, I understand that travel is expensive |
| 17:14.38 | russellb | anyway, enjoy taxi time |
| 17:14.44 | oej | runs away desperately telling the world that I left home ten minutes ago. |
| 17:14.51 | russellb | hehe |
| 17:15.21 | sruffell | tzafrir_laptop: ok...only the new form, and since it isn't available by default, no need to backport..agreed? |
| 17:15.57 | tzafrir_laptop | sruffell, hmm... well, any reason for this not included in 1.6.1? (not sure about the policy for 1.6.0) |
| 17:15.59 | sruffell | any of your customers who use that feature now will know that they can't upgrade dahdi until a new branch of asterisk is released, or they run off trunk. |
| 17:16.46 | tzafrir_laptop | if you package both zaptel and asterisk you can also patch asterisk accordingly if it's that important |
| 17:20.01 | sruffell | It could be included 1.6.1, if just that part of the VMWI changes are moved...just trying to see how much work is required to get this release. I need to try at least to document this in the change notes since it creates a dependency on asterisk versions because of that change. But since it is primarily your customers that use it currently, your the person who has the greatest potential breakage on upgrade. |
| 17:20.23 | sruffell | ....I would almost just like to make a point release (2.1.0.4) that only includes the pseudo channel fix... |
| 17:21.51 | sruffell | and since the change breaks backward compatibility on one of the interfaces, it will mean dahdi-linux 2.2.0. |
| 17:24.51 | tzafrir_laptop | sruffell, why does it break compatibility? |
| 17:25.51 | tzafrir_laptop | (the pseudo channel issue) |
| 17:27.32 | sruffell | the change in the arguments to DAHDI_VMWI breaks compatibility. Asterisk compiled against dahdi-linux 2.1.0.3 which uses the VMWI call will spam the log with a failure message because that ioctl will not work anymore if just dahdi-linux is upgraded. |
| 17:28.19 | sruffell | The pseudo channel issue doesn't break backward compatibility, it just fixes a regression that crept in the drivers after dahdi-linux 2.0.0 was released. |
| 17:35.24 | tzafrir_laptop | sruffell, it is a bug fix . I don't think it belongs in 2.1.0.4 . If you need a bugfix now: why not take 2.1.0.3 and add the pseudo channel fix? |
| 17:35.44 | *** join/#asterisk-dev ccesario (i=c8d3490f@gateway/web/ajax/mibbit.com/x-a8fe242a9b4dcfd2) |
| 17:40.01 | sruffell | tzafrir_laptop: I'm confused. If I add any bugfixes to 2.1.0.3, I need to either make 2.1.0.4 (if they are trivial and don't require release candidates) or 2.1.1 (if the changes are serious enough to require release candidates, which I do not think the pseudo channel change does). Ok...so it is probably safest to do that, and I won't worry about the other changes in trunk for the time being. But that still leaves the question abo |
| 17:44.15 | kpfleming | as i understand it, the DAHDI_VMWI stuff has not been in any release of DAHDI or Asterisk yet |
| 17:44.20 | kpfleming | in that case, the API change is just fine |
| 17:44.26 | kpfleming | they are both 'development' branches |
| 17:45.35 | sruffell | kpfleming: they are in asterisk 1.6.0 |
| 17:46.25 | sruffell | Line 7813 of http://svn.digium.com/view/asterisk/branches/1.6.0/channels/chan_dahdi.c?view=markup |
| 17:46.43 | sruffell | asterisk 1.4 doesn't use those ioctls. |
| 17:47.52 | sruffell | actually...let me double check the tags. |
| 17:48.30 | kpfleming | i asked doug twice last week if that VMWI stuff had appeared in any DAHDI or Zaptel release |
| 17:48.34 | kpfleming | he said no it had not |
| 17:48.54 | kpfleming | if it has, then we must revert the ioctl to its previous form in compatibility mode, and the new struct-based version must be a new ioctl number |
| 17:48.58 | sruffell | no..it's in the 1.6.0 branch..just not in any of the tagged releases of 1.6...so that is my confusion |
| 17:49.07 | kpfleming | no kidding |
| 17:49.38 | kpfleming | but i am more concerned about dahdi than asterisk; have any dahdi releases included this ioctl? |
| 17:49.46 | sruffell | I spoke with doug about it this morning and got the impression from him that he agreed there was some breakage. |
| 17:49.53 | sruffell | ....that too contributed to my confusion. |
| 17:50.02 | sruffell | checking... |
| 17:50.11 | kpfleming | alright |
| 17:50.30 | kpfleming | the safest course of action is probably going to be to revert the dahdi changes and re-do them as a new version of the ioctl |
| 17:50.46 | kpfleming | for dahdi, we need to preserve both API and ABI compatibility |
| 17:50.51 | sruffell | yes...at least in 2.1.0.3. line 971 of http://svn.digium.com/view/dahdi/linux/tags/2.1.0.3/include/dahdi/user.h?view=markup |
| 17:51.00 | kpfleming | ok, then it must be reverted |
| 17:51.54 | sruffell | kpfleming: that is my opinion too. tzafrir_laptop is arguing for only the new interface to be supported. |
| 17:52.05 | kpfleming | too late |
| 17:52.13 | sruffell | doug said that it would be trivial to give me a patch that supports both forms of the call in order to maintain compatibility. |
| 17:52.23 | kpfleming | well, it is too late if there is *any* released version of asterisk that uses it |
| 17:52.34 | kpfleming | but even so, asterisk should not be the reason why we retain API compatibility |
| 17:52.45 | kpfleming | there can be other users of dahdi as well, and breaking their API/ABI is not nice |
| 17:52.51 | sruffell | well...I'm not sure if there is a tagged version of asterisk that uses it...but there is a tagged version of dahdi that includes it. |
| 17:53.02 | kpfleming | if dahdi 2.1.0 included vmwi, then that API and ABI must remain |
| 17:53.07 | kpfleming | it can be marked deprecated if we wish to do that |
| 17:53.10 | kpfleming | but it cannot go away |
| 17:53.42 | sruffell | that sounds good to me. |
| 17:53.58 | kpfleming | you'll have to look at how we handled the previous ioctl changes to decide on the best course of action for API |
| 17:54.09 | kpfleming | the ABI is easy to do, the IOR/IOW/IOWR macros handle that |
| 17:54.33 | tzafrir_laptop | calls oron to the session... |
| 17:54.42 | *** join/#asterisk-dev oron (n=oron@local.xorcom.com) |
| 17:54.53 | kpfleming | but if the API is going to change for the same ioctl name, then Asterisk will need configure script magic to determine which version of the ioctl it is being built against, and include the proper code for that API |
| 17:55.18 | oron | kpfleming: not if we *rename* the ioctl |
| 17:55.23 | kpfleming | that was my point |
| 17:55.26 | sruffell | I like renaming the ioctl personally... |
| 17:55.31 | kpfleming | then that's fine |
| 17:55.37 | kpfleming | i'm ok with that too |
| 17:55.42 | sruffell | waits for oron's opinion. |
| 17:55.51 | kpfleming | so we revert the changes, restore the previous ioctl name's behavior (API *and* ABI) |
| 17:55.53 | oron | as the only users (afaik) of this ioctl() we favor renaming. |
| 17:56.01 | kpfleming | then we put in new changes that provide a new name |
| 17:56.18 | kpfleming | agreed? |
| 17:56.37 | oron | kpfleming: Looks like a plan. |
| 17:56.43 | kpfleming | and now that it is a structure, we can extend the ioctl structure in the future without having to rename the ioctl |
| 17:57.08 | kpfleming | and i think we should avoid adding *any* new ioctls in the future that don't use 'struct' arguments, for this very reason |
| 17:57.42 | sruffell | ok...sounds like a plan. Thanks everyone. |
| 17:58.40 | oron | Last note -- for the future, I'm not use if it's easier to rename ioctl's or add semantic on variable structures... |
| 17:58.48 | oron | s/use/sure/ |
| 17:59.17 | tzafrir_laptop | sruffell, one other thing: would be 2.1.1 based on? Specifically: will it include my latest xpp commits? |
| 18:00.08 | sruffell | yes...since we're not breaking backward compatibility, I'll make a 2.1.1 that is based off the current trunk. |
| 18:00.44 | sruffell | well..actually it still needs to be 2.2.0, since a new feature is added with support for polarity reversal. |
| 18:01.29 | kpfleming | oron: i think extending the structures is much easier, it means less namespace pollution and the userspace configure script testing is a bit easier |
| 18:01.58 | kpfleming | plus it reduces code duplication on both sides |
| 18:02.03 | oron | kpfleming: OK, we'll now have a chance to see it... |
| 18:02.19 | kpfleming | we've already done it once, iirc. let me find it. |
| 18:07.20 | kpfleming | oh, we did it in zaptel, but it's gone in dahdi |
| 18:07.22 | kpfleming | still looking |
| 18:07.33 | sruffell | we would probably have to somehow nest the structures used as the argument as we extend them so that we can have several different ioctls that just differ by the structure argument if we're going to maintain the ABI. |
| 18:08.09 | sruffell | so we could have several ioctls of the same name, just with a different structure for the argument. |
| 18:08.09 | kpfleming | that's what we did before |
| 18:08.09 | kpfleming | look at ZT_GET_PARAMS |
| 18:08.09 | kpfleming | in zaptel 1.4 |
| 18:08.24 | kpfleming | you don't even need to nest, just make sure you only *extend* the structure and never reorder or change existing field types |
| 18:08.33 | kpfleming | but nesting is fine too, it would ensure that as the policy |
| 18:10.21 | sruffell | I see...so you're not just extending the structure in zaptel, you created a new structure that is the old one with additional fields...so that covers the case I was thinking of. |
| 18:10.31 | kpfleming | correct |
| 18:10.35 | kpfleming | you have to do it that way |
| 18:10.41 | kpfleming | otherwise the old ioctl number would change |
| 18:10.52 | sruffell | yes..that is what I was concerned about. |
| 18:10.56 | kpfleming | and then ABI compatibility is broken |
| 18:11.05 | kpfleming | yay, we all are on the same page now |
| 18:11.17 | sruffell | :) |
| 18:11.22 | kpfleming | so.. for the future: no new dahdi ioctls unless they accept a 'struct *' parameter |
| 18:11.39 | sruffell | agreed. |
| 18:11.46 | kpfleming | our lives will be easier if any of those ioctls ever need to go from one to two items of data to be passed |
| 18:12.42 | kpfleming | it also means we don't need to 'overload' fields in the structure and put multiple items of data into a single field (like bit fields in an 'int')... the structure size is just not that important |
| 18:49.22 | *** join/#asterisk-dev ctooley (n=ctooley@mo-71-1-123-189.dhcp.embarqhsd.net) |
| 18:49.22 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 19:20.53 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 19:47.27 | *** join/#asterisk-dev bbryant (n=Brett_Br@adsl-068-016-200-248.sip.chs.bellsouth.net) |
| 19:47.27 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 19:53.03 | wedhorn | mvanbaak: The lines stuff in skinny.conf should load first regardless of the order in the conf file. Not sure why Dan was having an issue. |
| 19:53.12 | Corydon76-lap | kpfleming: Issue 14332 |
| 19:53.19 | Corydon76-lap | M14332 |
| 19:53.25 | MuffinMan | Failed to retrieve issue page for 14332. Try again later. |
| 19:54.16 | wedhorn | mvanbaak: when configuring lines and devices, it should be noted in the log file. Did DEA indicate any issues in the order or missing lines/devices on load? |
| 19:55.34 | mvanbaak | wedhorn: he noticed some settings on lines/devices were set wrong when devices were before the lines in the configfile |
| 19:57.27 | wedhorn | mvanbaak: noticed that, but the code goes to the [lines] section in skinny.conf, loads, goes to [devices], and loads. I can't see how or why that patch would fix anything (unless there is some issue in the code I haven't noticed) |
| 19:57.50 | *** join/#asterisk-dev VoipForces (n=courchea@207.107.190.130) |
| 19:57.58 | wedhorn | mvanbaak: I don't like the patch because it may be obscuring a bug |
| 19:58.01 | VoipForces | Anyone had errors like "include/linux/types.h:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__kernel_dev_t'" trying to compile dahdi under kernel 2.6.28 ? |
| 20:00.59 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 20:00.59 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 20:03.08 | sruffell | VoipForces: that doesn't look like anything I've seen before. Have you tried building dahdi/linux/trunk? |
| 20:03.20 | mvanbaak | wedhorn: I agree |
| 20:04.26 | wedhorn | mvanbaak: can we reopen the bug file and get some more info from Dan (or email him directly) |
| 20:04.58 | oej | Interesting mail about p2p to -dev. Can someone translate it to english for me? |
| 20:05.03 | oej | ;-) |
| 20:05.27 | kpfleming | he was here last week asking the same questions... hard to understand, about 'punching' holes in NAT or something |
| 20:06.22 | russellb | yeah, I didn't understand either |
| 20:06.42 | *** join/#asterisk-dev otherwiseguy (n=otherwis@nat/digium/x-6d55a4471c9ebf91) |
| 20:07.25 | mvanbaak | wedhorn: reopened |
| 20:07.30 | jsmith | oej: He's in #asterisk talking about it now... nick is "interfaith" |
| 20:07.44 | jsmith | oej: Care to start a conversation with him? |
| 20:07.55 | seanbright | i just can't deal with abbreviating 'ast' constantly |
| 20:08.02 | seanbright | it irritates me |
| 20:08.40 | oej | jsmith: I'm sure you're doing fine |
| 20:09.24 | kpfleming | Corydon76-dig: i don't understand... those compile errors are pointing to line 683 of app_stack.c, which is the call to AST_MODULE_INFO_STANDARD |
| 20:09.33 | oej | A quote for the log book: "The world at large does not care about IAX2" |
| 20:09.54 | kpfleming | Corydon76-lap: see above |
| 20:09.58 | oej | kpfleming: My OS/X warnings? |
| 20:10.18 | kpfleming | yes |
| 20:11.01 | oej | I did not understand a thing, but obviously Corydon found some docs |
| 20:11.25 | Corydon76-lap | oej: I know how to fix it; the thing I'm working on now is how we work around that |
| 20:11.26 | kpfleming | we were just talking in our weekly meeting about it, he thought it had something to do with weak aliases |
| 20:11.38 | kpfleming | but i don't understand how weak aliases are involved in that line of code |
| 20:11.39 | Corydon76-lap | It definitely has to do with weak aliases |
| 20:11.56 | kpfleming | is the line number in the error report bogus? |
| 20:12.00 | Corydon76-lap | I think it's more to do with that being the last line of the file |
| 20:12.04 | kpfleming | ok |
| 20:12.05 | oej | I'll happily let you guys sort it out :-) |
| 20:12.08 | kpfleming | so hang on a second then |
| 20:12.32 | oej | It was repeated many times if I remember correctly. |
| 20:12.38 | kpfleming | four times |
| 20:12.44 | kpfleming | which is not unusual for macros |
| 20:12.44 | oej | Which indicates the it's an alias that expands or? |
| 20:12.50 | oej | Right |
| 20:13.10 | kpfleming | oej: can you pastebin part of your config.log file? just search for 'weak' and get 10 lines above and below please |
| 20:13.27 | Corydon76-lap | oej: setenv MACOSX_DEPLOYMENT_TARGET 10.2 |
| 20:13.39 | Corydon76-lap | oej: then, the compiler will cease to complain |
| 20:14.11 | oej | kpfleming: Attribute weak support? |
| 20:14.15 | kpfleming | yes |
| 20:14.26 | kpfleming | oej: how is the 'svn branch name' N/A on your bug report :-) |
| 20:14.44 | oej | It was a clean trunk |
| 20:14.53 | oej | I think I added revision number |
| 20:15.05 | kpfleming | yes, but not 'trunk' |
| 20:15.10 | Qwell | kpfleming: svn/asterisk/branches/N/A/ :) |
| 20:15.17 | kpfleming | right |
| 20:15.32 | oej | keving: http://pastebin.ca/1318839 |
| 20:15.53 | oej | I think I selected "svn trunk" or something similar |
| 20:15.54 | Corydon76-lap | Now that I think about it, maybe I can just detect OS X 10.1 and before and make a fatal in the configure script, and be done with it |
| 20:16.17 | kpfleming | so why does the configure script check for 'attribute weak' and 'attribute alias' succeed when actual compiling does not? |
| 20:16.22 | oej | There's a lot of "#define HAVE_ATTRIBUTE_weak 1" |
| 20:16.29 | kpfleming | yes |
| 20:16.47 | kpfleming | Corydon76-lap: please don't do stuff like that |
| 20:17.03 | kpfleming | we want to concentrate on testing for what we want to use, not just making assumptions based on version numbers |
| 20:17.29 | Corydon76-lap | kpfleming: I mean based upon the compatibility macros that decide what features you have |
| 20:17.37 | Corydon76-lap | i.e. the way Apple says we should do it |
| 20:17.39 | oej | Corydon: Trying with your environment variable now |
| 20:18.34 | oej | These problems started when Steve got sick. |
| 20:19.26 | oej | Corydon: Five warnings now... Line 683 |
| 20:19.41 | Corydon76-lap | oej: weird, they go away when I do it here |
| 20:19.53 | Corydon76-lap | oej: are you running csh or bash? |
| 20:19.57 | oej | Trying again |
| 20:20.28 | Corydon76-lap | csh is the default on OSX, but I know I have changed my shell to bash, at least |
| 20:20.32 | oej | bash |
| 20:20.46 | russellb | bash was default for me |
| 20:20.56 | seanbright | ksh for me |
| 20:21.09 | Corydon76-lap | for bash, it's: export MACOSX_DEPLOYMENT_TARGET=10.2 |
| 20:21.19 | oej | I did it that way... |
| 20:22.02 | seanbright | oej: what version of gcc? just curious |
| 20:22.23 | oej | i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465) |
| 20:22.26 | Corydon76-lap | seanbright: this is OS X specific |
| 20:22.32 | seanbright | i know |
| 20:22.35 | seanbright | <-- runs OS X |
| 20:22.51 | Corydon76-lap | It's because gcc compiles for 10.0 by default on OS X |
| 20:23.06 | kpfleming | but why aren't other people experiencing this problem? |
| 20:23.25 | Corydon76-lap | Because other people aren't running trunk on OS X |
| 20:23.28 | oej | It's just a warning. Only freaks report warnings |
| 20:23.40 | Corydon76-lap | That, too |
| 20:23.42 | kpfleming | oh, it's trunk. yeah. |
| 20:23.58 | Corydon76-lap | although, it's also an issue on 1.6.0 |
| 20:23.59 | kpfleming | if you were compiling with --enable-dev-mode it would be an error |
| 20:24.20 | oej | I thought I had enabled that, but maybe that was in another branch |
| 20:24.30 | kpfleming | Corydon76-lap: do you see this problem on your system? |
| 20:24.40 | Corydon76-lap | Yes, on PowerPC |
| 20:24.44 | oej | Ah. I did --enable-devmode, not -enable-dev-mode |
| 20:24.45 | kpfleming | when did it start? |
| 20:25.05 | Corydon76-lap | Dunno, I never compile it on this system but very rarely |
| 20:25.09 | oej | Strange, should get an error. I wish. |
| 20:25.31 | kpfleming | seanbright: have you built 1.6.0,1.6.1 or trunk on your OS/X system? |
| 20:25.48 | seanbright | i have not, no. |
| 20:25.52 | kpfleming | bummer |
| 20:25.57 | seanbright | and it's at home |
| 20:25.59 | seanbright | otherwise i would |
| 20:26.01 | kpfleming | ok |
| 20:26.06 | russellb | has a mac but just does all of his development on linux .. |
| 20:26.27 | Corydon76-lap | Well, mine is at home, too, but that doesn't stop me from compiling on it |
| 20:26.32 | seanbright | yeah yeah |
| 20:26.36 | Corydon76-lap | Well, my PPC system, anyway |
| 20:26.39 | kpfleming | well, first, i am annoyed once again that apple's dev toolchain claims to support something but doesn't really support it |
| 20:26.44 | Corydon76-lap | Intel system is local |
| 20:26.47 | seanbright | mine is home *and* powered off |
| 20:26.52 | seanbright | doing my part to stay green |
| 20:26.54 | seanbright | jerk. |
| 20:26.56 | seanbright | heh |
| 20:26.59 | Corydon76-lap | lol |
| 20:27.02 | mvanbaak | need a testcompile on osx ppc ? |
| 20:27.11 | kpfleming | let me try to post a small configure script patch... hang on |
| 20:27.16 | mvanbaak | I can grab mine from the other room |
| 20:27.24 | Corydon76-lap | mvanbaak: not unless we want yet another identical test |
| 20:27.31 | mvanbaak | k |
| 20:28.07 | mvanbaak | I wasn't following it all |
| 20:28.09 | Corydon76-lap | seanbright: mine controls part of the DVR system, so it kinda needs to stay on |
| 20:28.15 | seanbright | ah |
| 20:28.25 | seanbright | i'm having hard drive issues |
| 20:28.32 | seanbright | so until i get a backup drive, it's staying off |
| 20:28.52 | Corydon76-lap | seanbright: where's your budget for 1.5TB external drives? |
| 20:29.09 | Juggie | careful w/ seagate drives atm! |
| 20:30.06 | seanbright | don't say that |
| 20:30.06 | Corydon76-lap | Eh, if I had trouble with Seagate drives, I'd just call my sister |
| 20:30.17 | seanbright | i've got 2 1TB drives i haven't even unboxed |
| 20:30.23 | kpfleming | arer you guys on OS/X able to run 'bootstrap.sh', or do i need to give you a patch to configure (not configure.ac) |
| 20:30.33 | Corydon76-lap | kpfleming: I am able to |
| 20:30.43 | Juggie | seanbright, go go linux raid! |
| 20:30.50 | Corydon76-lap | though, it's an older version of autoconf |
| 20:30.58 | seanbright | Juggie: i want to a combination windows/linux backup solution. |
| 20:31.04 | kpfleming | that shouldn't matter... just a second |
| 20:31.10 | oej | Ok, dev-mode works now. My Asterisk doesn't compile. |
| 20:31.11 | Corydon76-lap | autoconf 2.60 |
| 20:31.13 | seanbright | Juggie: windows home server is *the* solution for windows |
| 20:31.18 | Juggie | seanbright, windows could back up to a samba share. |
| 20:31.26 | seanbright | Juggie: yeah... but that feels dirty |
| 20:31.27 | seanbright | heh |
| 20:32.06 | Juggie | windows is dirty :) |
| 20:32.16 | seanbright | oh stop |
| 20:32.28 | kpfleming | OK, just below the current test in configure.ac for 'alias' support, add this: AST_GCC_ATTRIBUTE(weak_alias, [weak,alias("foo")]) |
| 20:32.43 | kpfleming | then run bootstrap and configure and tell me what config.log has for 'weak_alias' |
| 20:32.49 | seanbright | emacs needs a better autoconf mode |
| 20:33.03 | seanbright | the spacing in that file is all jacked up |
| 20:33.06 | russellb | emacs needs a better editor |
| 20:33.35 | seanbright | M-x destroy-russellb |
| 20:33.46 | tzanger | russellb: :-) |
| 20:34.29 | Corydon76-lap | bootstrap is running |
| 20:34.44 | seanbright | your father's emacs. an elegant weapon for a more civilized age. |
| 20:34.56 | Corydon76-lap | It's complaining about AST_PROG_EGREP and AST_PROG_LD, but it runs |
| 20:35.28 | Corydon76-lap | and now configure is running |
| 20:36.53 | oej | kpfleming: I think I succeeded in adding that but I get the same compile errors |
| 20:37.33 | Corydon76-lap | kpfleming: http://pastebin.ca/1318860 |
| 20:37.42 | oej | #define HAVE_ATTRIBUTE_weak_alias 1 |
| 20:38.15 | kpfleming | it would not affect the compile errors |
| 20:38.56 | kpfleming | ok, let me try again |
| 20:39.31 | mvanbaak | hands lmadsen a glas of vino |
| 20:39.40 | kpfleming | i don't understand |
| 20:39.57 | kpfleming | that new configure script fragment checks specifically for 'weak' and 'alias' used together, and is passing |
| 20:40.03 | *** join/#asterisk-dev mcargile (n=mikec@rrcs-24-173-156-170.se.biz.rr.com) |
| 20:40.03 | kpfleming | but when the real compile occurs, it fails |
| 20:40.12 | kpfleming | that is frustrating, to say the least |
| 20:40.43 | oej | yep |
| 20:42.53 | mcargile | codefreeze-lap: I am recompiling 1.4.23 with 0014241 applied now. Should have some results soon. |
| 20:43.13 | codefreeze-lap | mcargile: OK |
| 20:44.07 | kpfleming | Corydon76-lap: can you get me a copy of app_stack.i from your compile so i can see the preprocessed output? |
| 20:44.58 | Corydon76-lap | Sure, hang on |
| 20:44.59 | lmadsen | mvanbaak: heh... a bit early here for that unfortunately :) |
| 20:46.22 | Juggie | make -j2 isnt working for me on trunk, anyone else notice this? it complains about the jobserver and says to add '+' to the parent make rule. |
| 20:47.08 | jsmith | It isn't working for me either, but I don't really have time to look at it |
| 20:47.48 | mvanbaak | Mon Jan 26 21:47:38 CET 2009 |
| 20:48.43 | tzafrir_laptop | Juggie, some variable overriden that shoudn't be? This looks familiar |
| 20:49.43 | tzafrir_laptop | Something along the lines of MAKEFLAGS ? |
| 20:50.03 | kpfleming | Juggie: just don't try it |
| 20:50.19 | kpfleming | some of our Makefile rules don't make it obvious to GNU make that it is being called |
| 20:51.50 | kpfleming | you can use -j<n>, but you'll have to run it multiple times to get everything built |
| 20:53.34 | mcargile | codefreeze-lap: well I am not seeing that error anymore... do you want the output in a pastebin? |
| 20:54.24 | codefreeze-lap | mcargile: no, not necc.... only if the error was not fixed. |
| 20:54.51 | mcargile | codefreeze-lap: I am seeing a Notice now on all of them |
| 20:55.23 | mcargile | better than an error |
| 21:02.32 | seanbright | Juggie: i got most of the errors to go away |
| 21:02.37 | seanbright | but the solution is sub-optimal |
| 21:06.16 | seanbright | Juggie: http://pastie.org/private/l8bi34m7a9qvyrievmqmqq |
| 21:06.32 | seanbright | use at your own peril |
| 21:06.45 | seanbright | and it's not perfect, but it's slightly better |
| 21:10.38 | Corydon76-lap | kpfleming: http://asterisk.drunkcoder.com/patches/app_stack.i |
| 21:12.29 | Juggie | kpfleming, from my recollection, it used to work. |
| 21:12.55 | Juggie | anyways no biggie, just something i noticed. |
| 21:13.22 | *** join/#asterisk-dev ZX81 (n=matt@202.49.106.158) |
| 21:13.32 | Damin | cd |
| 21:13.57 | Juggie | [damin@localhost asterisk]# |
| 21:15.56 | kpfleming | Corydon76-lap: so it looks just like the configure script code looks, but it fails |
| 21:16.03 | mvanbaak | better that then a python segfault when issueing ls |
| 21:16.11 | kpfleming | i wonder if it is because it is in a loadable module |
| 21:16.33 | kpfleming | although unless loadable modules are in use, weak aliases are pretty much pointless |
| 21:17.08 | kpfleming | no wait... you got the error during the compilation from .c to .o, so that's not it |
| 21:18.47 | Corydon76-lap | I got the error in compilation from .i to .o |
| 21:19.19 | kpfleming | yes |
| 21:19.20 | Corydon76-lap | and technically, it's a warning, not an error |
| 21:19.28 | kpfleming | but not linking, which is what i was concerned about |
| 21:19.36 | Corydon76-lap | Maybe our configure checks aren't designed to fail on warning |
| 21:19.52 | kpfleming | ahh, true |
| 21:19.57 | kpfleming | just a sec |
| 21:19.59 | wedhorn | mvanbaak: guess you've noticed the exchange re skinny.conf. Your call, I've actually nothing against leaving the patch (probably more sensible to have lines first). |
| 21:20.55 | mvanbaak | uhhuh |
| 21:20.55 | kpfleming | yes, they are |
| 21:20.55 | kpfleming | ast_gcc_attribute.m4 adds '-Werror' to the CFLAGS |
| 21:20.55 | wedhorn | mvanbaak: maybe there was a weird character in his conf |
| 21:20.55 | wedhorn | ??? |
| 21:21.08 | mvanbaak | wedhorn: must be. I had another look at the code and cant see why it fails for him |
| 21:21.44 | kpfleming | in any case, i think at this point the best course of action is to just make the build system force the compiler to target >= 10.2 |
| 21:22.35 | kpfleming | so what needs to be done again? a compiler flag, an environment variable? |
| 21:23.17 | Corydon76-lap | 1) detection of the header, 2) conditional inclusion of the header, followed by a single macro definition |
| 21:23.47 | Corydon76-lap | and I'd say in asterisk.h, so that we fail for extremely old versions of OS X, period |
| 21:24.10 | kpfleming | can someone give me ssh to a box i can test this on? |
| 21:24.25 | Corydon76-lap | Sure, hang on |
| 21:24.34 | mvanbaak | only if you're on ipv6 |
| 21:26.41 | kpfleming | it does not appear that that header file is going to do us any good |
| 21:26.53 | kpfleming | it only helps with making sure you don't use OS-level APIs that appeared in specific releases |
| 21:27.04 | kpfleming | it has nothing to do with compiler/linker/dynamic loader features |
| 21:27.20 | Corydon76-lap | Hmmm |
| 21:27.30 | kpfleming | i really think we are just going to have to compile for 10.2 as the target |
| 21:27.35 | kpfleming | if that solves the problem |
| 21:27.37 | Corydon76-lap | Well, I've tested using the environmental variable |
| 21:27.46 | Corydon76-lap | See privmsg |
| 21:27.56 | mvanbaak | wedhorn: so close the issue and leave the 'fix' in or revert the 'fix' |
| 21:28.31 | kpfleming | i saw it |
| 21:28.32 | kpfleming | thanks |
| 21:28.47 | Corydon76-lap | I was hoping to give you access to my PPC box, but VNC doesn't work so well from this distance |
| 21:29.02 | Corydon76-lap | and adding a user on the CLI is not very easy on OS X |
| 21:31.31 | *** join/#asterisk-dev ccesario_ (i=c92a9737@gateway/web/ajax/mibbit.com/x-6afbc4cdd9a266e6) |
| 21:36.34 | *** join/#asterisk-dev asteriskmonkey (n=philip@69.77.169.14) |
| 21:41.55 | sruffell | kpfleming: I think the plan for VMWI is going to change from what we discussed earlier today. After digging into it a little more, since we're going to have two ioctls anyway, I believe it makes more sense to leave the current ioctl as is to indicate the number of messages waiting on the channel, and create a separate ioctl that is for setting up the parameters for vmwi on the channel. |
| 21:42.12 | sruffell | FYI in case you can see any problems with that... |
| 21:42.42 | *** join/#asterisk-dev DarkRift (n=dark@bas1-sthubert21-1279640708.dsl.bell.ca) |
| 22:10.17 | seanbright | Juggie: did it work? |
| 22:10.19 | seanbright | or at least help? |
| 22:12.54 | Juggie | seanbright, i have not had a chance to test it yet |
| 22:12.57 | Juggie | doing real work :) |
| 22:29.03 | seanbright | ohhh |
| 22:32.04 | Juggie | ya, working on some TSQL, fun fun! :) |
| 22:33.12 | mvanbaak | quick, replace it with postgresql |
| 22:33.51 | mvanbaak | anyone here any knowledge with fixing alignment issues ? |
| 22:35.22 | mvanbaak | to be more exact: fixing SIGBUS on non-strict-alignment arch |
| 22:46.49 | kpfleming | sruffell: forgive my lack of knowledge, but how does that differ from the current ioctl behavior? |
| 22:48.11 | sruffell | Currently released ioctl only sets the number of messages. The current state of the trunk replaces that ioctl with one that allows you to set the number of messages waiting in addition to the type of MWI you would like (NEON, line polarity reversal, etc.). And the proposed new interface would be to split those into two separate ones, one that does what was the original interface, and a separate one for setting how to generate the |
| 22:48.53 | sruffell | The wctdm and wctdm24xxp driver only support polarity line reversal, xpp/card_fxs.c only support NEON_HVAC |
| 22:55.00 | kpfleming | i think that makes sense... the type of VMWI notification is a configuration-time (set it and forget it) ioctl, where the 'number of msgs waiting' will be used much more often |
| 22:55.21 | *** join/#asterisk-dev telecos (n=sergio@107.167.219.87.dynamic.jazztel.es) |
| 22:56.52 | sruffell | ok |
| 22:59.04 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:59.05 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 23:47.50 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:47.50 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 23:51.57 | *** join/#asterisk-dev otherwiseguy (n=otherwis@12.175.45.205) |