11 Jul
2006
11 Jul
'06
1:32 p.m.
Hi,
The docs state that if drop() is called in onreply_route[], any
provisional replies are discarded. How about final replies?
What I want to achieve is to rewrite some reply codes, like:
onreply_route[x] {
if(status=="302") {
t_reply("480", "Something");
drop();
}
}
Would this work as intended?
Thanks,
Andy
11 Jul
11 Jul
1:59 p.m.
Hi Andreas,
for re-writing the negative final replies, use the failure route:
failure_route[x] {
if (t_check_status("302")) {
t_reply("480", "Something");
exit;
}
}
regards,
bogdan
Andreas Granig wrote:
Hi,
The docs state that if drop() is called in onreply_route[], any
provisional replies are discarded. How about final replies?
What I want to achieve is to rewrite some reply codes, like:
onreply_route[x] {
if(status=="302") {
t_reply("480", "Something");
drop();
}
}
Would this work as intended?
Thanks,
Andy
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
3:30 p.m.
Bogdan-Andrei Iancu wrote:
for re-writing the negative final replies, use the
failure route:
Oh, yes, of course. But, however, it seems to be a little bit more
complicated.
There are clients with adjustable ring-timeouts, which signal 302 and a
Contact to refer to on such a timeout event. I intercept such replies
and perform a server-side call-forward.
Now if the UAC the call is forwarded to is busy and replies with 486, I
can intercept this reply, but if I call break (for example because there
is no conditional call-forward for this busy UAC), the first 302 is
handed back to the original caller, and I don't see a way how to catch
this reply again and rewrite it.
Any ideas?
Thanks,
Andy
14 Jul
14 Jul
2:33 p.m.
Hi Andreas,
not sure about this. If you do serial forking, the reply selected to be
sent back to the UAC is only from the last serial step.
So if you have a first serial step ended with 302 and a second one ended
with 486, the 486 (if no other code is forced from script) will be sent
to the UAC.
hopefully I got your scenario correctly - if it doesn't work like this,
please let me know.
regards,
bogdan
Andreas Granig wrote:
Bogdan-Andrei Iancu wrote:
for re-writing the negative final replies, use
the failure route:
Oh, yes, of course. But, however, it seems to be a little bit more
complicated.
There are clients with adjustable ring-timeouts, which signal 302 and
a Contact to refer to on such a timeout event. I intercept such
replies and perform a server-side call-forward.
Now if the UAC the call is forwarded to is busy and replies with 486,
I can intercept this reply, but if I call break (for example because
there is no conditional call-forward for this busy UAC), the first 302
is handed back to the original caller, and I don't see a way how to
catch this reply again and rewrite it.
Any ideas?
Thanks,
Andy
2:43 p.m.
Bogdan-Andrei Iancu wrote:
not sure about this. If you do serial forking, the
reply selected to be
sent back to the UAC is only from the last serial step.
So if you have a first serial step ended with 302 and a second one ended
with 486, the 486 (if no other code is forced from script) will be sent
to the UAC.
It seems like it happens only in some special circumstances that the 302
is passed back. I'll have to dig a little bit deeper into that...
Thanks,
Andy
6706
days inactive
6709
days old
4 comments
2 participants
participants (2)
-
Andreas Granig -
Bogdan-Andrei Iancu