Hello

Regarding the stuck dialog in state 5 , we had wait_ack = 1 ; we've put wait_ack = 0 , and the cancelled dialog does not show in
the output of `kamctl mi dlg_list` anymore.

Regards,
Dragos


On Tuesday, November 26, 2013 9:32 AM, Guillaume Bour <libon.voiceteam@gmail.com> wrote:
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@staging.voip
        from_tag:: V7wg6INO0Sp3o0Od1AIzPyUXbUuRLOFy
        caller_contact:: sip:62389754-sbcqi87bli6bc@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@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@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@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 at http://www.asipto.com -



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@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@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@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@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@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users