7 May
2003
7 May
'03
10:57 a.m.
Hello again !
Does anybody has working forwarding unanswered calls ?
I'm trying to do second day and nothing. :(
What does means parametr 9 in
append_branch("sip:nobody@iptel.org:9)
Why not 10 ?. Does it only need for
fr_inv_timer and fr_timer ??
Greetings
Andrzej Radke
7 May
7 May
11:46 a.m.
Hello,
On 5/7/2003 10:57 AM, Andrzej Radke wrote:
Hello again !
Does anybody has working forwarding unanswered calls ?
I'm trying to do second day and nothing. :(
What does means parametr 9 in
append_branch("sip:nobody@iptel.org:9)
append_brach has only one parameter, a string (quotes at the beginning
and end of the parameter). So 9 is not a parameter, it is the port of
the SIP address -- in this case, I think it is an example since the port
9 is a kind of /dev/null in networking -- everything sent there is
silently discarded. In real life you must replace it with the port where
the SIP client listens.
Best regards,
Daniel
Why not 10 ?. Does it only need for
fr_inv_timer and fr_timer ??
Greetings
Andrzej Radke
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8 May
8 May
9:51 a.m.
On Wed, 7 May 2003, Jan Janak wrote:
Hello,
On 07-05 10:57, 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
Thanks
Andrzej Radke
Hello again !
Does anybody has working forwarding unanswered calls ?
I'm trying to do second day and nothing. :(
What means nothing ? Do you get any error message ?
Jan.
4 p.m.
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.
9 May
9 May
2:42 p.m.
On Thu, 8 May 2003, Jan Janak wrote:
On 08-05 09:51, Andrzej Radke wrote:
Many thansk Jan :) for help. It works :)
But what does means information in my logs
May 9 13:02:41 ide /usr/sbin/ser[13006]: ERROR: t_newtran: EoH not parsed
May 9 13:02:41 ide /usr/sbin/ser[13006]: on_negative_reply: Error in do_action
Andrzej Radke
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.
12 May
12 May
2:06 p.m.
On 09-05 14:42, Andrzej Radke wrote:
On Thu, 8 May 2003, Jan Janak wrote:
Can you send me the message that caused this ? Does this happen
regularly ?
Jan.
On 08-05 09:51, Andrzej Radke wrote:
Many thansk Jan :) for help. It works :)
But what does means information in my logs
May 9 13:02:41 ide /usr/sbin/ser[13006]: ERROR: t_newtran: EoH not parsed
May 9 13:02:41 ide /usr/sbin/ser[13006]: on_negative_reply: Error in do_action 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.
3:57 p.m.
> >
> >
> Many thansk Jan :) for help. It works :)
> But what does means information in my logs
> May 9 13:02:41 ide /usr/sbin/ser[13006]: ERROR: t_newtran: EoH not parsed
> May 9 13:02:41 ide /usr/sbin/ser[13006]: on_negative_reply: Error in do_action
Can you send me the message that caused this ? Does
this happen
regularly ?
Jan.
Hi !
Everything works great as I wrote above.
This take place every time when the unanswered calls are forwarded to
another sip addresses and probably doesn't influence on SER
After specific time the call is forwarded
FYI.
I've only checked on 0.8.10 SER version
Greeting
Andrzej Radke
4:02 p.m.
On 12-05 15:57, Andrzej Radke wrote:
I recommend you to start using CVS version now.
Jan.
> >
> >
> Many thansk Jan :) for help. It works :)
> But what does means information in my logs
> May 9 13:02:41 ide /usr/sbin/ser[13006]: ERROR: t_newtran: EoH not parsed
> May 9 13:02:41 ide /usr/sbin/ser[13006]: on_negative_reply: Error in do_action
Can you send me the message that caused this ?
Does this happen
regularly ?
Jan.
Hi !
Everything works great as I wrote above.
This take place every time when the unanswered calls are forwarded to
another sip addresses and probably doesn't influence on SER
After specific time the call is forwarded
FYI.
I've only checked on 0.8.10 SER version 
11:28 a.m.
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?
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.
Thanks,
Miklos
Jan Janak wrote:
On 08-05 09:51, Andrzej Radke wrote:
--
---------------------------------------------------------------------------
Miklos Tirpak
Computer and Automation Research Institute e-mail : mtirpak(a)sztaki.hu
of the Hungarian Academy of Sciences phone : (361) 279-6011
H-1132. Budapest, Victor Hugo u 18-22 fax : (361) 279-6021
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();
}
3:04 p.m.
Hello,
there is no special operator for it, but you could use a regular
expression to match the first line, something like this:
if (search("^SIP/2\.0 4[0-9][0-9].*$")) {
# 4xx response
};
You will need to load textops.so module to enable this.
Note: the condition will match only requests generated by the callee --
i.e. requests that really have arrived over the network.
For example 4xx generated when fr_inv_timer hits and request is being
cancelled is generated locally and the condition will not match such a
response.
So you should do something like this:
if (search(^SIP/2\.0 4[0-9][0-9].*$")) {
# Negative response returned
} else {
# Request timed out
};
Note 2: I haven't tried this so it is without guarantee, let me know if
that works or not.
Jan.
On 12-05 11:28, 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?
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.
Thanks,
Miklos
Jan Janak wrote:
On 08-05 09:51, Andrzej Radke wrote:
--
---------------------------------------------------------------------------
Miklos Tirpak
Computer and Automation Research Institute e-mail : mtirpak(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 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();
}
20 May
20 May
1:14 a.m.
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:
--
Jiri Kuthan http://iptel.org/~jiri/
On 08-05 09:51, Andrzej Radke wrote:
--
---------------------------------------------------------------------------
Miklos Tirpak
Computer and Automation Research Institute e-mail : mtirpak(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 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();
}
10:44 a.m.
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.
The reason i am interesed in the status code of negative replies:
We have to differentiate the following cases:
1) The gateway works well, but every E1 channel is in use.
2) Some (or all) E1 are out of service
3) The gateway is not responding
4) 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 provider
If 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:
--
---------------------------------------------------------------------------
Miklos Tirpak
Computer and Automation Research Institute e-mail : mtirpak(a)sztaki.hu
of the Hungarian Academy of Sciences phone : (361) 279-6011
H-1132. Budapest, Victor Hugo u 18-22 fax : (361) 279-6021
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:
--
Jiri Kuthan http://iptel.org/~jiri/
On 08-05 09:51, Andrzej Radke wrote:
--
---------------------------------------------------------------------------
Miklos Tirpak
Computer and Automation Research Institute e-mail : mtirpak(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 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();
}
11:54 a.m.
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:
1) The gateway works well, but every E1 channel is in use.
2) Some (or all) E1 are out of service
3) The gateway is not responding
4) 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 provider
If 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:
--
Jiri Kuthan http://iptel.org/~jiri/
At 11:28 AM 5/12/2003, Tirpák Miklós wrote:
--
---------------------------------------------------------------------------
Miklos Tirpak
Computer and Automation Research Institute e-mail : mtirpak(a)sztaki.hu
of the Hungarian Academy of Sciences phone : (361) 279-6011
H-1132. Budapest, Victor Hugo u 18-22 fax : (361) 279-6021 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:
--
Jiri Kuthan http://iptel.org/~jiri/ 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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7658
days inactive
7671
days old
13 comments
5 participants
participants (5)
-
Andrzej Radke -
Daniel-Constantin MIERLA -
Jan Janak -
Jiri Kuthan -
Tirpák Miklós