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

[Guillaume Bour]

On 20/11/2013 12:01, Daniel-Constantin Mierla wrote:
> Hello,
>
> 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.
>
> Cheers,
> Daniel
>


Hi Daniel,

local-request is triggered by a BYE
I have attached sample log and trace

There is some kind of dialogs mixing. Here is the 1st call dialog as 
reported by "kamctl mi dlg_list" _before and after_ the 2d call is answered:

# kamctl mi dlg_list
dialog::  hash=2790:3231
         state:: 2
         ref_count:: 1
         timestart:: 0
         timeout:: 0
         callid:: GoXhk8GfkIEEqFyFNcySEjSOOpVKg4Uq
         from_uri:: sip:15909901 at staging.voip
         from_tag:: swYh88AkicGbSHpK.D1z7uo3EX9Q-.AZ
         caller_contact:: 
sip:37984520-gch2kindtioq8 at 10.0.1.10:5060;transport=udp
         caller_cseq:: 24899
         caller_route_set::
         caller_bind_addr:: udp:10.0.1.10:5060
         callee_bind_addr::
         to_uri:: sip:+3360000011 at staging.voip
         to_tag::
         callee_contact::
         callee_cseq::
         callee_route_set::

# kamctl mi dlg_list
dialog::  hash=2790:3231
         state:: 3
         ref_count:: 2
         timestart:: 1384952191
         timeout:: 20242152
         callid:: GoXhk8GfkIEEqFyFNcySEjSOOpVKg4Uq
         from_uri:: sip:15909901 at staging.voip
         from_tag:: swYh88AkicGbSHpK.D1z7uo3EX9Q-.AZ
         caller_contact:: 
sip:37984520-gch2kindtioq8 at 10.0.1.20:5060;transport=udp
         caller_cseq:: 24899
         caller_route_set::
         caller_bind_addr:: udp:10.0.1.10:5060
         callee_bind_addr:: udp:10.0.1.10:5060
         to_uri:: sip:+3360000011 at staging.voip
         to_tag:: as6c8b935a
         callee_contact:: sip:+3360000022 at 10.0.1.11:5060
         callee_cseq::
         callee_route_set::



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131120/aa8dc6cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kamailio.log.bz2
Type: application/x-bzip
Size: 20798 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131120/aa8dc6cf/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cancel.ngrep.bz2
Type: application/x-bzip
Size: 2981 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131120/aa8dc6cf/attachment-0003.bin>