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@staging.voip
from_tag:: swYh88AkicGbSHpK.D1z7uo3EX9Q-.AZ
caller_contact::
sip:37984520-gch2kindtioq8@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@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@staging.voip
from_tag:: swYh88AkicGbSHpK.D1z7uo3EX9Q-.AZ
caller_contact::
sip:37984520-gch2kindtioq8@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@staging.voip
to_tag:: as6c8b935a
callee_contact:: sip:+3360000022@10.0.1.11:5060
callee_cseq::
callee_route_set::
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)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(a)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(a)lists.sip-router.org