[asterisk-bugs] [JIRA] (ASTERISK-24747) Call is not terminated in time due to lack of RTP nor it is shutdown if peer sends BYE

[Fabian Borot (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=224723#comment-224723 ] 

Fabian Borot commented on ASTERISK-24747:
-----------------------------------------

that is the problem, the replication. We can not replicate it at least so far but we were hoping to get some insight as to what to look for in order to alleviate the effect if this happens again. We have these ideas in mind:
1- reduce the rtptimeout to 3 seconds instead of 30 seconds
2- find in the code the part that re-schedule it to 10000 ms, and reduce that time to 2000 ms maybe
3- as you can see even though it said rescheduling the autodestruction in 10000 ms it was not happening every 10000 ms either, check that logic.
4- I see in the code that an AMI EVENT gets fired in the function  "static int check_rtp_timeout" :

                                ast_log(LOG_NOTICE, "Disconnecting call '%s' for lack of RTP activity in %ld seconds\n",
                                        ast_channel_name(dialog->owner), (long) (t - dialog->lastrtprx));
                                manager_event(EVENT_FLAG_CALL, "SessionTimeout", "Source: RTPTimeout\r\n"
                                                "Channel: %s\r\nUniqueid: %s\r\n", ast_channel_name(dialog->owner), ast_channel_uniqueid(dialog->owner));

If that is the case we could maybe disconnect the channel upon receiving the AMI event, we hope that that hangup will happen if commanded from AMI,

Let me know what you think pls

> Call is not terminated in time due to lack of RTP nor it is shutdown if peer sends BYE
> --------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24747
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24747
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 11.2.1
>         Environment: Linux 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:21:01 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
> CentOS release 5.7 (Final)
>            Reporter: Fabian Borot
>            Assignee: Fabian Borot
>         Attachments: asterisk log.txt
>
>
> We use RTP time out as a protection to shutdown the calls when there is lack of RTP for 30 secs. We have been noticing lately this behavior, either the calling or called peer terminates the call and asterisk takes a long time, (variable, around 30-40 secs later) to forward the BYE to the other leg.
> At the same time, asterisk shows in the logs for those calls that the call will be terminated due to Lack of RTP activity in 30 secs, we see the message "Rescheduling destruction for 10000 ms" for the channel, several times, not even spaced out every 10000 ms but 40 secs, 50 secs etc until eventually (sometimes after 4 mins) the call is terminated, causing to log the duration of the call with wrong values. Our customer are complaining  about it. We restarted the asterisk and so far it hasn't happened again but it looks like this behavior lasted several weeks and we don't know yet the repercussion of this issue because it may take a couple of billing cycles for the customers to create the disputes.
> The weird thing is that the BYE sent by the peers is acknowledged with the 200 OK but the calls are not terminated, they are terminated after several cycles of that "Rescheduling destruction" msgs.
> Looks like while the asterisk is in the process of terminating the call due t lack of rtp that the BYE msg is not taking into account to terminate the call. Is this possible ?
> thank you
> Any ideas?
>  Has anybody experienced an issue like this before?



--
This message was sent by Atlassian JIRA
(v6.2#6252)