[Serusers] Cannot capture call status in failure route
Jiri Kuthan
jiri at iptel.org
Fri May 28 04:11:21 CEST 2004
At 03:51 AM 5/28/2004, Zeus Ng wrote:
>> 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.
No problem, I was just fearing we mistakenly documented it somewhere.
>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.
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/
More information about the sr-users
mailing list