Hello. Thanks Daniel for your answer. Finally we discover the problem why the calls were stalled in state::1, we do several checks before an INVITE is t_relayed(), this seems to be too much for certain clients and then they send a INVITE with the same call-id, this was generating “state::1” dialogs. We solve this issue by sending a “100 – Trying” right after the INVITE arrives to the proxy, in this way the caller don’t send a new INVITE… it worked like a charm. Now we’re trying to see how we can handle certain situations where “state::3” dialogs are kept in memory. This happened with this type of calls : Caller Proxy Callee INVITE -----------> --------INVITE ---> <-- 100 Trying ---- <---- Ringing ------ <---- Ringing ------ <---- OK ---------- <---- OK --------- <---- OK ---------- <---- OK --------- <---- OK ---------- <---- OK --------- <---- OK ---------- <---- OK --------- <---- OK ---------- <---- OK --------- And then the call is out into state::3. Is there a way to detect this behavior and clear the dialog before it turns to state 3???? Hope someone can help me. Regards, Ricardo.- *De:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Enviado el:* viernes, 11 de mayo de 2012 3:35 *Para:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List *CC:* Ricardo Martinez *Asunto:* Re: [SR-Users] Question about dialog module (state 1) Hello, what version are you using? Can it be that you initiate the dialog in config (e.g., via dlg_manage()) and then you reply stateless? Cheers, Daniel On 5/9/12 9:53 PM, Ricardo Martinez wrote: Hello. I’m using the dialog module to keep control of simultaneous calls. In some cases, and I’m still trying to find why this happens, the dialog stays in “STATE:: 1”, which according to the docs is a dialog which no provisional response has been sent yet. Is there a way to eliminate this kind of dialogs??? When I list the dialogs I can see : dialog:: hash=2523:2040584107 state:: 1 ref_count:: 1 timestart:: 0 timeout:: 0 callid:: 25b8e5354ca0850a4d0bd9c43eeb617a(a)pxext.redvoiss.net from_uri:: sip:557100052213@pxext.redvoiss.net from_tag:: as10dc7c85 caller_contact:: sip:557100052213@200.68.19.44:5060 caller_cseq:: 103 caller_route_set:: caller_bind_addr:: udp:64.76.154.110:5060 callee_bind_addr:: to_uri:: sip:0981985480@pxext.redvoiss.net to_tag:: callee_contact:: callee_cseq:: callee_route_set:: when I try to eliminate this dialog : kamctl fifo dlg_terminate_dlg 25b8e5354ca0850a4d0bd9c43eeb617a(a)pxext.redvoiss.net 500 command 'dlg_terminate_dlg' failed Thanks in advance, Regards, Ricardo Martinez.- _______________________________________________ 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

Hello Daniel. Yes.. finally all resumes to a missing ACK. The problem is that I can force the client to repair this…. Is possible to detect this kind of dialogs in the script?. I know that I can delete these kind of dialogs via MI commands, but’s not the idea……. Hope someone can help me here. Thanks in advance, Regards, Ricardo.- *De:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Enviado el:* martes, 15 de mayo de 2012 3:53 *Para:* Ricardo Martinez *CC:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List *Asunto:* Re: [SR-Users] Question about dialog module (state 1) Hello, so what's the situation now, a missing ACK? I think such dialogs can be terminated via mi command. Cheers, Daniel On 5/15/12 12:25 AM, Ricardo Martinez wrote: Hello. Thanks Daniel for your answer. Finally we discover the problem why the calls were stalled in state::1, we do several checks before an INVITE is t_relayed(), this seems to be too much for certain clients and then they send a INVITE with the same call-id, this was generating “state::1” dialogs. We solve this issue by sending a “100 – Trying” right after the INVITE arrives to the proxy, in this way the caller don’t send a new INVITE… it worked like a charm. Now we’re trying to see how we can handle certain situations where “state::3” dialogs are kept in memory. This happened with this type of calls : Caller Proxy Callee INVITE -----------> --------INVITE ---> <-- 100 Trying ---- <---- Ringing ------ <---- Ringing ------ <---- OK ---------- <---- OK --------- <---- OK ---------- <---- OK --------- <---- OK ---------- <---- OK --------- <---- OK ---------- <---- OK --------- <---- OK ---------- <---- OK --------- And then the call is out into state::3. Is there a way to detect this behavior and clear the dialog before it turns to state 3???? Hope someone can help me. Regards, Ricardo.- *De:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Enviado el:* viernes, 11 de mayo de 2012 3:35 *Para:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List *CC:* Ricardo Martinez *Asunto:* Re: [SR-Users] Question about dialog module (state 1) Hello, what version are you using? Can it be that you initiate the dialog in config (e.g., via dlg_manage()) and then you reply stateless? Cheers, Daniel On 5/9/12 9:53 PM, Ricardo Martinez wrote: Hello. I’m using the dialog module to keep control of simultaneous calls. In some cases, and I’m still trying to find why this happens, the dialog stays in “STATE:: 1”, which according to the docs is a dialog which no provisional response has been sent yet. Is there a way to eliminate this kind of dialogs??? When I list the dialogs I can see : dialog:: hash=2523:2040584107 state:: 1 ref_count:: 1 timestart:: 0 timeout:: 0 callid:: 25b8e5354ca0850a4d0bd9c43eeb617a(a)pxext.redvoiss.net from_uri:: sip:557100052213@pxext.redvoiss.net from_tag:: as10dc7c85 caller_contact:: sip:557100052213@200.68.19.44:5060 caller_cseq:: 103 caller_route_set:: caller_bind_addr:: udp:64.76.154.110:5060 callee_bind_addr:: to_uri:: sip:0981985480@pxext.redvoiss.net to_tag:: callee_contact:: callee_cseq:: callee_route_set:: when I try to eliminate this dialog : kamctl fifo dlg_terminate_dlg 25b8e5354ca0850a4d0bd9c43eeb617a(a)pxext.redvoiss.net 500 command 'dlg_terminate_dlg' failed Thanks in advance, Regards, Ricardo Martinez.- _______________________________________________ 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 -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda