SER does not create aliases automatically (only serweb does so when
creating a new user account). Only the content of location table gets
updated automatically from REGISTER messages.
If the aliases are not correct then you can remove them using serctl and
create new ones.
Jan.
On 15-07 08:27, Dave Bath wrote:
Hey Jan,
I guessed this! Which is why I am confused. I have not created these
aliases... all I have done is registered three different UAs with three
different usernames (admin, test1, test2). This is why I don't
understand why there are all showing up. I think this may be why the
extensions have stopped ringing correctly, but I don't know why it has
happened.
Any suggestions? Tests? Anything to do with net configuration? SER
believing it is the same user agent registering each time?
Once any, many thanks for all the support being shown here.
Dave
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: 15 July 2004 08:22
To: Dave Bath
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Aliasing problem
aliases are not recursive, in other words you cannot do something like
this: alias1->alias2->alias3, SER would only translate alias1 into
alias2 and then forward the request there.
If you create several aliases for a single user (alias1->user1,
alias1->user2, alias1->user3) then all of them should ring because SER
will fork the INVITE.
Jan.
On 15-07 08:19, Dave Bath wrote:
Many thanks Jan. I rebuilt from the latest
source fc RPMS, so I have
no
idea why serctl was inaccurate. Fixed now tho!
My further problem with aliases might be my understanding, or there's
something funny happening. Basically, when having 2 or 3 UAs, calling
one of them results in random numbers of the other ones ringing as
well.. and usually the connecting party going straight to "connected"
state rather than ringing.
When I use serctl to examine the aliases, I see the following:
[root@sip dave]# serctl alias show admin
<sip:admin@<ip1>:5060>;q=0.00;expires=3524
<sip:test1@<ip2>:5060>;q=0.00;expires=2255
<sip:test2@<ip3>:5060>;q=0.00;expires=3565
[root@sip dave]# serctl alias show test1
<sip:admin@<ip1>:5060>;q=0.00;expires=2621
Am I completely misunderstanding how aliases work? But shouldn't admin
show something like <sip:admin@<ip1>:5060 blah blah> and test1 show
something like <sip:test1@<ip2>:5060 blah blah>?
Am I missing something? Any suggestions?
D
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: 15 July 2004 07:59
To: Dave Bath
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Aliasing problem
Older versions of serctl contain a bug that make the inserted aliases
to
expire immediately, that has been fixed a long
time ago, see:
http://lists.iptel.org/pipermail/serusers/2004-January/004949.html
Jan.
On 14-07 19:40, Dave Bath wrote:
> 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers