Summary:ASTERISK-01385: SIP channels remain open with Elesign ESC1710 and ethernet loss
Reporter:muelas (muelas)Labels:
Date Opened:2004-04-09 12:56:15Date Closed:2011-06-07 14:10:45
Versions:Frequency of
Environment:Attachments:( 0) siplog-10-April-2004.txt
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)



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        101         003aba52-00  00101/00003  00000ms  0000ms  ALAW        101         000fb8e7-00  00101/00003  00000ms  0000ms  ALAW        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   844XXXXX    00001/00019  00053/00054  00470ms  1079ms  ILBC   844XXXXX    00002/00020  00023/00024  00439ms  1087ms  ILBC   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
port = 5060                     ; Port to bind to
bindaddr = 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=ulaw                      ; Allow codecs in order of preference

------ 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! = Asterisk server = 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@ is the voip device, 9600@ 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.