| 00:36.50 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 03:12.49 | *** join/#asterisk-dev jmls1 (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 04:33.04 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 06:16.53 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 07:10.04 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 07:10.04 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 07:11.31 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 10:12.32 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:25c5:17c6:2c57:a004) |
| 10:16.59 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 10:17.23 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:39.49 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:25c5:17c6:2c57:a004) |
| 10:55.34 | *** join/#asterisk-dev jmls (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 11:26.48 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:26.48 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:54.51 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:54.51 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:58.47 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 13:10.48 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-idpnigzczdpllmhz) |
| 13:10.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:26.42 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:26.48 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:30.19 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ytynnescdkegljsx) |
| 13:51.34 | *** join/#asterisk-dev jacobw (~jacobw@fedora/jacobw) |
| 13:52.20 | jacobw | hi, i'm looking for information on call holding using reinvite messages with sdp a=sendonly, is this in development? |
| 13:59.40 | Marquis42 | jacobw: What do you mean by "information". If you're trying to find semantics of how that works, then it's more of a "Google for an explanation" thing. |
| 14:02.13 | opticron | jacobw, it is partially supported in asterisk at the moment |
| 14:03.22 | mjordan | opticron: do you mean its partially supported because it does not apply to all media format types? |
| 14:03.55 | opticron | that, and it doesn't support receiving "recvonly", iirc |
| 14:05.20 | opticron | see process_sdp_a_sendonly in chan_sip.c |
| 14:05.32 | file | based on the message in #asterisk I believe jacobw is actually asking about *sending* that - ie passing through hold |
| 14:05.45 | file | which is not currently supported for chan_sip, and nobody is working on it afaik |
| 14:06.19 | opticron | jacobw, ^^ |
| 14:08.53 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:08.54 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:23.08 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:23.10 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:42.53 | mjordan | kpfleming: so, based on the valgrind output from that particular issue, the 'off nominal' path would occur if the execution of a query failed but we determined that we had the ability to attempt a reconnect to the database |
| 14:44.44 | kpfleming | ok, so if a particular ODBC driver doesn't support reconnects, then that code wouldn't be executed. |
| 14:45.18 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:45.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:56.33 | mjordan | kpfleming: correct, if the SQL statements are being executing as a transaction then a reconnect is never attempted. Based on their logs, the reconnection attempt does occur, and then either the same query that is being reattempted or a subsequent one ends up performing an invalid free. |
| 14:56.46 | kpfleming | lovely |
| 15:08.23 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 15:22.58 | sruffell | tzafrir_laptop: is oron around? |
| 15:23.10 | tzafrir_laptop | sruffell, no |
| 15:23.19 | sruffell | k, thanks. |
| 15:34.04 | jacobw | opticron, file, thanks |
| 15:50.35 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 16:11.03 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:07.30 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:22.17 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:07.03 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:07.03 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:43.32 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 18:43.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:11.28 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 19:45.41 | pabelanger | Looks like speakers for Astricon are out: http://www.astricon.net/2012/speakerBIOfull.aspx |
| 19:51.41 | kpfleming | pabelanger: and you are listed as being with Digium :-) |
| 19:52.07 | pabelanger | woohoo, expense paid right? |
| 19:52.12 | file | I don't think a picture of me with a hat will fit in the Asterisk... |
| 19:52.38 | pabelanger | file, do eh |
| 19:52.41 | pabelanger | et* |
| 19:53.05 | file | top hat certainly not |
| 19:58.09 | kpfleming | jrose_atDigium: in order for your named ACLs to be easy to modify when they live in a database, i think you *will* need to come up with some way to specify the order of processing |
| 19:58.35 | kpfleming | combining them into a single 'permit' column is going to be quite unfriendly to processes that want to modify them |
| 20:05.45 | leifmadsen | pabelanger: heck ya all expenses paid! |
| 20:14.02 | pabelanger | leifmadsen, hookers and blow all around |
| 20:14.18 | leifmadsen | lol |
| 20:19.07 | oej | Found a bug in our sessin-timers implementation. |
| 20:21.19 | jrose_atDigium | Alright, so I'm going to redesign the table for the ACLs in the realtime database from having a split primary key of name and order to having just the one primary key for name... |
| 20:21.30 | jrose_atDigium | instead of having a sense field and a rule field, I'm going to just have the rule field. |
| 20:21.39 | kpfleming | you didn't read the comments i posted above about 8 lines |
| 20:22.03 | kpfleming | oej: good, bugs that are found can be fixed |
| 20:22.19 | jrose_atDigium | Yeah, I did, I was just talking about the approach I was thinking of... but if you don't like that, I can go with my original instinct too. |
| 20:22.48 | kpfleming | how would the approach you just posted address the ordering issue? |
| 20:23.18 | jrose_atDigium | I mean the original approach. |
| 20:23.22 | oej | jrose: Having systemname may be a good setting to use |
| 20:23.24 | jrose_atDigium | Have the order specified as part of the primary key. |
| 20:23.43 | kpfleming | you don't need to worry about whether it's a primary key or not, that's the database implementor's decision. |
| 20:23.52 | kpfleming | you just need to focus on the data to be stored and how it will be used. |
| 20:24.04 | kpfleming | but i think that having an 'order' column will be necessary indeed. |
| 20:24.19 | jrose_atDigium | Yes, if each rule needs to take place on its own row. |
| 20:24.30 | kpfleming | right |
| 20:24.41 | jrose_atDigium | oej: What do you mean by 'systemname' setting? |
| 20:25.02 | kpfleming | he means having a column for systemname, so that the same table can hold ACLs for multiple systems |
| 20:25.09 | oej | right |
| 20:25.23 | oej | But you might also want to share the same table between systems, therefore a setting |
| 20:25.33 | kpfleming | so that means your retrieval code needs to have the option to include the systemname in the query criteria |
| 20:25.43 | jrose_atDigium | Oh, ok. |
| 20:26.03 | jrose_atDigium | So that's just a general setting for acl.conf then that can be specified and if it is, it includes that as a rule in the realtime_multientry query. |
| 20:26.45 | kpfleming | right |
| 20:26.55 | jrose_atDigium | simple enough |
| 20:27.10 | jrose_atDigium | alright, so the way it's working right now... |
| 20:27.36 | jrose_atDigium | I have a table with the acl name, and the rule order along with all the info needed for the rule itself (sense and address/mask) |
| 20:27.57 | kpfleming | sounds logical |
| 20:28.25 | jrose_atDigium | when searching for an ACL by name, if it isn't in the configs, I'm using ast_load_realtime_multientry to get a config that includes all the rows for a given acl name. |
| 20:29.08 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.40.134) |
| 20:29.08 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:29.16 | jrose_atDigium | At this point, if I got a config, I'm iterating through each category in the config to see if it's the rule I want (starting with 0 and going up from there) and if it's the one I want, I append it to the ast_ha I'm building. |
| 20:30.08 | jrose_atDigium | Right now I'm removing the categories that I've already added, but that could actually slow things down if the stuff sent by the database is wildly out of order, so I'm not sure on that. |
| 20:30.08 | kpfleming | you might be able to include ORDER BY criteria in the realtime query. i don't remember. |
| 20:30.56 | jrose_atDigium | Well, I haven't seen any code that does that, and I tried to just add an "ORDER BY rule" parameter before the SENTINEL and that just gave me a segfault that I haven't delved too deeply into yet. |
| 20:31.00 | jrose_atDigium | It'd be nice though. |
| 20:31.22 | jrose_atDigium | It might be worth creating another realtime_multientry function for too. |
| 20:31.43 | kpfleming | well, part of the issue there is that realtime != SQL. not all realtime back ends can do sorting. |
| 20:32.05 | jrose_atDigium | Yeah, I suppose I have to have a backup plan anyway then. |
| 20:32.38 | kpfleming | but searching for specific order numbers is a bad idea, because that requires the entries in the database to have consecutive order numbers, which should not be necessary. |
| 20:32.52 | kpfleming | you are probably best off to just sort the data you get before you start processing it |
| 20:32.57 | oej | We have that setting for sip registrations in sip.conf |
| 20:33.26 | jrose_atDigium | Ok, so I actually will be needing to do a proper sort then. |
| 20:33.32 | kpfleming | i think so |
| 20:43.30 | jrose_atDigium | Ok, so here is another random question on realtime and named ACLs: Right now, The whole updated ACL pushing events to other consumers thing is still a little bit in its infancy, but ACL reloads will trigger such an event and consumers react to that. Do we need to make any particular effort to react to realtime changes? If we don't, it seems that consumers will never update their ACLs to be current with what's in the realt |
| 20:43.31 | jrose_atDigium | ime database, and that just seems kinda wonky IMO. |
| 20:44.12 | jrose_atDigium | I don't really know if there is a way to do that either though. |
| 20:49.52 | oej | I still don't get why consumers need to react. |
| 20:49.59 | oej | please explain for an old man. |
| 20:50.27 | oej | In my code, they just have pointers to the acls and apply them when needed. In that case they don't need to be aware of a change. |
| 20:50.40 | jrose_atDigium | From what I understand of this... |
| 20:50.51 | jrose_atDigium | If you have an active dialog, changing the ACL mid dialog can do nasty things. |
| 20:51.17 | jrose_atDigium | Like if you start rejecting reinvites in a SIP dialog because the ACL changes... |
| 20:52.08 | oej | Yes, that may be an affect |
| 20:52.22 | oej | If you have sip session timers, the dialog will be killed (and if they work) |
| 20:52.52 | oej | That will happen if I have fail2ban active and it changes IP tables too. It's a desired result of changing an ACL. |
| 20:53.21 | jrose_atDigium | And of course there are other consumers of ACLs which may have similar caveats. |
| 20:53.41 | jrose_atDigium | It's safer in general to make the ACL persist for at least the duration of the dialog. |
| 20:54.07 | kpfleming | right, that's our biggest concern. just like we don't change the allowed codecs list in the middle of a dialog's lifetime, we shouldn't change the ACLs either. |
| 20:54.13 | jrose_atDigium | When to actually go in and fix things, right now I believe that's up to the consumer. |
| 20:54.20 | kpfleming | that's also true. |
| 20:54.41 | kpfleming | if chan_sip wants to apply some ACL changes immediately to all active dialogs for a peer, and defer others to new dialogs, then it can do that. |
| 20:55.55 | oej | THat means you have to copy named ACLs into the dialog |
| 20:56.08 | kpfleming | that is correct |
| 20:56.11 | oej | So they have became "template ACLs" and not named acls anymore. |
| 20:56.21 | oej | This has to be documented in detail. |
| 20:56.29 | kpfleming | no, they preserve their names, and can be replaced in the future when they change. |
| 20:56.36 | kpfleming | and it will be documented, with tests written. |
| 20:57.20 | oej | If I have an offending device I want to disable it immediately, regardless of dialogs |
| 20:57.26 | oej | Hmmm. |
| 20:57.38 | oej | Going off line, it's late. |
| 20:57.41 | oej | Bye for now. |
| 20:57.44 | kpfleming | right. i still don't quite understand the value of doing that specific action in asterisk, though. |
| 20:58.06 | oej | PRACK on good night ;-) |
| 20:58.09 | kpfleming | most of the time it's much better to do that outside of asterisk, on the system or in a router. |
| 20:58.15 | kpfleming | oej: sleep well! |
| 20:58.23 | oej | PRACK, PRACK, ACK |
| 21:48.10 | *** join/#asterisk-dev w9sh (~chatzilla@50-79-224-193-static.hfc.comcastbusiness.net) |
| 22:01.38 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-idpnigzczdpllmhz) |