27 May
2004
27 May
'04
3:35 p.m.
I have the following logic.
route {
...
t_on_reply("1");
t_on_failure("1");
t_relay();
}
onreply_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
}
failure_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
if (status=="408") {
do something 1
} else if (status=="480") {
do something 2
} else if (status=="486") {
do something 3
}
}
When a reply with 4xx comes in, it first goes through onreply_route[1] and
get the result printed to syslog. The message is then passed to
failure_route[1]. But it seems that the status code and reason are gone. I
get a <null> for both values in the failure route. How should I change the
script to get that.
Zeus Ng
27 May
27 May
3:43 p.m.
failure_routes process the initial request, not the reply which caused
the failure.
Daniel
On 5/27/2004 3:35 PM, Zeus Ng wrote:
I have the following logic.
route {
...
t_on_reply("1");
t_on_failure("1");
t_relay();
}
onreply_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
}
failure_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
if (status=="408") {
do something 1
} else if (status=="480") {
do something 2
} else if (status=="486") {
do something 3
}
}
When a reply with 4xx comes in, it first goes through onreply_route[1] and
get the result printed to syslog. The message is then passed to
failure_route[1]. But it seems that the status code and reason are gone. I
get a <null> for both values in the failure route. How should I change the
script to get that.
Zeus Ng
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:08 p.m.
failure_routes process the initial request, not the
reply
which caused
the failure.
I'm not trying to process reply which caused the failure. Instead, I want to
process the failure on the initial request. The problem is, a reply, no
matter it's 1xx, 2xx, 3xx will always goes through reply route first. Then
goes to failure route.
E.g.
UA1 -> SER -> UA2
If UA2 reply "486 Busy" to SER, the reply will be processed by reply route
first (due to t_on_reply()) and then failure route (due to t_on_failure()).
What I expected is any reply code >= 400 should be processed by failure
route only.
Daniel
On 5/27/2004 3:35 PM, Zeus Ng wrote:
I have the following logic.
route {
...
t_on_reply("1");
t_on_failure("1");
t_relay();
}
onreply_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
}
failure_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
if (status=="408") {
do something 1
} else if (status=="480") {
do something 2
} else if (status=="486") {
do something 3
}
}
When a reply with 4xx comes in, it first goes through
onreply_route[1]
and get the result printed to syslog. The message
is then passed to
failure_route[1]. But it seems that the status code and reason are
gone. I get a <null> for both values in the failure route.
How should I
change the script to get that.
Zeus Ng
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
9:16 p.m.
You can try something like:
failure_route[1] {
if ( t_check_status("486") ) {
.
do whatever
.
}
}
Zeus Ng wrote:
--
Andres
Network Admin
http://www.telesip.net
failure_routes
process the initial request, not the reply
which caused
the failure.
I'm not trying to process reply which caused the failure. Instead, I want to
process the failure on the initial request. The problem is, a reply, no
matter it's 1xx, 2xx, 3xx will always goes through reply route first. Then
goes to failure route.
E.g.
UA1 -> SER -> UA2
If UA2 reply "486 Busy" to SER, the reply will be processed by reply route
first (due to t_on_reply()) and then failure route (due to t_on_failure()).
What I expected is any reply code >= 400 should be processed by failure
route only.
Daniel
On 5/27/2004 3:35 PM, Zeus Ng wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
I have the following logic.
route {
...
t_on_reply("1");
t_on_failure("1");
t_relay();
}
onreply_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
}
failure_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
if (status=="408") {
do something 1
} else if (status=="480") {
do something 2
} else if (status=="486") {
do something 3
}
}
When a reply with 4xx comes in, it first goes through
onreply_route[1]
and get the result printed to syslog. The message
is then passed to
failure_route[1]. But it seems that the status code and reason are
gone. I get a <null> for both values in the failure route.
How should I
>change the script to get that.
>
>Zeus Ng
>
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
>
> 
9:43 p.m.
Indeed, Andres is right, that's what should be done in this place.
The root reason is that 'status' is not intended for use in failure_route.
(I hope we never advertised it was.) We should obviously make it impossible
to avoid confusion. I think that enabling t_check_status from reply_route
and removing 'status' will do it.
Note there is a great difference between what status and t_check_status
do. 'status' refers to currenlty received reply in onreply_route.
failure_route is very different -- failure_route returns to processing
of the original request, with which several replies may be associated.
t_check_status thus first does a branch picking process, selects
a branch SER would use if you did nothing else, and that's what you
receive.
-jiri
At 09:16 PM 5/27/2004, Andres wrote:
You can try something like:
failure_route[1] {
if ( t_check_status("486") ) {
.
do whatever
.
}
}
Zeus Ng wrote:
--
Andres
Network Admin
http://www.telesip.net
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
failure_routes process the initial request, not the reply which caused the failure.
I'm not trying to process reply which caused the failure. Instead, I want to
process the failure on the initial request. The problem is, a reply, no
matter it's 1xx, 2xx, 3xx will always goes through reply route first. Then
goes to failure route.
E.g.
UA1 -> SER -> UA2
If UA2 reply "486 Busy" to SER, the reply will be processed by reply route
first (due to t_on_reply()) and then failure route (due to t_on_failure()).
What I expected is any reply code >= 400 should be processed by failure
route only.
Daniel
On 5/27/2004 3:35 PM, Zeus Ng wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
I have the following logic.
route {
...
t_on_reply("1");
t_on_failure("1");
t_relay();
}
onreply_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
}
failure_route[1] {
xlog("L_NOTICE", "Reply status %rs: Reason %rr\n");
if (status=="408") {
do something 1
} else if (status=="480") {
do something 2
} else if (status=="486") {
do something 3
}
}
When a reply with 4xx comes in, it first goes through
onreply_route[1]
and get the result printed to syslog. The message
is then passed to failure_route[1]. But it seems that the status code and reason are gone.
I get a <null> for both values in the failure route.
How should I
>change the script to get that.
>
>Zeus Ng
>
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
28 May
28 May
3:51 a.m.
The root reason is that 'status' is not
intended for use in
failure_route. (I hope we never advertised it was.) We should
No you didn't advertise it. It's only my common sense of assuming
'status'
is also available in failure_route got it wrong. I should never do that.
Indeed, there are a couple of functions in the TM module which have no
documentation. I understand you guys are busy and will try digging in the
code for answer. I wouldn't brother you unless I ran into situation like
this. However, would you mind describing what t_forward_noack_uri() and
t_write_req() does and some example scripts.
obviously make it impossible to avoid confusion. I
think that
enabling t_check_status from reply_route and removing
'status' will do it.
Before you go on removing 'status', can you confirm the question in the next
paragraph?
Note there is a great difference between what status and
t_check_status do. 'status' refers to currenlty received
reply in onreply_route. failure_route is very different --
failure_route returns to processing of the original request,
with which several replies may be associated. t_check_status
thus first does a branch picking process, selects
a branch SER would use if you did nothing else, and that's
what you receive.
Does that mean t_check_status is parallel forking safe in reply_route? I
wouldn't want a DND from a client in a group pickup affect the end result of
the call.
4:11 a.m.
At 03:51 AM 5/28/2004, Zeus Ng wrote:
No problem, I was just fearing we mistakenly documented it somewhere.
You can use t_check_status from both, failure_route and onreply_route.
In failure_route it picks the most likely reply candidate. In onreply_route
it refers to currently processed reply.
If you process reply codes from failure_route:
1) you get to failure_route after all branches finished without success
2) you will get status of the lowest-code reply
If a callee sends a DND and there are other incomplete branches,
failure_route will not be entered.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
The root
reason is that 'status' is not intended for use in
failure_route. (I hope we never advertised it was.) We should
No you didn't advertise it. It's only my common sense of assuming
'status'
is also available in failure_route got it wrong. I should never do that. Indeed, there are a couple of functions in the TM
module which have no
documentation. I understand you guys are busy and will try digging in the
code for answer. I wouldn't brother you unless I ran into situation like
this. However, would you mind describing what t_forward_noack_uri() and
t_write_req() does and some example scripts.
None of these functions is actually useful now. t_forward_noack_uri is
primarily for internal use by other fucntions and t_write_req is
a unix-socket-based IPC for talking to other applications, still a feature
under development.
obviously make
it impossible to avoid confusion. I think that
enabling t_check_status from reply_route and removing
'status' will do it.
Before you go on removing 'status', can you confirm the question in the next
paragraph?
Note there is a great difference between what status and
t_check_status do. 'status' refers to currenlty received
reply in onreply_route. failure_route is very different --
failure_route returns to processing of the original request,
with which several replies may be associated. t_check_status
thus first does a branch picking process, selects
a branch SER would use if you did nothing else, and that's
what you receive.
Does that mean t_check_status is parallel forking safe in reply_route? I
wouldn't want a DND from a client in a group pickup affect the end result of
the call.
7294
days inactive
7295
days old
6 comments
4 participants
participants (4)
-
Andres -
Daniel-Constantin Mierla -
Jiri Kuthan -
Zeus Ng