[SR-Users] Use of t_cancel_callid() to drop an early dialog
Guillaume Bour
libon.voiceteam at gmail.com
Tue Nov 26 09:32:01 CET 2013
On 25/11/2013 21:35, Daniel-Constantin Mierla wrote:
> Hello Guillaume,
>
> thanks, I will backport. Is this solving the issue reported in this
> email thread, or the one related to the drop of another early dialog
> is still there?
Hi,
Yes, the correct early dialog is cancelled, and the local-request event
route is not executed anymore for this dialog.
But it remains indefinitly listed in output of command "kamctl mi
dlg_list", so I suppose the dialog is not really destroyed
$> /opt/kamailio/sbin/kamctl mi dlg_list
dialog:: hash=1149:11437
state:: 5
ref_count:: 1
timestart:: 0
timeout:: 0
callid:: q69aDDCPso8rh-0NqPxv39VCt8XPgwrN
from_uri:: sip:15909901 at staging.voip
from_tag:: V7wg6INO0Sp3o0Od1AIzPyUXbUuRLOFy
caller_contact::
sip:62389754-sbcqi87bli6bc at 10.0.1.106:5060;transport=udp
caller_cseq:: 16068
caller_route_set::
caller_bind_addr:: udp:10.0.1.10:5060
callee_bind_addr::
to_uri:: sip:+33600000011 at staging.voip
to_tag::
callee_contact::
callee_cseq::
callee_route_set::
Regards,
Guillaume
>
> Cheers,
> Daniel
>
> On 11/25/13 4:47 PM, Guillaume Bour wrote:
>> On 24/11/2013 16:35, Daniel-Constantin Mierla wrote:
>>> Hello Guillaume,
>>>
>>> I pushed two commits on master branch:
>>>
>>> -
>>> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=777dd5e28ff6b4fcc3b1c44e841eb415c974075f
>>> -
>>> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=60372d613544af1f8f06122eb77fa2a9636a6c3a
>>>
>>> The changes restore the previous values for T and T_branch, should
>>> be safer for the case when t_cancel_callid() is used in the context
>>> of another transaction.
>>>
>>> The patches are for master branch, but should apply easily to 4.0
>>> branch. If you confirm they are working fine, then I will backport
>>> to git branch 4.0 as well.
>>>
>>
>> Hi Daniel,
>>
>> I have tested it on 4.0 branch, and its working fine
>>
>> Regards,
>> Guillaume
>>
>>> Cheers,
>>> Daniel
>>>
>>> On 11/21/13 5:19 PM, Guillaume Bour wrote:
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20131126/ed50bcf7/attachment-0001.html>
More information about the sr-users
mailing list