[SR-Users] Use of t_cancel_callid() to drop an early dialog
Daniel-Constantin Mierla
miconda at gmail.com
Sun Nov 24 16:35:51 CET 2013
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131124/c72bf687/attachment.html>
More information about the sr-users
mailing list