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.

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?

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.

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(); }

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.

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.