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
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
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
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
-
Andreas Granig -
Bogdan-Andrei Iancu