[Home]

Summary:ASTERISK-16006: [regression] X-Lite disconnects because of RTCP timeout when Local channel and MeetMe/F involved
Reporter:Dmitry Andrianov (dimas)Labels:
Date Opened:2010-04-23 11:09:05Date Closed:2010-10-12 10:05:57
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) issuelog-17236.txt
Description:The dialplan:

context test1 {
       start => {
               Answer;
               Read(code,conf-getpin);
               MeetMe(1234,F);
       }

       test => {
               Answer;
               Dial(Local/start@test1/);
       }
}

1. use X-Lite
2. place a call to test@test1 somehow
3. you are asked for a PIN.
4. enter anything and press #
5. You hear you are only person in the conference
6. 30 seconds later X-Lite hangs up the call because of RTCP inactivity

Note that X-Lite must have RTCP timeout enabled (this is default setting):
 Right click -> Options -> Advanced -> Network ->
   In times of network disruption automatically hang up the call after => ON
   RTCP had been inactive for => 30 seconds

****** ADDITIONAL INFORMATION ******

Note that every piece of dialplan is important.
The problem disappears if you do ANY of the following:
* remove F option from MeetMe
* remove Read application from dial plan
* remove Dial to the Local channel (by executing MeetMe directly)

still feels like a bug even though there are so many workarounds...
Comments:By: Dmitry Andrianov (dimas) 2010-04-23 11:18:17

Forgot to say - exactly the same dialplan works fine with 1.4.26.1 - X-Lite does not disconnect.
By: Paul Belanger (pabelanger) 2010-04-23 12:23:27

We will need debug log and SIP Trace (see below).

http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt

---
Thank you for taking the time to report this bug and helping to make Asterisk better.

Unfortunately, we cannot work on this bug because your description did not include enough information.

You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines.

We\'d be grateful if you would then provide a more complete description of the problem.

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf).

Thanks!
By: Dmitry Andrianov (dimas) 2010-05-06 05:46:15

To be honest, I do not see how SIP trace will help. However I'm providing it just to make sure the issue won't be closed "due to lack of feedback" :)

Note: we are using DUNDi so I filtered these from log file using (grep -vi dundi) - these are irrelevant to the call but produce a lot of text...
By: m0bius (m0bius) 2010-05-11 08:01:48

Hello,

I have seen this before as well and I don't think it has to do with Dialing the Local channel only. I believe that it has to do with Dial() in general.

We have experienced it with 1.6.1.16 and 1.6.2.6 but not with 1.6.1.1

From SIP traces we have seen so far there is no difference between an X-Lite call and a normal call. If you are to disable the X-Lite option "In times of network disruption, automatically hang up calls after..." everything works. (However X-Lite comes with the option pre-enabled with 30 seconds)
By: Francesco Romano (francesco_r) 2010-05-11 08:25:46

I have the same exact problem with Asterisk 1.4.31: x-lite clients dialing out through asterisk pri card or sip gsm gateway. And i don't use local channels. The same softphones registered to another asterisk 1.4.24 (same sip gateway but another pri card) and nearly the same configuration don't have this problem, so i think is a regression in asterisk.
By: Jamuel Starkey (jamuel) 2010-05-11 11:47:22

We see this with Eyebeam as well.  Running 1.6.1.12 and just a regular dial -- no Local involved.  As mentioned previously disabling the RTCP loss detection in the EB client works around the issue.

Let us know if you'd like any logs or captures.
By: Jamuel Starkey (jamuel) 2010-05-11 11:56:59

This issue does *NOT* appear to be present in 1.6.1.19-rc3.
By: Dmitry Andrianov (dimas) 2010-05-12 13:46:15

Yep, something is wrong with Asterisk-RTCP-XLite.
There was a thread on asterisk-dev about that long time ago - http://lists.digium.com/pipermail/asterisk-dev/2010-January/041643.html

I hope that although my scenario is not simple, it is 100% reproducible and will allow developers to see the problem themselves. I could not reproduce it with simple internal calls etc.
By: David Vossel (dvossel) 2010-05-18 13:25:58

I tried to reproduce this using X-Lite 2.0 for linux and was not successful (using the same dialplan supplied in the description). Asterisk sent RTCP updates correctly and the phone never hung up.  I was not however able to find the "In times of network disruption automatically hang up the call after" option in this version.  What version of X-Lite are you all using?  Can someone please provide us with a packet capture with SIP and RTP traffic on a call that fails.
By: David Vossel (dvossel) 2010-05-19 17:14:31

I was able to gain access to a windows box and test X-Lite 3.0.  The issue occurs just like it was reported when tested against 1.6.2.6.  After 30 seconds the call hangs up.  The good news is that I tested it against 1.6.2.7 and it appears to have been resolved.  Please update.  If you have any additional problems feel free to re-open this issue.
By: David Vossel (dvossel) 2010-09-13 14:57:18

I'm having problems with this again. I do not believe it was completely resolved. I'm looking back into this issue.
By: David Vossel (dvossel) 2010-10-12 10:05:56

I'm closing this. I can see we are sending the X-Lite client RTCP when it times out. For some reason the client is treating the change in the SSRC id as a stoppage of RTCP entirely. Newer and older versions of the X-lite client do not have this problem, and there is a work around for issue by disabling the RTCP timeout option in the advanced menus of the X-Lite client.