[Asterisk-Users] Realtime Friends

[Matthew Boehm]

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" <rod.bacon at empoweredcomms.com.au>
> To: "Matthew Boehm" <mboehm at cytelcom.com>; "Asterisk Users Mailing
> List - Non-Commercial Discussion" <asterisk-users at lists.digium.com>
> 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
>> Asterisk-Users at lists.digium.com
>> 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
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users