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

Guillaume Bour libon.voiceteam at gmail.com
Thu Nov 21 17:19:18 CET 2013


Hi Daniel

No, replies are not dropped.

I looked into source code, particularly tmx_mod.c::t_cancel_callid() 
function.
It alter the global pointer T (pointing to the transaction currently 
processed), but do not restore original value at the end:
   - at the beginning of t_cancel_callid(), T is NULL
   - then t_lookup_callid() make it point to the transaction we want to 
cancel
   - and the pointer is not cleanup before exiting t_cancel_callid

Here is a patch that fix this issue (it may not be the correct way to do it)


Regards,
Guillaume

On 20/11/2013 22:57, Daniel-Constantin Mierla wrote:
> Hello,
>
> are you dropping replies? I don't see the 'SIP/2.0 487 Request 
> Terminated' being sent to caller, it looks ok and has two Via headers.
>
> Cheers,
> Daniel
>
> On 11/20/13 4:06 PM, Guillaume Bour wrote:
>> 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::
>>
>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> -- 
> 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 athttp://www.asipto.com  -
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131121/0a35aeca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t_cancel_callid.patch
Type: text/x-patch
Size: 2361 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131121/0a35aeca/attachment-0001.bin>


More information about the sr-users mailing list