| 04:22.24 | *** join/#asterisk-doc Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 08:01.15 | *** join/#asterisk-doc snuff-ho1e (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 12:12.28 | *** join/#asterisk-doc Phixion (n=hoSSohbe@88.224.159.249) |
| 12:12.39 | Phixion | hi ? |
| 12:12.45 | jsmith | Hello Phixion |
| 12:13.02 | Phixion | hi jsmith , i have a problem..could you please help me ? |
| 12:14.03 | Phixion | you there? |
| 12:15.21 | jsmith | Phixion: It depends... this isn't the channel to discuss regular Asterisk problems, but if you ask you're question, I'll try to answer it |
| 12:15.46 | Phixion | oh thank..i have ordered the g729 codec licence from digium |
| 12:16.01 | Phixion | but i didnt got any email or something contains the key-id |
| 12:16.13 | Phixion | where can i get it do you know? |
| 12:16.30 | jsmith | You can email support@digium.com, or call them. |
| 12:16.44 | Phixion | i have mailed them about 2 hours ago.. |
| 12:17.09 | jsmith | Phixion: You have to understand that they can't answer every email immediately... they get a *lot* of email |
| 12:17.22 | jsmith | Have you checked your SPAM filter to make sure it didn't end up there? |
| 12:17.31 | jsmith | Or, like I said, you could try calling them. |
| 12:17.50 | Phixion | ok i will try to call them..but .. bad english.. |
| 12:21.13 | jsmith | Do you have an order number? |
| 12:21.31 | jsmith | If so, I can try to get ahold of them |
| 12:21.36 | Phixion | yes i have |
| 12:28.41 | *** join/#asterisk-doc snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 13:53.18 | *** join/#asterisk-doc RobH (n=RobH@rob.tech.wikimedia.org) |
| 14:40.13 | lmadsen | jsmith: |
| 14:40.13 | lmadsen | >> Is there a way not to loose active calls durring failover? |
| 14:40.13 | lmadsen | > |
| 14:40.13 | lmadsen | > Not an easy way, no, because call state is stored in memory, not on disk |
| 14:40.15 | lmadsen | > or in the database. The only reliable way to not lose calls in progress |
| 14:40.17 | lmadsen | > would be to somehow replicate the memory between two boxes (which is |
| 14:40.19 | lmadsen | > neither cheap nor easy to accomplish, but by no means impossible). |
| 14:40.21 | lmadsen | <PROTECTED> |
| 14:40.23 | lmadsen | is that how IBM did it? |
| 14:40.28 | lmadsen | thx for replying to that thread |
| 14:40.34 | jsmith | Yup |
| 14:41.04 | jsmith | They used specialized hardware and some additions to the Asterisk code to essentially copy the memory between to machines |
| 14:42.11 | jsmith | Dolphin also builds something similar |
| 14:42.13 | jsmith | http://www.wulfkit.com/corporate/scitech.html |
| 14:42.15 | brac | [Dolphin Interconnect Solutions Inc. - SCI Technology] |
| 14:42.48 | lmadsen | neato |
| 14:43.07 | lmadsen | that would be a HUGE boon to Asterisk if someone figured out how to make 2 boxes failover between each other and not lose the calls |
| 14:43.17 | lmadsen | I'm not saying it'd be easy, but it's certainly be a handy feature :) |
| 14:43.39 | file | nods |
| 14:54.51 | jsmith | lmadsen: It's a very non-trivial problem to solve |
| 14:55.16 | jsmith | lmadsen: If effect, there's *so much* data that has to be pushed back and forth that it's almost impossible to do and do right |
| 14:55.27 | jsmith | (at least doing it at that level) |
| 14:55.32 | file | well... |
| 14:57.08 | ctooley | Depends on the type of call. |
| 14:57.43 | ctooley | Complexity definitely goes up with the level of tolerance in how much audio can be missed during switchover. |
| 14:57.50 | lmadsen | jsmith: oh I understand the non-triviality of the probem |
| 14:57.52 | ctooley | Also depends on how "failure" is detected. |
| 15:00.24 | ctooley | signaling in SIP is rather easy to failover (at least compared to RTP), but RTP can certainly be done. |
| 15:00.43 | jsmith | ctooley: Well, I'm taking a step back and thinking multi-protocol here... IAX, SIP, Zap |
| 15:00.59 | jsmith | ctooley: I know *you* are up to your neck in SIP, but Asterisk is multi-protocol :-) |
| 15:02.02 | ctooley | jsmith, yeah, IAX should be relatively similar to SIP in that regard, though. |
| 15:02.02 | ctooley | Zap on the other had is very complex. |
| 15:02.23 | ctooley | There's not a good way to make POTS lines for instance takeover someone else's call. |
| 15:12.20 | ctooley | With a PRI it's technically plausible, but highly ineffective. |
| 15:13.11 | ctooley | With an SS7 PRI it's very similar to the transition that occurs with SIP, but Asterisk neither supports those nor would they be cheap to get from a provider. |
| 15:18.34 | ctooley | With something that has signaling to tell the remote party to move the call it's a large hurdle, but feasible. With something like POTS, it's not even reasonable to attempt. |
| 15:23.39 | lmadsen | jsmith: do you have any experience with MySQL clustering? Know of a good book? |
| 15:24.57 | lmadsen | basically we're trying to figure out the best way of making multiple sites have a DB that they can write to locally which is part of a cluster for multiple asterisk systems |
| 15:25.07 | lmadsen | so I'm in research mode now :) |
| 15:25.17 | file | ah yes... |
| 15:25.43 | file | that approach. |
| 15:25.47 | jsmith | lmadsen: Nope... I refuse to further my learning with regards to MySQL |
| 15:26.36 | lmadsen | lol, fair enough :) |
| 15:26.46 | lmadsen | ya... unfortunately this was promised for a client :( |
| 15:26.55 | lmadsen | so now I get stuck in figuring out how to make it all work |
| 15:27.15 | lmadsen | they are independent sites, and need to work independently from each other if they lose connection to the primary site |
| 15:28.03 | file | but need to be up to date when possible |
| 15:28.39 | lmadsen | aye |
| 15:28.54 | lmadsen | oh, and did I mention they have to be able to write-local as well? |
| 15:29.03 | lmadsen | even when the master is offline, then sync up when reconnected |
| 15:29.31 | ctooley | lmadsen, they need to be a "cluster" or they need multiple sites to be able to have a database that is also located somewhere else that could "take over" being the master database? |
| 15:29.52 | lmadsen | they need to have a distributed DB basically |
| 15:30.11 | lmadsen | multiple sites, each with a DB at each location, that when written to, puts the data on all other sites |
| 15:30.26 | lmadsen | but when disconnected from other sites, continue running, then reconnect gracefully once reconncted |
| 15:30.50 | ctooley | lmadsen, sounds more like replication to me. |
| 15:31.55 | jsmith | ctooley: Sounds like "multi-master" replication |
| 15:32.12 | ctooley | jsmith, right |
| 15:32.27 | lmadsen | which is what we're trying to achieve... every DB has to be a "master" |
| 15:32.39 | ctooley | As long as the schemas are different for each location, it's not really an issue |
| 15:32.44 | ctooley | lmadsen, that's perfectly fine. |
| 15:32.53 | lmadsen | huh? it's the same schema |
| 15:32.55 | ctooley | Each DB server can be a master and a slave at the same time. |
| 15:33.05 | lmadsen | how many? and does that need to run in a chain? |
| 15:33.12 | lmadsen | because for example... we have 6 sites |
| 15:33.14 | ctooley | gimme a minute |
| 15:33.30 | jsmith | coughs... bucardo.org... |
| 15:33.42 | lmadsen | you say that like it was obvious... |
| 15:34.09 | lmadsen | asynchronous :( |
| 15:34.27 | lmadsen | unfortunately for our application... since it's a call centre, we need it to be synchronous |
| 15:34.35 | lmadsen | otherwise we don't know the state of calls on other servers |
| 15:34.54 | file | good luck. |
| 15:35.01 | ctooley | You most likely do not want "clustering" anyway |
| 15:35.03 | lmadsen | postgres? can't use that |
| 15:35.32 | lmadsen | ctooley: oh? |
| 15:35.44 | ctooley | A) clustering requires all tables in RAM |
| 15:35.44 | jsmith | You want synchronous multi-master + the ability to run disconnected?!? |
| 15:36.04 | ctooley | B) clustering doesn't allow accurate replication. |
| 15:36.04 | lmadsen | hey, I didn't promise this :) |
| 15:36.05 | jsmith | Aren't they mutually exclusive? |
| 15:36.52 | lmadsen | I want synchronous when connected to the cluster, but the ability to still run independently should they become disconnected from the master |
| 15:36.58 | ctooley | jsmith, technically "circular" replication can work between two sites. It's trickier to set up between more than 2 |
| 15:37.14 | ctooley | and it's dangerous to run in general |
| 15:37.30 | jsmith | ctooley: But by definition, if you're doing *synchronous* replication, then you have to have a quorum |
| 15:37.44 | jsmith | ctooley: And if your site is disconnected, it's by definition not a quorum |
| 15:38.03 | file | quorum... I like that |
| 15:38.54 | jsmith | file: That's the technical term... but it has a nice ring to it |
| 15:39.28 | file | that is a solid word. |
| 15:40.28 | DarkFlib | really, you don't want mysql type replication... you want something a little more like how BGP works... |
| 15:41.32 | DarkFlib | ie. on connection they swap their tables and rebuild it... on disconnection they drop anything that is from the other host... between those times they sync normally |
| 15:42.10 | DarkFlib | but I don''t know anything that does that at the application level... |
| 15:44.44 | jsmith | Hey DarkFlib... long time, no chat! |
| 15:44.53 | DarkFlib | yeah.... been avoiding you... |
| 15:44.55 | DarkFlib | :P |
| 15:45.10 | jsmith | DarkFlib: I don't blame you. I'd avoid me if I were anybody else, too! |
| 15:45.31 | DarkFlib | hows the number getting on for the fedora project? |
| 15:45.54 | ctooley | is splitting focus between database failover and implementing SIP call failover. :( |
| 15:48.09 | *** join/#asterisk-doc km2 (n=x@c-24-23-255-173.hsd1.ca.comcast.net) |
| 15:48.27 | DarkFlib | has been setting up a dyndns type system lately... probably gonna leverage it for enum... |
| 15:52.15 | ctooley | jsmith, I assume that you are considering the possibility that site A needs to modify stuff that site B cares about. I wouldn't expect that. |
| 15:52.54 | jsmith | DarkFlib: Working on it this morning, finally. :-/ |
| 15:53.20 | ctooley | Only in the event that site B fails and site A needs to take over would that be something I'd consider recommended, and then site B would need to be allowed to "catch up" before it became "active" again. |
| 15:54.05 | jsmith | ctooley: Absolutely... for some applications, as long as site B sees a version of site A's data that existed in the past, that's OK. But if lmadsen wants it to keep *current* state and not just *consistent state at some point in history*, he's got a long row to hoe. |
| 15:54.35 | lmadsen | jsmith: not quite -- only when it is connected to the DB does B care about the data A supplies, other than that, it just needs to care about its own status |
| 15:54.40 | ctooley | jsmith, that shouldn't be too difficult with circular replication. |
| 15:54.58 | jsmith | builds a token-ring network and passes ctooley the token |
| 15:55.22 | DarkFlib | watches as ctooley hides the token and feigns ignorance |
| 15:55.48 | lmadsen | when everything is working, everything needs to be synchronous between the sites... but if say... Site G is disconnected from the network (or the hub fails), then all the sites just need to run as if they weren't clustered anymore |
| 15:55.51 | ctooley | looks at the token, sees it's not for him, and passes it along |
| 15:56.32 | lmadsen | we obviously won't be getting data from the other sites, and at that point, we won't care |
| 16:01.13 | wwalker | lmadsen: what is supposed to happen when site G can again communicate with the others? |
| 16:01.37 | lmadsen | it should get up to date, and continue on as part of the cluster |
| 16:01.53 | lmadsen | it should tell everyone, "this is my current state, what is yours"? |
| 16:02.04 | lmadsen | then sync, then continue merrily on its way |
| 16:02.39 | *** join/#asterisk-doc ctooley_ (n=ctooley@209.33.106.165) |
| 16:03.09 | ctooley_ | jsmith, that token ring idea is actually a fairly interesting one. |
| 16:03.42 | jsmith | ctooley_: I wouldn't have mentioned it if I didn't think it was relevant |
| 16:04.21 | lmadsen | what happens when the chain is broken though... no one down the chain gets updated |
| 16:05.44 | ctooley_ | lmadsen, a good token ring network has multiple paths |
| 16:05.56 | ctooley_ | And therefore can handle a cable break. |
| 16:06.04 | ctooley_ | would be very tricky to set up though. |
| 16:06.10 | lmadsen | aye |
| 16:06.19 | lmadsen | you essentially get back into a hub and spoke topology :) |
| 16:06.31 | ctooley_ | lmadsen, not really |
| 16:06.43 | wwalker | I'd use local talbes at each site for autoincrment id numbers. each site assigned it's own number 1M, 2M, 3M.... |
| 16:07.10 | ctooley_ | that's what I originally suggested, but he's wanting it all to be "intermingled" |
| 16:07.12 | wwalker | then have a daemon at each site watch for new rows on the remote DBs and pull the rows into the local everything DB |
| 16:07.44 | wwalker | decisions are made on the local everything DB, but once a server becomes available agin you "catch up" automatically. |
| 16:08.17 | wwalker | all the data is duplicated. It's in each hosts local table, and in every hosts intermingled table. |
| 16:08.32 | wwalker | it's a coupld of seconds behind real time. |
| 16:09.39 | wwalker | lmadsen: would different nodes update the same row at different times? |
| 16:10.44 | lmadsen | no, I don't think so |
| 16:10.58 | lmadsen | i.e. there shouldn't be a race condition if that's what you're thinking |
| 16:12.49 | ctooley_ | then separate schemas shouldn't be an issue either, a "entire company" set of views could be set up. |
| 16:13.59 | lmadsen | well right now we're using tables that allow queue members to log in and out, so those rows will only ever be updated by one person, and then we generate views based on those tables |
| 16:14.00 | wwalker | if no race conditions, then what I proposed should work. |
| 16:15.00 | wwalker | the tables would have to have last_modified fields |
| 16:15.15 | ctooley_ | wwalker, your daemon would have to either use modified fields or use binlog playback. |
| 16:15.26 | ctooley_ | to see the queries and execute them. |
| 16:19.37 | wwalker | X = select last_modified from local where id >= 1000000 and id < 2000000 order by last_modified desc limit 1; |
| 16:19.40 | wwalker | replace into local (select * from remote 1 where last_modified > X); |
| 16:20.16 | wwalker | loop through that once for each remote site. |
| 16:20.54 | wwalker | the "remote" would be a federated table to make the remote database accessible locally. This could be done entirely in SQL I think |
| 16:22.50 | wwalker | this would allow you to stay as close to realtime as you want to load the network down. |
| 16:23.08 | wwalker | I'd put a 1 second sleep at the end of the loop before running it again. |
| 20:09.50 | *** join/#asterisk-doc RobH (n=RobH@cpe-72-184-129-136.tampabay.res.rr.com) |
| 20:49.15 | jsmith | DarkFlib: Still awake? |
| 21:24.13 | lmadsen | is! |
| 21:30.02 | *** join/#asterisk-doc km2 (n=x@adsl-75-52-246-33.dsl.pltn13.sbcglobal.net) |
| 22:37.50 | *** join/#asterisk-doc km2 (n=x@c-24-23-255-173.hsd1.ca.comcast.net) |
| 22:59.30 | DarkFlib | yes |
| 23:05.24 | lmadsen | jsmith-away: ^^^ |
| 23:08.42 | DarkFlib | I saw... but he might just be playing dead... |
| 23:08.45 | DarkFlib | :P |
| 23:08.49 | DarkFlib | I sometimes do |
| 23:09.36 | lmadsen | :D |
| 23:09.43 | lmadsen | ya... I thought I'd try and get his attention :) |
| 23:10.11 | DarkFlib | although just now I was spending time with the family... step-moms father isn't expected to last the night |
| 23:19.37 | DarkFlib | is setting up enum atm for himself and a small group of peers |
| 23:21.54 | lmadsen | fun stuff :) |
| 23:22.37 | DarkFlib | pretty basic... |