[SR-Users] Use of t_cancel_callid() to drop an early dialog

Daniel-Constantin Mierla miconda at gmail.com
Wed Nov 20 12:01:33 CET 2013


On 11/20/13 11:50 AM, Guillaume Bour wrote:
> Hi All
> We wan't to prevent our users to make more than one call at time, so 
> we choose to disconnect the previous call.
> When the previous call is established, we use dlg_bye(), and its ok.
> But when it is in early state, we use t_cancel_callid() to cancel its 
> INVITE transaction.
> We face 2 issues:
>     1) we use local-request event route to account calls on timeout. 
> Sometimes this route is called for the cancelled call (after default 
> timeout of 1 hour)

what is in the local-request in this case? Is it a BYE?

> 2) t_cancel_callid() cancel previous call, but also _make current 
> dialog disappear_: call is still ongoing and we can answer and talk to 
> each other, but the dialog does not appear in 'kamctl stats dialog' 
> and 'kamctl mi dlg_list' commands
> Is there a known limitation, or do we misuse t_cancel_callid() ?
Can you send the log with debug=3 in kamailio.cfg? It will help to see 
what happens. Otherwise, if the call id is different for current dialog, 
it should not happen. The ngrep output in this situation (for both first 
and second invite) will help.


Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at http://www.asipto.com -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131120/156407a9/attachment.html>

More information about the sr-users mailing list