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?
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
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.
At 10:56 PM 2/21/2003, Jamin W. Collins wrote:
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.
Then don't alter the URI it in your script. Let me know if it works for you now.
-Jiri
On Sun, Feb 23, 2003 at 09:43:24PM +0100, Jiri Kuthan wrote:
At 10:56 PM 2/21/2003, Jamin W. Collins wrote:
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.
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?
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
On Mon, Feb 24, 2003 at 01:07:14AM +0100, Jiri Kuthan wrote:
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.
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.
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.
Just passing on what I'm seeing. If there's more information that I can provide I'd be happy to.
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.
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.
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
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(); }
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
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.
At 09:34 PM 2/24/2003, Jamin W. Collins wrote:
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.
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
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.
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
-
Jamin W. Collins -
Jiri Kuthan -
Tomas Björklund