On 24/07/14 09:43, Olle E. Johansson wrote:
On 24 Jul 2014, at 09:38, Klaus Darilion klaus.mailinglists@pernau.at wrote:
On 21.07.2014 14:59, Daniel-Constantin Mierla wrote:
Hello,
you may get similar results using t_cancel_callid(():
For each call you have to store the call-id, cseq and the target user somehow (e.g., using htable).
Then, when you have a registration, see if the user has an ongoing call towards him/her. If yes, cancel that transaction and you end up in failure route. Based the flags, you can see it was canceled on purpose and can do another lookup location to get now two branches.
You would need to store the initial caller address before looking up location, revert to it in failure route before looking up location again.
The behavior is not exactly the same as you requested, as first branch is canceled. But given that the branch will be called again in short time, the user might not notice anything in terms of ringing interruption.
The problem may be that there is a missed called on device 1. Maybe this can be avoided by adding the reason header with "cause=200" if the client supports it.
That is a good idea - but how do you add that to a CANCEL generated by Kamailio using this function?
There is support for reason header in CANCEL generated by TM -- not sure it is done for this case but should not be a big patch, as the same internal function is executed to send this cancel (a parameter should be set for the reason header, iirc).
Cheers, Daniel