| Summary: | ASTERISK-01385: SIP channels remain open with Elesign ESC1710 and ethernet loss | ||
| Reporter: | muelas (muelas) | Labels: | |
| Date Opened: | 2004-04-09 12:56:15 | Date Closed: | 2011-06-07 14:10:45 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) siplog-10-April-2004.txt | |
| Description: | Hi, I have an elesign ESC1710 (ethernet terminal adapter for analogue phone) with the SIP firmware. Firstly, I should say that the firmware on this thing is terrible with countless bugs, and this problem is with the device. Asterisk just doesn't handle the problem very well (and may occur with other devices/calls) The problem is when I make a call with the esc1710 (which is usually passed to a IAX2 connection), the call works fine. When I hangup the connection on the phone handset, the channels used in the call remain open, and as more channels are opened, the calls degrade in quality. I've tested the connection with kphone and not had any problems, the call terminates correctly. No doubt other programs or devices would work fine too. I wouldn't have posted this message however if there was not a more serious issue. If I pull the ethernet connection during a call, the connection *remains* active and never comes down - suggesting the lack of a timeout or failure to detect a lack of voice data?! Perhaps this is only an issue with calls between SIP and IAX, I am not sure, and don't have enough time/devices to test other schenarios. I've added the show channels output in the additional information field to show the effect it has. The only way to remove the channels is to restart Asterisk. Hopefully someone else can reproduce this bug!!?? I'm running Asterisk 0.7.1 (no time to upgrade yet, I couldn't see anything in the changelog that might suggest a fix) Cheers, sam ****** ADDITIONAL INFORMATION ****** After calling another Asterisk server running the "echo test application", the channels remain open as follows: mullet*CLI> show channels Channel (Context Extension Pri ) State Appl. Data IAX2[voiptalk]/3 ( s 1 ) Up Bridged Call SIP/101-e917 SIP/101-e917 (internal-line 0904 1 ) Up Dial IAX2/<hidden>@voiptalk/0904 IAX2[voiptalk]/2 ( s 1 ) Up Bridged Call SIP/101-6633 SIP/101-6633 (internal-line 0904 1 ) Up Dial IAX2/<hidden>@voiptalk/0904 IAX2[voiptalk]/1 ( s 1 ) Up Bridged Call SIP/101-6be3 SIP/101-6be3 (internal-line 0904 1 ) Up Dial IAX2/<hidden>@voiptalk/0904 6 active channel(s) mullet*CLI> sip show channels Peer User/ANR Call ID Seq (Tx/Rx) Lag Jitter Format 10.14.0.4 101 003aba52-00 00101/00003 00000ms 0000ms ALAW 10.14.0.4 101 000fb8e7-00 00101/00003 00000ms 0000ms ALAW 10.14.0.4 101 000e42d5-00 00101/00003 00000ms 0000ms ALAW 3 active SIP channel(s) mullet*CLI> iax2 show channels Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter Format 217.14.132.162 844XXXXX 00001/00019 00053/00054 00470ms 1079ms ILBC 217.14.132.162 844XXXXX 00002/00020 00023/00024 00439ms 1087ms ILBC 217.14.132.162 844XXXXX 00003/00007 00201/00202 00470ms 0616ms ILBC 3 active IAX channel(s) ALSO: Hanging up on a voicemail connection gives the following Warning, which results in the automatic closure of the channels: Apr 9 17:14:20 WARNING[688150]: app_voicemail.c:1190 play_and_record: No audio available on SIP/101-09e8?? | ||
| Comments: | By: Brian West (bkw918) 2004-04-10 06:49:10 I'm not seeing that here with my trusty 7960... Show us the config ... and try placing a Hangup in your dialplan. By: Brian West (bkw918) 2004-04-10 07:03:37 Similar to 1307 By: chrisorme (chrisorme) 2004-04-10 08:43:57 Also very similar to 1239 - the Draytek 2600V sadly By: chrisorme (chrisorme) 2004-04-10 08:45:54 Actually I don't think it is similar to 1307.. typo probably ? By: muelas (muelas) 2004-04-10 13:29:08 As chrisorme says, 1307 is probably a typo .. but my problems are *very* similar to those registered in 1239, if not the same. I'll start a test call and see if it closes after (upto) 16mins as stated in that bug report. (I didn't wait that long last time!) With regard to the placing hangup in the dialplan, not quite sure what you mean... the call never exits the Dial() correctly! My Config for the sip part that registers the device (all standard stuff I'd imagine)(with commented stuff removed): -------- start cut ; SIP Configuration for Asterisk [general] port = 5060 ; Port to bind to bindaddr = 0.0.0.0messages if we're behind a NAT context = incoming ; Default for incoming calls maxexpirey=3600 ; Max length of incoming registration we allow disallow=all ; Disallow all codecs allow=ilbc allow=gsm disallow=g729 allow=alaw allow=ulaw ; Allow codecs in order of preference [101] type=friend host=dynamic defaultip=10.14.0.4 username=101 secret=<mysecret> dtmfmode=info allow=g723.1 allow=alaw allow=ulaw mailbox=201 ------ end cut I can provide extensions.conf if really necessary, but when using other software sip phones and h323 it all works fine. By: muelas (muelas) 2004-04-10 13:44:08 I've uploaded some sip debug output from a call to the local echo server. From what I can tell, BYEs are being sent from somewhere! 10.14.0.1 = Asterisk server 10.14.0.4 = ethernet phone (now about 16mins since I started the first call to the echo application, and still going strong!) By: chrisorme (chrisorme) 2004-04-10 17:05:10 Just a quick note. I assume you hung your phone up and the connect stays open of course? There's some reference in my bug (1237) to another person who found something like this with kphone. There are probably more devices this happens with too. I'm not sure what the present status of that is, there was a lot of discussion there but I don't know if anyone agreed to assign any coding. Ideas: You may want to try calling something apart from echo as the powers may not see this as a fair test ? Also does your line hang up when the remote person hangs up first rather than your phone, and does who the remote person is matter? (for me if they were on ISDN or some digital device all seemed ok, but if they were on analogue the line stayed open for up to 16 minutes - as I know you read - this may be some silence detection routine at the analogue exchange if such things exist). Hopefully there is a way of noticing there is no significant audio on the line for a prolonged period (10 secs? / 1 minute?), (doesn't voicemail have a way of checking this already?), and then an option to killoff the SIP channel after a timeout if it won't die could maybe be considered. Maybe even the header where devices say what they are could be used so the routine was only run for common culprits or just via a flag in sip.conf? How is your C ? Mine's not very good, do you know anyone that could patch this? It might be worth offering a bounty if you don't hear anything for a while ? Also it might be worth comparing debugs to try and find out what your device is doing wrong .. mine may not be sending byes or something. Yours may be doing something else or the same ? Anyway I'm sure these bugs are very closely related and I'm sure there's more hardware / SIP clients that leaves lines open and I think this is pretty important although we are working in some way with one of the fundamental limitations of SIP. For now you might want to do what I did and put AbsoluteTimeout(3600) in your Dialplan so it at least saves you a few pennies. (or cents!?) Also you may want to put ,Answer and ,Hangup in your extensions.conf after the dial line so that busy calls are handled correctly - that's what I had to do... But I still think your bug will remain after all of that but it's worth confirming that the bug still exists perhaps and the powers might look at it a little more? ie. I think it's worth doing what's suggested by the way with the Hangup in your extensions.conf then they should know the bug is real... Does your device have any status screen like the Draytek to say it thinks its hung up or does it know there's still a call in progress ? Also do you get this bug / behaviour without pulling out the ethernet cable? I did.. It might also be helpful to post which version of * you are using. My bug is with all versions I tried, both CVS, stable and CVS of March 5th. Good luck!!! By: Brian West (bkw918) 2004-04-10 21:22:08 yep I ment 1239 :P haha By: Mark Spencer (markster) 2004-04-10 21:48:58 This is a protocol limitation within SIP unless session timer support is added. By: muelas (muelas) 2004-04-11 01:49:29 Although this would be resolved by adding a timeout in SIP, my crappy voip ethernet device *does* appear to be sending (multiple) BYEs back to the server! The attached file shows this (unless I'm mistaken, which is possible.) If I am correct though, its a case of asterisk not understanding the BYEs ?? Hopefully not being too much of a pain in the ass re-opening the bug :-) (BTW, I didn't mention before, 101@10.14.0.4 is the voip device, 9600@10.14.0.1 is the echo test on the asterisk box.) By: Mark Spencer (markster) 2004-04-11 05:08:08 The reproducability here is listed as "always". Can you confirm that you literally *always* don't get Asterisk seeing the hangup? The attached debug certainly seems to suggest that Asterisk doesn't respond, but there is NO path for which receiving a "BYE" does not generate a 200 OK, unless it's failing some more serious low-level parsing. If you find me on IRC i'll be happy to diagnose this if you can reliably make it happen. By: chrisorme (chrisorme) 2004-04-15 08:24:24 Did this bug go anywhere ? I assume doing sip session timers is a big deal? (and they would have to monitor if there was audio on the lines to know if a call had hung? What about calls on hold though?) My bug about the Draytek 2600V was closed as the problem of unterminated call / calls that didn't hang up due to firmware in clients might be followed up here. Just wondering if it got anywhere. Today draytek released 2.5.2_UK firmware. I have yet to see if this solves the problem for me. - C By: Brian West (bkw918) 2004-04-17 17:42:43 Yes sip session timers are going to be in cvs-head at some point in the near future. | ||