On 20.11.2009 16:57 Uhr, Michal Matyska wrote:
Daniel-Constantin Mierla píše v Pá 20. 11. 2009 v 16:53 +0100:
On 20.11.2009 16:38 Uhr, Daniel-Constantin Mierla wrote:
On 20.11.2009 9:53 Uhr, Miklos Tirpak wrote:
On 11/20/2009 12:58 AM, Andres Moya wrote:
Dear all!
Please help. I have problem dealing with recursive call in failure route.
this route happen first time for authentication to external SIP provider (react on code 401), then it have response 480 i want to direct traffic to another operator via cr_route.
First i relay INVITE and getting 401, then sending authentication, but provider gives 480. I can see it in a dump of SIP session. But my failure_route still thinking that reply code is 401 on second reply. Maybe because i dont understand well how branches concept work here? Or using kamailio 3.0? ;) Looks like it give me status code of first reply and ignoring actual code in reply. :( I don't know if it something with development version or my own misunderstanding. sorry
This is correct, the proxy must choose one of the two responses to forward and 401 has higher precedence than 480 (RFC3261, 16.7: "Choosing the best response"). The failure route always works on the selected response as opposed to the last response received.
I think this is wrong imo, if I got it right from your email, because the failure route should work on a selected reply from the last set of branches in serial forking.
Do you say that if I get 301 with couple of contacts, then in failure route I create new branches, relay, all failed because of timeout and/or busy, I get back in failure route with the 301?
I cannot drop all replies because maybe the reply I want to be sent back to caller is from a previous branch. Think at:
A calls B B phone gives busy B has redirect to C in such case C phone gives timeout C has now redirect to voice mail Voice mail returns server failure
If I need to drop the replies then I will send the 500 reply which is wrong.
... actually, while it might be questionable whether to select the reply to be sent back to caller from last serial forking set of branches or from entire set of branches, triggering failure route should be with a reply from last set of branches, otherwise you cannot take the right decision for new branches.
If I understand correctly, then whenever you start above mentioned "new set of branches" just call t_drop_replies() and you are done.
i said "questionable about selection of reply to send back but not about what code is presented to failure route". So yes, if I want only from last set of branches, it is ok what you say. But if not, then you are screwed up with serial forking logic.
the t_drop_replies() drops all branches, even there were two or more serial forking steps, not the replies from the last set of branches -- I checked the code. It just not look coherent.
Cheers, Daniel