Just for the sake of completeness, you can get the dialog duration
(equivalent of $DLG_lifetime) using the following construction:
event_route[cnxcc:call-shutdown]
{
$var(duration) = $TS - $dlg(start_ts);
xlog("L_INFO", "Call killed after [$var(duration)] sec(s)");
unforce_rtp_proxy();
}
On Fri, Jun 21, 2013 at 8:45 AM, Federico Cabiddu <
federico.cabi...@gmail.com> wrote:
> Thanks!
> I'll have a look on this too.
>
> Regards,
>
> Federico
>
>
> On Fri, Jun 21, 2013 at 2:43 PM, Carlos Ruiz Díaz <
> carlos.ruizd...@gmail.com> wrote:
>
>> Maybe cnxcc module can help you [1].
>>
>> If you need to set a time limit you could use cnxcc_set_max_time() and
>> when the call times out, an event route is called.
>>
>> [1] http://kamailio.org/docs/modules/devel/modules/cnxcc.html
>>
>> Regards,
>> Carlos
>>
>>
>> On Fri, Jun 21, 2013 at 8:30 AM, Federico Cabiddu <
>> federico.cabi...@gmail.com> wrote:
>>
>>> Hi Daniel,
>>> thank you for your answer.
>>> I tried to catch the BYE with event_route[dialog:end] but I'm facing
>>> another problem.
>>> When the timeout for the dialog is reached Kamailio correctly sends a
>>> BYE to the caller and to the callee but in the logs I see this:
>>>
>>> DEBUG: dialog [dlg_timer.c:240]: start with tl=0x7f10937f0138
>>> tl->prev=0x7f10937b4f20 tl->next=0x7f10937b4f20 (42641998) at 42641998 and
>>> end with end=0x7f10937b4f20
>>> end->prev=0x7f10937f0138 end->next=0x7f10937f0138
>>> DEBUG: dialog [dlg_timer.c:243]: getting tl=0x7f10937f0138
>>> tl->prev=0x7f10937b4f20 tl->next=0x7f10937b4f20 with 42641998
>>> DEBUG: dialog [dlg_timer.c:249]: end with tl=0x7f10937b4f20
>>> tl->prev=0x7f10937f0138 tl->next=0x7f10937f0138 and
>>> d_timer->first.next->prev=(nil)
>>> DEBUG: dialog [dlg_timer.c:282]: tl=0x7f10937f0138 next=(nil)
>>> DEBUG: dialog [dlg_req_within.c:302]: sending BYE to caller
>>> DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=<sip:x...@yyy.yyy.yyy.yyy
>>> :zzzz;transport=udp>
>>> DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343
>>> DEBUG: dialog [dlg_req_within.c:323]: BYE sent to caller
>>> DEBUG: dialog [dlg_req_within.c:302]: sending BYE to callee
>>> DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=<sip:x...@yyy.yyy.yyy.yyy
>>> :zzzz;transport=udp>
>>> DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343
>>> DEBUG: dialog [dlg_req_within.c:323]: BYE sent to callee
>>> DEBUG: dialog [dlg_hash.c:735]: ref dlg 0x7f10937f00e0 with 1 -> 3
>>> DEBUG: dialog [dlg_handlers.c:1474]: executing event_route 1 on state 5
>>> DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 -> 4
>>> DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289
>>> DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 -> 3
>>> DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 -> 4
>>> DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289
>>> DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 -> 3
>>> DEBUG: <core> [parser/parse_to.c:799]: end of header reached, state=10
>>> DEBUG: <core> [parser/msg_parser.c:190]: DEBUG: get_hdr_field: <To>
>>> [20]; uri=[y...@kamailio.org]
>>> DEBUG: <core> [parser/msg_parser.c:192]: DEBUG: to body [<
>>> y...@kamailio.org>#015#012]
>>> DEBUG: <core> [parser/parse_to.c:176]: DEBUG: add_param: tag=123
>>> DEBUG: <core> [parser/parse_to.c:799]: end of header reached, state=29
>>> DEBUG: <core> [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0
>>> parsed: <you@> (4) / <y...@kamailio.org> (16)
>>> ERROR: <core> [parser/parse_from.c:113]: failed to parse From uri
>>> ERROR: pv [pv_core.c:400]: cannot parse From URI
>>> DEBUG: <core> [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0
>>> parsed: <you@> (4) / <y...@kamailio.org> (16)
>>> ERROR: <core> [parser/parse_to.c:879]: failed to parse To uri
>>> ERROR: pv [pv_core.c:394]: cannot parse To URI
>>> INFO: <script>: event_route[dialog:end]: call-id=123 from=<null>
>>> to=<null> : (method= OPTIONS) :: dlg flag: 18446744073709551615 ::
>>> DLG_lifetime: <null>
>>>
>>> The parser error problem seems to be related to the To and From headers
>>> of FAKED_SIP_MSG, defined in lib/kcore/faked_msg.c.
>>> If I change those URIs adding "sip: " the pv error disappears but once
>>> entered the event_route[dialog:end]
>>>
>>> INFO: <script>: event_route[dialog:end]: call-id=123 from=you to=you :
>>> (method= OPTIONS) :: dlg flag: 18446744073709551615 :: DLG_lifetime:
>>> <null>
>>> WARNING: dialog [dlg_req_within.c:177]: inconsitent dlg timer data on
>>> dlg 0x7fa07e0c6fe0 [2950:12062] with clid '1518225741' and tags '717826890'
>>> '1348505040'
>>>
>>> As you can see, the $DLG_lifetime is <null> and we also have the
>>> message on the inconsistent dlg timer.
>>>
>>> Probably there is something that I'm not understanding but why the
>>> event_route in this case is processing a "fake" OPTIONS message?
>>> Another thing I noticed is that event_route[dialog:end] is not executed
>>> when a dialog is terminated by dlg_end_dlg or dlg_terminate_dlg fifo
>>> commands.
>>> We really need to access the DLG_lifetime value in both cases (internal
>>> timeout or external command), any hint on how to do it?
>>>
>>> Thank you in advance.
>>>
>>> Regards,
>>>
>>> Federico
>>>
>>>
>>>
>>>
>>> On Fri, Jun 21, 2013 at 12:43 AM, Daniel-Constantin Mierla <
>>> mico...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> there is an event route for dialog timeout, I guess there is available.
>>>> tm:local is executed by tm, so you may need to call the function that
>>>> lookups the dialog.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 6/20/13 1:47 PM, Dragos Oancea wrote:
>>>>
>>>> Hello ,
>>>>
>>>>
>>>> Is the $DLG_lifetime supposed to be accessed in
>>>> theevent_route[tm:local-request] ?
>>>>
>>>> We are trying to access it and it always reports null with kamailio
>>>> 4.0.0 .
>>>>
>>>> We found a reference about this here:
>>>> http://www.kamailio.org/pub/kamailio/3.3.3/ChangeLog
>>>>
>>>> .....
>>>>
>>>> dialog(k): run event route after setting cfg dlg vars
>>>>
>>>> - in this way they (e.g., $DLG_lifetime) should be accessible in event
>>>> route
>>>> (cherry picked from commit 2cdded28d9968a0b78f5ec8329ae6983d9ea77a9)
>>>>
>>>> .....
>>>>
>>>> Apparently it should have been possible.
>>>> Any hints on this ?
>>>>
>>>> Thank you!
>>>>
>>>> Regards,
>>>> Dragos & Federico
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierla -
>>>> http://www.asipto.comhttp://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
>>>
>>>
>>
>>
>> --
>> Carlos
>> http://caruizdiaz.com
>> +595981146623
>>
>> _______________________________________________
>> 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
>
>
--
Carlos
http://caruizdiaz.com
+595981146623
_______________________________________________
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
