At 10:44 AM 5/20/2003, Tirpák Miklós wrote:
Hi Jiri,
Thank you, the example confing of nathelper will be good for me, and i will also try Jan's suggestion. The backup gateway has been not configured yet, so i will try it a bit later.
Another, a better-related config example is examples/serial_183.cfg -- it applies failure handling, which is however reset if the first gateway sends a 183. Let me know how you move on.
thanks,
-Jiri
The reason i am interesed in the status code of negative replies:
We have to differentiate the following cases:
- The gateway works well, but every E1 channel is in use.
- Some (or all) E1 are out of service
- The gateway is not responding
- The negative replay was casued by the isdn provider (unknown number, busy, they have an error ...)
and so on...
The architecture:
PSTN provider | | -------------- isdn --------------- | university |-------| isdn/sip gw |
| ---------------other universities---| SER |
/ \ ----------------- ----------------- | 1.sip/isdn gw | | 2.sip/isdn gw | ----------------- ----------------- ||| ||| PSTN provider PSTN providerIf the 1. gw returns a negative replay we have to decide what to do: try the 2. one, or pass the replay back to the caller. The universities also have their own connection with a PSTN provider, but the prices are different (in general higher). So the question is when to allow the university to use it's own backup line.
Miklos
Jiri Kuthan wrote:
At 11:28 AM 5/12/2003, Tirpák Miklós wrote:
Hi,
Is there any way to check the returned status code of the response in "failure_route[1]"? Or how can i decide if the request timed out or negative response returned?
There is not any -- actually, I don't think it matters too much as non-responsive UAS is of the same use as a negatively responding one.
I would like to use a backup SIP-ISDN gateway. So if the master fails i would like to resend the requests to the backup. The reason of the negative replay (or timeout) matters in this case.
Why? An option you can try is undocumented reply processing. See the example config file in nathelper module. -jiri
Thanks, Miklos
Jan Janak wrote:
On 08-05 09:51, Andrzej Radke wrote:
The request is not forwarded to another sip address after specific time ( i.e. 10 s) Isn't forwarded never. Maybe something wrong with my configuration script ?? Could You look into my configuration file http://lists.iptel.org/pipermail/serusers/2003-May/001276.html
I just tried and it worked. Attached find a simple configuration file that I used. I set fr_inv_timer to 10s (default value is 120s) and tried to call a user. If the user didn't pick up in 10s then the original call was cancelled and another invite was sent to user 7271.
Jan.
# # $Id: ser.cfg,v 1.18 2003/05/06 16:19:15 janakj Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ debug=9 # debug level (cmd line: -dddddddddd) fork=no log_stderror=yes # (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=195.37.78.191 loadmodule "./modules/tm/tm.so" modparam("tm", "fr_inv_timer", 10) route { if (method=="INVITE") { t_on_failure("1"); }; t_relay(); } failure_route[1] { log("!!!!!!!!!!!!!!! HIT\n"); revert_uri(); setuser("7271"); append_branch(); t_relay(); }
Miklos Tirpak Computer and Automation Research Institute e-mail : mtirpak@sztaki.hu of the Hungarian Academy of Sciences phone : (361) 279-6011 H-1132. Budapest, Victor Hugo u 18-22 fax : (361) 279-6021
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
--
Miklos Tirpak Computer and Automation Research Institute e-mail : mtirpak@sztaki.hu of the Hungarian Academy of Sciences phone : (361) 279-6011 H-1132. Budapest, Victor Hugo u 18-22 fax : (361) 279-6021
-- Jiri Kuthan http://iptel.org/~jiri/