My silence comes from the fact that I didn't check my email yesterday. :) It was my impression that if a UA1 registered to server1 and UA2 registered to server2, and both servers were using ARA, then both servers should know how to reach both UAs.
I don't have two servers to test this on at the moment. My suggestion would be to take this to the developers list and see if what I theorized above is indeed the expected behavior of ARA. If it is, then we have a bug. If it is not, then we have a feature request. -Matthew Rod Bacon wrote: > Matt, can I assume from your silence that you concurr with my > thinking that realtime is in fact broken, or is it that I am using it > incorrectly? > > > ----- Original Message ----- > From: "Rod Bacon" <[EMAIL PROTECTED]> > To: "Matthew Boehm" <[EMAIL PROTECTED]>; "Asterisk Users Mailing > List - Non-Commercial Discussion" <[email protected]> > Sent: Wednesday, April 13, 2005 9:06 AM > Subject: [Asterisk-Users] Realtime Friends > > >> Matthew, I got the updates to start working again by ensuring that >> rtcachefriends=yes. I don't see why this should make a difference, >> but it does. My understanding was that this parameter only >> controlled the seeding of the in-memory friends list from the >> realtime db for purposes of MWI and KeepAlive. >> >> I have, however, one remaining issue that I need to resolve. >> >> Essentially, I am testing two Asterisk servers (Server1 ans Server2), >> configured to talk to a common database. I am trying to have calls >> placed on ANY server routed to SIP UAs registered on ANY OTHER >> server. >> >> Specifically; >> >> UA1 registers to Server1. DB is updated correctly. UA2 registers to >> Server2. DB is updated correctly. I can query the db (using REALTIME >> LOAD) from either server and see the correct SIP info for either UA. >> >> The central dialplan simply routes calls to SIP/UA1 or SIP/UA2. >> >> The problem is that Server1 ONLY knows about UA1 and Server2, UA2. >> The logic seems to be that the lookup in the extensions table >> (realtime dialplan) happens, then tries to route the call to a SIP >> registrant that is not in the local (in-memory) friends table. >> >> I thought the Server would then go back to the friends realtime >> table to get the registration info? Is this NOT how it is supposed >> to work? >> >> Should rtcachefriends force the server to update it's friends list on >> server startup, then at predetermined (configurable?) intervals? >> >> >> >> Matthew Boehm wrote: >>> (I removed the [] header cause that is what i base my email filter >>> on.) >>> >>> Rod Bacon wrote: >>> >>> >>>> I think there's a more sinister bug in play somewhere. The phones >>>> are on the same LAN. It was working when I only had a single >>>> asterisk server using the database, and seemed to stop when I >>>> added a second server. I know this doesn't make any sense... >>> >>> >>> OK. Lemme picture this. You had originally 1 asterisk server >>> and 1 database server. This worked fine with RealTime. Then you >>> added a second asterisk server to connect to this same database >>> server and now the phone won't register with either asterisk server? >>> >>> >>>> The SIP registration MUST be ok, because the in-memory database on >>>> the server that accepts the registration shows the correct >>>> information... the problem is that it doesn't write it to the >>>> database. >>> >>> >>> Oh. Weird. But if you turn off the 2nd asterisk server, >>> everything is fine? >>> >>> >>>> I think the bug must lie in the update code. When the registration >>>> is accepted, the update command is sending nulls to the database >>>> for some reason. >>> >>> >>> Yes, this is wierd cause I can't duplicate this. You don't have >>> entries >>> in BOTH sip.conf AND ARA do you? You said the phone does indeed >>> register, it >>> just doesn't update the database using RealTime? >>> >>> Is there any way you can send a full debug output starting >>> slighty before the phone tries to register? have you done a packet >>> sniff to see if >>> asterisk is indeed sending back a 200 OK to the register request? >>> >>> -Matthew >>> >> >> -- >> ========================================== >> Rod Bacon - VOIP Systems Engineer >> Empowered Communications >> Ground Floor, 102 York St. South Melbourne >> Victoria, Australia. 3205 >> Phone: +613 99401600 Fax: +613 99401650 >> ========================================== > > > -------------------------------------------------------------------------- ------ > > >> _______________________________________________ >> Asterisk-Users mailing list >> [email protected] >> http://lists.digium.com/mailman/listinfo/asterisk-users >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-user > > > _______________________________________________ > Asterisk-Users mailing list > [email protected] > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
