[Home]

Summary:ASTERISK-04567: Enabling rtcachefriends prevents phones on different servers from calling each other
Reporter:Rana Dutt (rdutt)Labels:
Date Opened:2005-07-12 09:51:41Date Closed:2005-07-31 21:37:39
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:With rtcachefriends = yes in sip.conf, my SIP phone registered to Asterisk Server A cannot dial another SIP phone registered to Asterisk Server B. The error message is: "Cannot create channel of type SIP (Cause 3 - no route to destination)".

The two phones _can_ call each other if I set rtcachefriends = no. The common extensions.conf simply uses Dial(SIP/extension) to dial extensions.

Both Asterisk servers are using identical MySQL databases, kept in sync using replication. The sipusers tables in both databases show the correct dynamic IP address and port for both phones, indicating that the phones did register successfully. And the dynamic registration information is reflected in both databases because of the MySQL replication.  

However, running "sip show peers" on Server A only shows the phone registered to Server A. Running the same command on Server B only shows the phone registered to Server B.

So despite the fact that phone B's registration data (IP address and port) is in Server A's database, the Asterisk on Server A doesn't know how to route the call to phone B. It looks like Asterisk is using cached data and ignoring the database, but the registration info for phone B never got into the cache.

I need rtcachefriends enabled, because I need MWI to work.

****** ADDITIONAL INFORMATION ******

> Kevin P. Fleming wrote:
>> Matthew Boehm wrote:

>> Can't it be changed so that if Server A has stored an "unknown address" for
>> phone B that if it needs to contact B again it should look up in the
>> database to "try" and contact it instead of just giving up? Perhaps
>> rtagressive option? Contact only, not storing info in cache.

> "Can" it be done? Of course, it's all just code :-)

> I think it would be reasonable to add that as an option, but the number
> of Realtime-related options is rapidly getting out of hand and people
> will not be able to understand what they all do and how they interact...
Comments:By: Kevin P. Fleming (kpfleming) 2005-07-12 10:00:25

This is in no way, shape or form a MAJOR bug, since Asterisk is not documented to operate in the way you have asked. I have reclassified this as a feature request, but unless you can find someone to implement it for you it will likely get closed in a few days and you'll have to post a request/bounty on the wiki.
By: Brian West (bkw918) 2005-07-14 10:52:54

This is like the third time this has come up.. we did a patch on the ignore expire bug that kp closed out that fixes this.  The issue is the fullcontact isn't stored in the datbase.  The patch on the ignoreexpire bug adds support for storing the fullcontact into the database like it should have done from day one.

/b
By: Brian West (bkw918) 2005-07-14 10:54:38

for the record its on this bug http://bugs.digium.com/view.php?id=4362

chan_sip.diff
By: Kevin P. Fleming (kpfleming) 2005-07-14 20:43:04

That is _not_ this problem at all, as best I can tell, it's completely unrelated. If the phone registers to server A, and server B attempts to make a call to the phone _before_ it has registered to server A, server B will have cached in memory the fact that the phone is unreachable.

Using 'ignoreexpire' would allow server B to use the info from a potentially expired registration, but it will _not_ cause server B to flush its cache and re-read the peer's info from the database after server A has changed it. Any solution that does not inform all the other servers that the database info has been changed is doomed to only working in very simple situations, as otherwise the server caches will become stale and calls will go to the wrong places.

The only simple change I can see coming from this discussion is to allow the Realtime code to _not_ cache a peer it reads from the database if the peer is unregistered or expired (the exact opposite of 'ignoreexpire'). At least in that situation, if the phone has not registered when server B tries to place a call to it, server B won't remember that in memory and refuse to look in the database again until the rtcache timeout expires. If someone wants to post a patch to implement that behavior, I'll happily review it.

I will agree fully that the methods that are currently used to store contact/expiration info in astdb and the Realtime database need some rethinking, but I cannot see how that is related to this issue.
By: Brian West (bkw918) 2005-07-17 17:53:51

The fullcontact is needed for it to work properly.  I currently have this setup on a 7+ system cluster.. that streaches from east to west coast.  It works because the fullcontact is accessable from all systems.  Right now the full contact is stored in the ASTDB on the server the phone registers with.  Now if you register a phone with server A we'll say friend "bob".  Ok now you have Server B trying to call SIP/bob, it can't because we don't have the full contact handy to actually form the proper invite... thus it will fail.

And yes this is the exact issue the bug reporter is talking about.

/b
By: drmac (drmac) 2005-07-20 11:48:35

since ip, port and ua name are already stored in database, cant you just construct the fullheader with those 3 columns?

phone a reg's to server 1
phone b reg's to server 2
b calls a.

server 2 says "hmm, I don't know anything about phone a. lets see if there is a phone a in the db. ahh..there is, lets use the info from these 3 columns to create_addr and contact this phone. i should also keep this info in cache incase i need to call phone a again."
By: Brian West (bkw918) 2005-07-20 11:54:01

dmarc no you can't trust that to be 100% correct.

/b
By: drmac (drmac) 2005-07-20 13:07:11

oh..i see..like in the case of a NAT'd UA:

Addr->IP: 22.22.22.22 port 59887
Reg Contact: sip:phonea@192.168.1.10:5060

hmm..so I guess you would need to store both pieces of info into the db.
By: Michael Jerris (mikej) 2005-07-31 21:36:08

The patch on 4832 is additional functionality to address this issue.  Closing this out as a duplicate.  If the patch on that bug does not resolve your issue please re-open this bug.