Hello,
first of all, I would recommend you to use 0.8.11 instead of 0.8.10, it
is worth upgrading because 0.8.11 fixes many bugs and shortcomings.
On 06-11 11:37, Garey, Tim wrote:
I have successfully installed ser 0.8.10. on a PC
running Red Hat Linux.
Detailed OS and SER versions
are at the end of this message.
I am not using SQL or Digest/HTTP Authentication. I want to keep things as
simple as
possible until I gain more experience with ser.
if (method=="INVITE") {
rewriteuri("sip:6032251114@172.17.4.102");
forward(172.17.4.102);
1. Why am I receiving multiple invites? Especially after Phone B answers and
it's 200OK is received by SER, I see
another 6 invites (in addition to several extra's at the beginning of the
message). If I hang up before SER sends
the last one phone B will ring. It takes about 30 seconds or so to stop.
Are you forwarding the mesages in ser using forward command ? If so
then it is your user agent who retransmits the messages because
forward implements stateless forwarding.
If you are using t_relay() then probably ser is unable to match the
transaction of the original INVITE when receiving 100 Trying.
Again, I would recommend you to upgrade your ser to 0.8.11 and retry.
Also use t_relay() instead of forward().
2. What routing logic can I insert to take any invite
starting with 603-225-
and forward it
to the softswitch with the correct dialed digits. The above works great but
is hard coded
for just one number.
You can use rewritehostport("172.17.4.102") instead of rewriteuri.
That will rewrite only the host part of the Request-URI and it will
not touch username (number). You can then forward it to the softswitch
using t_relay();
3. What similar routing logic can I insert to take any
invite starting with
603-753 and send it to to phones
registered on the SER side?
for that we use if (uri==mysql) condition. The condition will match
for any request that is targeted to the IP or hostname of your SER
server. Requests for users registered with your SER server will have
IP or hostname of your SER server in the Request-URI so this condition
will be true.
You then need to call lookup("location") inside the condition to get
the current location of the user from the user location database. See
the default configuration script, it does exactly what you need.
Jan.