[Serusers] Aliasing problem

Wed Jul 14 21:45:51 CEST 2004

Hey thanks, that did fix it.  Now if I do a serctl show alias 1000 I see
Admin listed, and it's listed under the "Your Aliases" section of
serweb.  I still don't understand why there wasn't an error thrown back
by serctl.  Does anyone know which field from the database is needed, as
conceivably someone might have a phone number for longer than a year,
and I don't want to have to renew all the aliases... 

Best regards,

Dave

________________________________

From: Ezequiel Colombo [mailto:ecolombo at arcotel.net] 
Sent: 14 July 2004 20:17
To: Dave Bath; serusers at lists.iptel.org
Subject: Re: [Serusers] Aliasing problem

FOREVER_REL contain the value used by serctl to set the Expires time of
the contact alias added.

If this value is too large the value result a hugh value for the column
type of the aliases table.

	----- Original Message ----- 

	From: Dave Bath <mailto:dave at fuuz.com>  

	To: serusers at lists.iptel.org 

	Sent: Wednesday, July 14, 2004 4:01 PM

	Subject: [Serusers] Aliasing problem

	Hey Ezequiel,

	Many thanks for the quick response!  Yeah, sorry, I should have
mentioned I already have persistent storage for the user tables -
they're all stored using mode2, I was just checking with all the
references to "aliases stored in cache" that they were actually written
to the db as well.

	Could you explain what the FOREVER_REL value is?  Why would the
value be too high? Too large a number of the type of storage in the
mysql table? 

	Also, does anyone know why the serctl script says the alias was
added, but it doesn't seem to have been..?

	Many thanks again everyone,

	D

________________________________

	From: Ezequiel Colombo [mailto:ecolombo at arcotel.net] 
	Sent: 14 July 2004 19:54
	To: Dave Bath; serusers at lists.iptel.org
	Subject: Re: [Serusers] Aliasing problem

	Dave, you must turn no the persistent storage of the usrloc
table. After this the contacts added in the memory table can be dumped
to mysql.

	You can also check in the script serctl if the value of the
variable FOREVER_REL is appropiate or is too high for your mysql aliases
table and cause the INSERT to fail. In my network i have reduced this
value to FOREVER_REL=31536000 (one year).

	... FROM README FILE OF USRLOC MODULE ...

	1.3.10. db_mode (integer)

	   The usrloc module can utilize database for persistent contact
	   storage. If you use database, your contacts will survive
	   machine restarts or sw crashes. The disadvantage is that
	   accessing database can be very time consuming. Therefore,
	   usrloc module implements three database accessing modes:

	     * 0 - This disables database completely. Only memory will
be
	       used. Contacts will not survive restart. Use this value
if
	       you need a really fast usrloc and contact persistence is
	       not necessarry or is provided by other means.
	     * 1 - Write-Through scheme. All changes to usrloc are
	       immediately reflected in database too. This is very slow,
	       but very reliable. Use this scheme if speed is not your
	       priority but need to make sure that no registered
contacts
	       will be lost during crash or reboot.
	     * 2 - Write-Back scheme. This is a combination of previous
	       two schemes. All changes are made to memory and database
	       synchronization is done in the timer. The timer deletes
	       all expired contacts and flushes all modified or new
	       contacts to database. Use this scheme if you encounter
	       high-load peaks and want them to process as fast as
	       possible. The mode will not help at all if the load is
	       high all the time. Also, latency of this mode is much
	       lower than latency of mode 1, but slightly higher than
	       latency of mode 0.

	   Warning

	   In case of crash or restart contacts that are in memory only
	   and haven't been flushed yet will get lost. If you want
	   minimize the risk, use shorter timer interval.

	   Default value is 0.

	   Example 1-10. Set db_mode parameter
	...
	modparam("usrloc", "db_mode", 2)
	...

		----- Original Message ----- 

		From: Dave Bath <mailto:dave at fuuz.com>  

		To: serusers at lists.iptel.org 

		Sent: Wednesday, July 14, 2004 3:40 PM

		Subject: [Serusers] Aliasing problem

		Hey guys,

		I have been playing with SER for a few days now, and
apart from having to rebuild all the RPMs to get it working on FC1 with
mysql4 (mysql4 is apparently not officially supported in FC1 ?!)
everything was smooth and dandy.  Really enjoying using such a powerful
and flexible product. 

		However, I have one problem, and I've done my best to
trawl all the groups and lists, and debug it myself and I cannot work
out what is going on - perhaps I just don't understand how it works
properly.  I am trying to set numerical aliases so that incoming routing
can be handled more easily by a PSTN gateway.  I am trying the command:

		Serctl alias add 1000 sip:admin@<sipserver>

		I get a reply that the alias has been added (once a
previous message on this list pointed out that I needed to add
lookup("aliases"); to ser.cfg)!

		The problem is the mysql table is still empty - although
serctl says that the alias has been added, it doesn't seem to have been.
When I try and call "1000" I get a 404 not found, but calling "admin"
works fine.  

		Does anyone have any ideas?! 

		Also, on a slight side note, I was assuming that the
aliases are reboot-safe... they're stored in the database and will get
reloaded if ser is rebooted.  Is this the case by default or does an
option need to be enabled?

		Sorry for the long post.  Many thanks to everyone who
has worked on this, and it would be fantastic to get this last bit
sorted out.

		Cheers,

		Dave

		Inmarsat Ltd

		Global Satellite Communications

		Regional BGAN Engineer

________________________________

		_______________________________________________
		Serusers mailing list
		serusers at lists.iptel.org
		http://lists.iptel.org/mailman/listinfo/serusers

________________________________

	_______________________________________________
	Serusers mailing list
	serusers at lists.iptel.org
	http://lists.iptel.org/mailman/listinfo/serusers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20040714/ae62ebc8/attachment.htm>