Summary:ASTERISK-15059: Calltoken and Realtime
Reporter:Thomas Athineou (thom4fun)Labels:
Date Opened:2009-10-31 05:51:02Date Closed:2011-06-07 14:07:25
Versions:Frequency of
Description:We update to

The option
is running fine in flat file but will be ignored in realtime static.

The option
in Realtime dynamic is running fine for register the iax client but make a call
will be rejected, because calltoken is required.

Are there any way to get the old client to work where the IAX.Conf is stored in realtime static and the clients are stored in Realtime dynamic?



Database will be postgrSQL
Comments:By: Leif Madsen (lmadsen) 2009-11-02 11:36:27.000-0600

What was the former version you upgraded from?

By: Thomas Athineou (thom4fun) 2009-11-02 11:48:10.000-0600

Old version was

By: Thomas Athineou (thom4fun) 2009-11-05 07:02:47.000-0600


is there a way to work around???

By: Leif Madsen (lmadsen) 2009-11-05 09:35:35.000-0600

The only work around I can see is going back to where you say you're not experiencing the issue. I don't see how the security fix that is in could actually cause this though...

By: Leif Madsen (lmadsen) 2009-11-05 09:43:28.000-0600

Actually, this should have been an issue in as well; was only a change for ACL in chan_sip, and would have made absolutely no difference in this case.

However, apparently this issue has already been resolved, so please test the code from SVN:

svn co http://www.asterisk.org/svn/asterisk/branches/1.6.1 asterisk-1.6.1-vanilla

Compile and install as per usual.

By: Thomas Athineou (thom4fun) 2009-11-05 15:56:14.000-0600

Yes that is true, has the same issue.

I do not know what asterisk-1.6.1-vanilla means and the link above dont work, so I have a try with and there is this issue to.
Also there are some more problems (also in where SIP and IAX clients are stored in Realtime Static AND Dynamic databases. It seems to me that there are very big problems with realtime. So I do not know what to do now.
Give me please some more time to test.

By: Leif Madsen (lmadsen) 2009-11-06 09:30:12.000-0600

Typo on my part:

svn co http://svn.asterisk.org/svn/asterisk/branches/1.6.1 asterisk-1.6.1-vanilla

asterisk-1.6.1-vanilla doesn't mean anything; it's just a directory name where the branch will be checked out to. I just call it 'vanilla' because it means there are no custom changes. You can name it anything you want. will be no different from If you read the release announcement and look at the ChangeLog, you will see it was only a security release based on, which was another security release based on

Testing with the latest check out from subversion is the best way to test and see if there are still existing issues. The other issues you mention for realtime should be filed separately.

Personally I've used realtime in many situations and it works for me. However I don't mix both static and dynamic at the same time.

By: Thomas Athineou (thom4fun) 2009-11-09 15:54:57.000-0600

Thanks a lot for your help.
I use realtime in many situations to, and with a lot of fun, because I am really a database junky. But now we have a situation where we need a very dynamic version of asterisk. So I have a look for a really “realtime” Asterisk. And the idea was to store the user in dynamic and the provider in static databases, update the databases via web interface and make a reload via AGI. It sounds great, and it works great. But in every version is a bug where it makes it impossible to use.

Now we have a good try with
We will only use SIP provider, store the IAX base in flat file with dynamic buddies in database, SIP is working fine completely in database, have also a mix of extensions (static and dynamic) , and have not a straight, but a working way to go.

(But the bug is going on: the calltokenoptional= stored in realtime static will be ignored...)


By: Leif Madsen (lmadsen) 2009-11-09 16:10:00.000-0600

If you look at the release announcements for and, along with the ChangeLogs, you will notice that is no different from other than the security release. No bug fixes are present in those versions because they were security releases.

Please try if you plan on testing for bug fixes, or alternatively from the branch in SVN.

By: Leif Madsen (lmadsen) 2009-12-07 14:58:37.000-0600

makafre on #asterisk seems to be experiencing the same problems, so this is likely an issue that needs to be investigated.

By: Leif Madsen (lmadsen) 2009-12-15 11:35:28.000-0600

Can you provide the relevant database row contents and which context you set the contents of the configuration in?

By: Leif Madsen (lmadsen) 2009-12-22 11:19:50.000-0600


By: Thomas Athineou (thom4fun) 2009-12-23 06:37:19.000-0600

I am sorry for delay... I do not have an database with this problem, because there will be no function with our clients. But if there will be no other way, let me know that I have to rebuild a test environment for this problem.

By: Leif Madsen (lmadsen) 2009-12-23 11:49:23.000-0600

I don't understand your statement. We're just looking for the data involved in the database, which can be done by a SELECT, which would have no impact on your clients server. Either that, or I'm totally misunderstanding you.

By: Thomas Athineou (thom4fun) 2009-12-28 06:43:51.000-0600

Hello Imadsen, I do not have any database with this problem, because we have a need of old clients, which do not know something about calltoken.
So we are back to 1.4.26

If you are not being able to reproduce this error, I have to rebuild / configure a server, a database, a client …

And in front of this work I would know if it is necessary.

By: Tilghman Lesher (tilghman) 2009-12-28 09:16:44.000-0600

thom4fun:  looks like we have a language barrier.  Could you find somebody who understands English better to translate this for you?  You're not translating the request correctly.

By: Thomas Athineou (thom4fun) 2009-12-28 09:42:38.000-0600


Please be so kind and give me your question again.

By: Leif Madsen (lmadsen) 2010-01-04 13:56:11.000-0600

Please see this note:  https://issues.asterisk.org/view.php?id=16159#115279

By: Leif Madsen (lmadsen) 2010-01-18 09:03:21.000-0600

Suspending issue due to lack of feedback from the reporter. Please reopen if you're able to provide the requested information.