Summary:	ASTERISK-01232: Draytek 2600V when placing SIP calls to PSTN user on analogue line keeps call open after Dtek hangup so PSTN user can't call out
Reporter:	chrisorme (chrisorme)	Labels:
Date Opened:	2004-03-17 08:33:23.000-0600	Date Closed:	2011-06-07 14:10:46
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) draytek_lockline_final ( 1) drylckup_final
Description:	When placing calls from a Draytek 2600V port to PSTN user via ISDN30 lines in * the call connects fine.  However, when the Draytek user hangsup IF the PSTN user is on an analogue line then the call continues for a while. sip show channels and iax2 show channels (the ISDN 30 is on another box) both show the call continuing in progress. The Draytek shows on its status screen that it thinks the call has ended.   When the PSTN user hangsup the call is still in progress.  When the PSTN user tries to make further calls they can't as they have no dialtone (for at least a few minutes, but this can be as high as 16 minutes) as the call still appears in progress.   When calling an ISDN user from the Draytek (not an analogue line user) the call stays up when the Draytek hangups but once the ISDN user hangs up the call is dropped, so the problem is only with users on analogue PSTN.   The problem is that the VoIP user via * gets charged for the time the call is up and the PSTN analogue lines user's phone is out of commission until some timeout is reached (exchange? *?) or until 'restart now' or 'stop now' is issued from asterisk to give them their line back. Calls placed from the analogue PSTN to Draytek via Asterisk terminate fine when the PSTN user hangs up. Placing calls from the Draytek to another Draytek port via * hangs up fine.   This problem is isolated to when the Draytek calls PSTN users on analogue lines. ****** ADDITIONAL INFORMATION ****** I feel this may be something to do with the way the Draytek 2600V ends a call / sends bye. I did sip debug and didn't see 'BYE' - this problem occurs in all versions of the Draytek firmware.  Perhaps it isn't sending a correct BYE, or * isn't recognising it? It would be nice if I could produce a SIP DEBUG log from a file.  Any tips on how I can do this? Comparing with sipura and snom units this bug is isolated to the Draytek. The Draytek is a top selling product here in the UK as it is an ADSL router providing 2 FXS lines.  If we could get this bug fixed (together with md5/secret bug on LAN traffic auth/register failure and that the draytek can't register with a secret) we could actually deploy it.  The only other bug with it is g729 volume but this is a Draytek firmware bug I am sure. Hope this is a helpful report.  Don't hesitate to email me with suggested patches or chan_sip2.c or with questions or requests for debug if you think I can help or please give me pointers in the code ( no pun intended ) but I'm not a decent programmer. If we really really want to get this sorted could we offer a bounty? or would custom work from Digium be required to get this fixed?  Please excuse my ignorance. Chris
Comments:	By: Brian West (bkw918) 2004-03-17 21:31:37.000-0600 post a sip debug of the transaction. By: chrisorme (chrisorme) 2004-03-17 21:44:25.000-0600 I've attached an example.  In this case the PSTN analogue line was still up after 13 minutes after the draytek user placing the call hungup at which point I did asterisk -rx "restart now" to get them their line back.   If this sip debug output file doesn't help let me know - I have another example however I attempted to upload debug log but got APPLICATION ERROR ASTERISK-11: ERROR: File upload failed. PHP file uploads may be disabled. Please ask your admin to run the admin_check script to debug this problem. (bug_file_add.php: line 33) Many thanks for even looking at this for me - It'd be so amazing if it's remotely possible this is fixable. thanks - Chris By: chrisorme (chrisorme) 2004-03-17 21:51:54.000-0600 Ok. I got the files attached. drylckup_final is probably the most helpful as it this is the only thing that happened. If it is too brief try draytek_lockline_final where the same thing happened. I hope these help - thanks again - Chris By: chrisorme (chrisorme) 2004-03-18 11:11:15.000-0600 I think I may have noticed/reported what described is in Bug ASTERISK-1600207 except it is 100% repeatable with the Draytek 2600V when the person called is on an analogue line.   The media stream is staying open for some while after hangup - between 2-3 and 15-17 minutes leaving open the theoretical possibility of longer call still. By: antonyellis (antonyellis) 2004-03-21 12:14:50.000-0600 I can confirm this.  Try plugging a sipura into one of the draytek LAN ports and your phones into this, calls connect faster and are terminated properly by asterisk. By: chrisorme (chrisorme) 2004-03-30 13:11:15.000-0600 The termination of the Draytek is not detected by * I think.  Probably due to the Draytek not sending a bye?   Or doing something nonstandard ? Other symptoms of this are : When calling a person who does not answer and hanging up the phone on the Draytek the person's phone remotely keeps ringing.  This does not happen with other sip phones. It is then not possible to call out whilst the remote phone is still ringing etc. Any chance of looking at the logs and getting a workaround for this and other clients or should I badger Draytek for a firmware improvement to handle termination better?  Anything specifically I should ask them to fix/do as we have about a dozen of these units for remote workers we'd like to use with * ? Chris edited on: 03-30-04 12:03 By: chrisorme (chrisorme) 2004-04-10 08:39:43 I guess I haven't received any feedback on this report as it's not considered something worth working around with * or is being look at in another report. From reading other reports I don't think the Draytek is the only client that suffers this behaviour. The only reason I think a work around is worth considering is that the manufacturer may take forever to come up with a firmware patch and this device is as far as I know the only gateway with built in ADSL, (wireless to come) and FXS ports. By: Mark Spencer (markster) 2004-04-10 21:50:09 This will require sip session timer support to fix By: chrisorme (chrisorme) 2004-04-11 06:11:53 Sorry for reopening this, but finally ... Is there a way I can check whether the Draytek is actually sending the BYEs and * not understanding them or if the Draytek just plain is not sending them ?? Is this what etherreal is for ?  what can I use ? Or otherwise how can I find out what the exact problem is ie why the SIP channel is staying open so I can at least give a full account to Draytek who 'seem' very keen to fix this in their next firmware update? Can they really have totally forgotten to send BYE at the end of a call ? Their 'call progress monitor' in the web interface believes the call to have ended and will offer dialtone.  Of course trying to place a call then fails. I'm afraid I'm just not sure of exactly what I should see in the attached logs and therefore how to diagnose what goes wrong. By: Olle Johansson (oej) 2004-04-11 07:17:30 The CLI command SIP debug will log all SIP messages to and from asterisk. You can pipe asterisk to a file with the Unix command "tee" to get a log ('man tee' will help). Otherwise, software like 'nast' and ethereal and packetyzer (for windows) is good at capturing SIP packets. There's another bug report for SIP timers, so I'll close this again. By: zoa (zoa) 2004-12-31 07:44:58.000-0600 Just reopening to add some more info. Same issue happens on 2500 and 2900 series. the machines are not sending any sip messages at all on hangup. (We doublechecked this with tcpdump) Obviously a firmware bug.