Hi,
Lately there were some discussions about t_check_status in failure_route when cancelling, where Jan (IIRC) made clear that only the lowest reply-code can be matched with t_check_status.
Now I have a related problem when routing to PSTN:
I use lcr-module in failure-route for routing to the next GW when 408/500/503 is received. I have noticed that I sometimes get 408 signalled from the GW (a PSTN code is mapped to it). So on one GW I mapped 408 to 480 for testing purposes to skip the fallback, the others still return 408.
Now if one of the not-remapped GWs returns 408, there's the fallback to another GW. If it's the remapped one, it returns 480, but t_check_status still matches 408.
I know that this special issue will be solved when I configure all my GWs to map the 408 to 480, but the question arises if this situation could come up again in other circumstances? Because if the first GW fails with 408 triggered by fr_timer, other return codes >408 from subsequent GWs can't be detected and passed back to the calling UAC without another PSTN fallback?
There was a discussion about introducing a method which checks if the call is cancelled to detect 487 (don't know anymore if on the openser-lists or here), but what about other codes?
Comments?
Andy
Andreas Granig wrote:
There was a discussion about introducing a method which checks if the call is cancelled to detect 487 (don't know anymore if on the openser-lists or here), but what about other codes?
Or to rephrase it: does it really make sense to choose the lowest code for serial forking? I understand it does when forking in parallel, and that it's the same implementation for both in SER, but wouldn't it make live easier when differing between both scenarios and just overwrite the last code when doing serial forking?
Andy
I have some private code to treat 487 as the lowest number. There were some discussions about this in ser list before. Since there is no standard, ser implementation just picked the the lowest code.
I am not sure which way is better, pick 487 as lowest, or use t_check_status. Any suggestion?
If someone wanst, I can provide the patch to the list.
Richard
On 9/9/05, Andreas Granig andreas.granig@inode.info wrote:
Andreas Granig wrote:
There was a discussion about introducing a method which checks if the call is cancelled to detect 487 (don't know anymore if on the openser-lists or here), but what about other codes?
Or to rephrase it: does it really make sense to choose the lowest code for serial forking? I understand it does when forking in parallel, and that it's the same implementation for both in SER, but wouldn't it make live easier when differing between both scenarios and just overwrite the last code when doing serial forking?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Richard Z writes:
I have some private code to treat 487 as the lowest number. There were some discussions about this in ser list before. Since there is no standard, ser implementation just picked the the lowest code.
standard says:
It MUST choose from the 6xx class responses if any exist in the context. If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context. The proxy MAY select any response within that chosen class. The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen.
so if response will be from class 4xx, proxy can pick any one of them.
I am not sure which way is better, pick 487 as lowest, or use t_check_status. Any suggestion?
i prefer to be in control myself rather than trusting the proxy to do a clever thing. that means tests in ser.cfg.
-- juha
Richard Z wrote:
I have some private code to treat 487 as the lowest number. There were some discussions about this in ser list before. Since there is no standard, ser implementation just picked the the lowest code.
RFC 3261 tells to use the lowest code, except 6xx which always wins immediately.
regards klaus
I am not sure which way is better, pick 487 as lowest, or use t_check_status. Any suggestion?
If someone wanst, I can provide the patch to the list.
Richard
On 9/9/05, *Andreas Granig* <andreas.granig@inode.info mailto:andreas.granig@inode.info> wrote:
Andreas Granig wrote: > There was a discussion about introducing a method which checks if the > call is cancelled to detect 487 (don't know anymore if on the > openser-lists or here), but what about other codes? Or to rephrase it: does it really make sense to choose the lowest code for serial forking? I understand it does when forking in parallel, and that it's the same implementation for both in SER, but wouldn't it make live easier when differing between both scenarios and just overwrite the last code when doing serial forking? Andy _______________________________________________ Serusers mailing list serusers@lists.iptel.org <mailto:serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Klaus Darilion wrote:
RFC 3261 tells to use the lowest code, except 6xx which always wins immediately.
No, it tells to use the lowest *response class* (if no 6xx exists), and from there one may select *any response* within that chosen class (with preference to responses which provide information affecting resubmission of the request).
Andy
-
Andreas Granig -
Juha Heinanen -
Klaus Darilion -
Richard Z