21 Feb
2003
21 Feb
'03
9:33 p.m.
This is probably a very simple question. I'm trying to create a very
simplistic configuration that simply forwards the call to one of two
fixed destinations. Essentially, it forwards all calls to server A and
if that fails, forwards the call to server B. Forwarding to server A is
no problem. Within route, I simply have:
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (len_gt( max_len )) {
sl_send_reply("513", "Message too big");
break;
};
rewriteFromRoute();
if (!forward("192.168.1.1")) {
sl_reply_error();
};
This works perfectly, but only forwards to one server. I tried changing
the last bit to:
if (!forward("192.168.1.1")) {
if (!forward("192.168.0.1")) {
sl_reply_error();
};
};
However, this results in "ERROR: bad config file (5 errors)".
Any suggestions? Is something like this possible?
--
Jamin W. Collins
21 Feb
21 Feb
11:03 p.m.
Funny, I copy'n'pasted the config file in my SER and it worked.
You may want to look at your log files to see what is the error.
There is a tougher issue though: you never know with stateless
forwarding whether a transaction completed or not. You only know
that sending did not fail (e.g., due to lack of memory). You
need to switch over to stateful processing to achieve the fail-
over capability. The voicemail example is similar to what you
want to do.
http://www.iptel.org/ser/doc/seruser-html/x510.html#AEN616
-Jiri
At 08:33 PM 2/21/2003, Jamin W. Collins wrote:
This is probably a very simple question. I'm
trying to create a very
simplistic configuration that simply forwards the call to one of two
fixed destinations. Essentially, it forwards all calls to server A and
if that fails, forwards the call to server B. Forwarding to server A is
no problem. Within route, I simply have:
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (len_gt( max_len )) {
sl_send_reply("513", "Message too big");
break;
};
rewriteFromRoute();
if (!forward("192.168.1.1")) {
sl_reply_error();
};
This works perfectly, but only forwards to one server. I tried changing
the last bit to:
if (!forward("192.168.1.1")) {
if (!forward("192.168.0.1")) {
sl_reply_error();
};
};
However, this results in "ERROR: bad config file (5 errors)".
Any suggestions? Is something like this possible?
--
Jamin W. Collins
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
11:56 p.m.
On Fri, Feb 21, 2003 at 10:03:25PM +0100, Jiri Kuthan wrote:
Funny, I copy'n'pasted the config file in my
SER and it worked.
You may want to look at your log files to see what is the error.
There is a tougher issue though: you never know with stateless
forwarding whether a transaction completed or not. You only know
that sending did not fail (e.g., due to lack of memory). You
need to switch over to stateful processing to achieve the fail-
over capability. The voicemail example is similar to what you
want to do.
http://www.iptel.org/ser/doc/seruser-html/x510.html#AEN616
That seems to be almost what I'm after. However, I would rather not
alter the original URI at all. I simply need to forward the connection
to one of two different servers. If I'm reading that VM example right,
it's altering the URI for each step.
--
Jamin W. Collins
23 Feb
23 Feb
10:43 p.m.
At 10:56 PM 2/21/2003, Jamin W. Collins wrote:
On Fri, Feb 21, 2003 at 10:03:25PM +0100, Jiri Kuthan
wrote:
Then don't alter the URI it in your script. Let me know if it works for you now.
-Jiri
Funny, I copy'n'pasted the config file in
my SER and it worked.
You may want to look at your log files to see what is the error.
There is a tougher issue though: you never know with stateless
forwarding whether a transaction completed or not. You only know
that sending did not fail (e.g., due to lack of memory). You
need to switch over to stateful processing to achieve the fail-
over capability. The voicemail example is similar to what you
want to do.
http://www.iptel.org/ser/doc/seruser-html/x510.html#AEN616
That seems to be almost what I'm after. However, I would rather not
alter the original URI at all. I simply need to forward the connection
to one of two different servers. If I'm reading that VM example right,
it's altering the URI for each step.
24 Feb
24 Feb
1:30 a.m.
On Sun, Feb 23, 2003 at 09:43:24PM +0100, Jiri Kuthan wrote:
At 10:56 PM 2/21/2003, Jamin W. Collins wrote:
It's something of a catch-22. If I use a stateless forward, the server
that it's forwarded to sees the connection as originating from the
actual phone's IP. If I use a stateful forward, the connection is seen
as coming from the SER server itself, and as a result the audio path
fails. For the stateful forward to work, I believe I would need the
phones to register their presence with the SER server, right?
Is there a way to configure it so the phones are not required to
register with the SER proxy?
--
Jamin W. Collins
That seems to be almost what I'm after.
However, I would rather not
alter the original URI at all. I simply need to forward the
connection to one of two different servers. If I'm reading that VM
example right, it's altering the URI for each step.
Then don't alter the URI it in your script. Let me know if it works
for you now.
2:07 a.m.
At 12:30 AM 2/24/2003, Jamin W. Collins wrote:
It's something of a catch-22. If I use a stateless
forward, the server
that it's forwarded to sees the connection as originating from the
actual phone's IP.
There is some disconnect here -- be a request forwarded by a proxy
statefuly or statelessly, it arrives always in the same shape to
the destination. In particular, proxy server's address is in IP
packet's source address and in Via.
If I use a stateful forward, the connection is seen
as coming from the SER server itself, and as a result the audio path
fails.
Audio is sent to the address advertised in SDP, which is not
manipulated by SER.
For the stateful forward to work, I believe I would
need the
phones to register their presence with the SER server, right?
Unless you wish to write scripts like
"if (uri=~"sip:joe@.." { forward("1.2.3.4") ....
you will want to keep track of users in automated manner. That's
what registration is good for. Once a user registers, messages
can be sent to him in either mode: stateless or stateful. The latter
gives some more abilities, like forking. See
http://www.iptel.org/ser/doc/seruser.html#AEN839
Is there a way to configure it so the phones are not
required to
register with the SER proxy?
You don't need to configure your server so that phones do not
regsiter with it -- that's a phone configuration issue. however,
it will not be easy to route requests to your phones if they do
not register.
-Jiri
4:47 a.m.
On Mon, Feb 24, 2003 at 01:07:14AM +0100, Jiri Kuthan wrote:
Just passing on what I'm seeing. If there's more information that I can
provide I'd be happy to.
Right now, the phones are configured on the two destination servers.
So, these servers can send calls directly to the phones. However, for
things to work properly (outbound calls and such), the server needs to
see the incoming request as originating from the phone's IP address,
which is why the stateful forwarding is currently a problem.
--
Jamin W. Collins
At 12:30 AM 2/24/2003, Jamin W. Collins wrote:
I'm just passing on what I'm seeing. If I forward the request with
forward("192.168.1.16"), the server shows the connection as the IP
address of the originating phone. However, if I use
t_relay_to("192.168.1.16", "5060"), the server shows the connection
as
coming from the SER server and the connection never truly completes.
I've also tried different variations with append_branch and t_relay,
these have led to similar results as the t_relay_to.
It's something of a catch-22. If I use a
stateless forward, the
server that it's forwarded to sees the connection as originating
from the actual phone's IP.
There is some disconnect here -- be a request forwarded by a proxy
statefuly or statelessly, it arrives always in the same shape to the
destination. In particular, proxy server's address is in IP packet's
source address and in Via. If I use a
stateful forward, the connection is seen as coming from
the SER server itself, and as a result the audio path fails.
Audio is sent to the address advertised in SDP, which is not
manipulated by SER. Is there a way
to configure it so the phones are not required to
register with the SER proxy?
You don't need to configure your server so that phones do not
regsiter with it -- that's a phone configuration issue. however,
it will not be easy to route requests to your phones if they do
not register.
12:37 p.m.
At 03:47 AM 2/24/2003, Jamin W. Collins wrote:
I'm just passing on what I'm seeing. If I
forward the request with
forward("192.168.1.16"), the server shows the connection as the IP
address of the originating phone. However, if I use
t_relay_to("192.168.1.16", "5060"), the server shows the connection
as
coming from the SER server and the connection never truly completes.
I don't understand what it means "server shows the connection coming
from XY". What server do you exactly mean? What does it mean it
shows connection? (Does it display SDP IP address, or source IP
address of a SIP request, or Contacts or something completely else?)
Just passing on what I'm seeing. If there's
more information that I can
provide I'd be happy to.
Message dumps would be probably clarifying in this case. Use for example
"ngrep port 5060" to capture SIP traffic.
Right now, the phones are configured on the two
destination servers.
So, these servers can send calls directly to the phones. However, for
things to work properly (outbound calls and such), the server needs to
see the incoming request as originating from the phone's IP address,
I don't understand this either -- I mean if you for some reason (like
like of digest authentication) wish to verify IP addresses in SER, then
you do so, if you don't wish, you don't. What is the problem?
which is why the stateful forwarding is currently a
problem.
And how does it relate to whether you forward in stateless or stateful mode?
-Jiri
8:22 p.m.
I'm not able to replicate the situation I described previously. Perhaps
I was simply confused, over stressed, or hallucinating.
Allow me to attempt to explain the current configuration and what I'm
trying to accomplish. Perhaps there is a simpler way of doing what I
need?
Configuration Information
SER - 192.168.0.3
CIC - 192.168.1.16
Phone1 - 192.168.0.14 (Cisco 7960)
- registered with SER as st2030 with a uri of sip:st2030@192.168.0.14
- registered with CIC as 2030 with a uri of sip:st2030@192.168.0.3
Phone2 - 192.168.0.34 (Snom 200)
- registered with SER as st2111 with a uri of sip:st2111@192.168.0.4
- registered with CIC as 2111 with a uri of sip:2111@192.168.0.3
Registrations on CIC are hard coded. SER registrations are done by each
phone.
Both Phone1 and Phone2 register their presence with SER (confirmed via
serctl)
Both Phone1 and Phone2 have the SER server listed as their outbound
proxy.
Currently, any destination physically on the CIC server (internal
prompts and routing) work just fine from either Phone1 or Phone2. So,
SER is routing the calls to CIC correctly. Additionally, calls from
Phone1 to Phone2 through only SER (by stXXXX names) work fine (full
audio).
The problem is that calls through both SER and CIC alert but don't
appear to complete. That is if Phone1 calls Phone2 (or vice versa) by
their numeric extensions on CIC the destination phone will ring but not
connect (no audio).
So, to summarize, calls from either phone through SER to CIC work fine,
as do calls from either phone to the other through only SER. However a
call from either phone through SER to CIC and back through SER to the
other phone do not.
You might ask why involve both the CIC and SER when the phones could
quite easily communicate with the CIC server directly. This is but one
step in a larger configuration. There will be a central CIC server and
many branch locations connected via a WAN. The SER servers will sit at
the branch locations and forward all calls (with a few exceptions such
as 911) to to the central CIC server for handling. Calls need to go
through the central CIC server for tracking/reporting purposes. Thus,
it is possible that a call from an agent at one branch will route
through the SER to the central CIC server only to be routed back through
the same SER proxy to another agent at the same branch. The need for
the SER proxies comes about with things like 911. With the SER proxy
and a PSTN gateway, emergency calls can still be routed when the WAN
connection to the central server is down.
My understanding of the flow in this instance is as follows (please
correct me if I'm wrong):
- Phone2 dials 2030.
- SER performs a lookup for sip:2030@192.168.0.3 that fails.
- SER rewrites the host address to Server1 (192.168.1.16) and state-fully
forwards the call to sip:2030@192.168.1.16
- Server1 performs a lookup for sip:2030@192.168.1.16 and finds that it
should connect to sip:st2030@192.168.0.3
- SER performs a lookup for sip:st2030@192.168.0.3 and finds that it
should connect to sip:st2030@192.168.0.14
- Phone1 rings
- Phone1 answers, audio path should be connected but is not.
Here is my current SER configuration:
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
fifo="/tmp/ser_fifo"
listen="192.168.0.3"
# ------------------ module loading ----------------------------------
loadmodule "/usr/lib/ser/modules/sl.so"
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/rr.so"
loadmodule "/usr/lib/ser/modules/maxfwd.so"
loadmodule "/usr/lib/ser/modules/usrloc.so"
loadmodule "/usr/lib/ser/modules/registrar.so"
loadmodule "/usr/lib/ser/modules/exec.so"
# ----------------- setting module-specific parameters ---------------
modparam("usrloc", "db_mode", 0)
modparam("tm", "fr_inv_timer", 5 )
modparam("tm", "fr_timer", 5 )
# ------------------------- request routing logic -------------------
# main routing logic
route{
rewriteFromRoute();
if (uri==myself) {
if (method=="REGISTER") {
log(1, "registration");
save("location");
break;
};
if (!lookup("location")) {
rewritehost("192.168.1.16");
t_relay();
break;
};
};
t_relay();
}
--
Jamin W. Collins
9:54 p.m.
What is CIC?
Send us network dumps please -- that will make it easier to understand for us.
You can for example use "ngrep port 5060".
[...]
My understanding of the flow in this instance is as
follows (please
correct me if I'm wrong):
- Phone2 dials 2030.
- SER performs a lookup for sip:2030@192.168.0.3 that fails.
- SER rewrites the host address to Server1 (192.168.1.16) and state-fully
forwards the call to sip:2030@192.168.1.16
- Server1 performs a lookup for sip:2030@192.168.1.16 and finds that it
should connect to sip:st2030@192.168.0.3
- SER performs a lookup for sip:st2030@192.168.0.3 and finds that it
should connect to sip:st2030@192.168.0.14
- Phone1 rings
- Phone1 answers, audio path should be connected but is not.
That may have so many reasons that I really cannot even guess what
it might be without seeing the dumps.
-Jiri
10:34 p.m.
On Mon, Feb 24, 2003 at 08:54:00PM +0100, Jiri Kuthan wrote:
What is CIC?
A PBX made by I3 (www.inin.com)
Send us network dumps please -- that will make it
easier to understand
for us. You can for example use "ngrep port 5060".
Network dump from the SER server is attached.
--
Jamin W. Collins
11:03 p.m.
At 09:34 PM 2/24/2003, Jamin W. Collins wrote:
On Mon, Feb 24, 2003 at 08:54:00PM +0100, Jiri Kuthan
wrote:
snom phone is a common suspect again.
The first signaling transaction looks ok. The only unusual thing is that
for some reason, the ININ server advertises 192.168.0.9 as media receiver
whereas its signaling lives at 192.168.1.16. Is media decomposed?
The really suspicious is the second transaction. The snom phone sitting
at .36 advertises contacts with .34 in its replies. That makes the
caller (ININ) to send an ACK to .34. Snom does not received it and
keeps soliciting it by retransmitting 200s.
-Jiri
What is CIC?
A PBX made by I3 (www.inin.com)
Send us network dumps please -- that will make it
easier to understand
for us. You can for example use "ngrep port 5060".
Network dump from the SER server is attached.
25 Feb
25 Feb
8:31 p.m.
On Mon, Feb 24, 2003 at 10:03:35PM +0100, Jiri Kuthan wrote:
The first signaling transaction looks ok. The only
unusual thing is
that for some reason, the ININ server advertises 192.168.0.9 as media
receiver whereas its signaling lives at 192.168.1.16. Is media
decomposed?
Looks like that was the problem. Switched the IP of the CIC system to
192.168.0.9 and things are working beautifully now. Strangely the CIC
system had hard coded the IP address and didn't fully take the IP
change when it was made a while back.
Now on to see if I can properly configure it to use two CIC servers.
--
Jamin W. Collins
21 Feb
21 Feb
11:58 p.m.
New subject: [Serusers] Path to sc (serctl)
Hi,
I was getting tired of starting/stopping ser by hand so i added
stop/start/restart functionality to serctl
Se patch (made to cvs version 1.41)
Best regards,
Thomas Björklund
7944
days inactive
7948
days old
13 comments
3 participants
participants (3)
-
Jamin W. Collins -
Jiri Kuthan -
Tomas Björklund