[Asterisk-bugs] [Asterisk 0009905]: H and h parameters do not hang up when * is dialed
noreply at bugs.digium.com
noreply at bugs.digium.com
Fri Jun 29 15:35:34 CDT 2007
email_notification_title_for_action_bugnote_submitted
======================================================================
http://bugs.digium.com/view.php?id=9905
======================================================================
Reported By: rushowr
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 9905
Category: Applications/app_dial
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
Asterisk Version: 1.4.4
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: No
Request Review:
======================================================================
Date Submitted: 06-06-2007 15:13 CDT
Last Modified: 06-29-2007 15:35 CDT
======================================================================
Summary: H and h parameters do not hang up when * is dialed
Description:
(This bug was noticed on a SIP only implementation)
Dial's H argument is supposed to allow the calling user to press *, which
then hangs up the call. 'h' argument does the same for the called party.
Unfortunately, neither seems to work. This has been tested several times
with our 1.4 system.
As a side note, would it be possible to allow the admin to set the key
combination to press to accomplish the hangup? There's been interest in
using ## in my camp.
======================================================================
----------------------------------------------------------------------
rushowr - 06-29-07 15:35
----------------------------------------------------------------------
Couple quick notes...
1. Here's the output from a call where Dial failed to hang up when ** was
entered. Additionally, you'll see ## used because the tester forgot I had
disabled that feature.
-- SIP/[FAR END] answered SIP/[NEAR END]
Internal RTCP NTP clock skew detected: lsr=3970800615, now=3930304308,
dlsr=1 (0:000ms), diff=40496308
Internal RTCP NTP clock skew detected: lsr=3970800615, now=3930304359,
dlsr=1 (0:000ms), diff=40496257
Internal RTCP NTP clock skew detected: lsr=3970802647, now=3930305725,
dlsr=1 (0:000ms), diff=40496923
Internal RTCP NTP clock skew detected: lsr=3970802647, now=3930305728,
dlsr=1 (0:000ms), diff=40496920
Internal RTCP NTP clock skew detected: lsr=3971130327, now=3930632588,
dlsr=1 (0:000ms), diff=40497740
Internal RTCP NTP clock skew detected: lsr=3971130327, now=3930632593,
dlsr=1 (0:000ms), diff=40497735
[Jun 29 22:30:02] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '#'
received on SIP/[NEAR END], duration 0 ms
Internal RTCP NTP clock skew detected: lsr=3971461087, now=3930963347,
dlsr=1 (0:000ms), diff=40497741
Internal RTCP NTP clock skew detected: lsr=3971461087, now=3930963352,
dlsr=1 (0:000ms), diff=40497736
[Jun 29 22:30:06] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '*'
received on SIP/[NEAR END], duration 0 ms
[Jun 29 22:30:07] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '*'
received on SIP/[NEAR END], duration 0 ms
Internal RTCP NTP clock skew detected: lsr=3971724279, now=3931226745,
dlsr=1 (0:000ms), diff=40497535
Internal RTCP NTP clock skew detected: lsr=3971724279, now=3931226750,
dlsr=1 (0:000ms), diff=40497530
Internal RTCP NTP clock skew detected: lsr=3971789815, now=3931292570,
dlsr=1 (0:000ms), diff=40497246
Internal RTCP NTP clock skew detected: lsr=3971789815, now=3931292575,
dlsr=1 (0:000ms), diff=40497241
Internal RTCP NTP clock skew detected: lsr=3972120576, now=3931623169,
dlsr=1 (0:000ms), diff=40497408
Internal RTCP NTP clock skew detected: lsr=3972120576, now=3931623173,
dlsr=1 (0:000ms), diff=40497404
[Jun 29 22:30:18] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '*'
received on SIP/[NEAR END], duration 0 ms
Internal RTCP NTP clock skew detected: lsr=3972451270, now=3931953773,
dlsr=1 (0:000ms), diff=40497498
Internal RTCP NTP clock skew detected: lsr=3972451270, now=3931953779,
dlsr=1 (0:000ms), diff=40497492
[Jun 29 22:30:21] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '*'
received on SIP/[NEAR END], duration 0 ms
Internal RTCP NTP clock skew detected: lsr=3972643815, now=3932145953,
dlsr=1 (0:000ms), diff=40497863
Internal RTCP NTP clock skew detected: lsr=3972643815, now=3932145957,
dlsr=1 (0:000ms), diff=40497859
[Jun 29 22:30:24] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '*'
received on SIP/[NEAR END], duration 0 ms
[Jun 29 22:30:24] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '*'
received on SIP/[NEAR END], duration 0 ms
Internal RTCP NTP clock skew detected: lsr=3972782030, now=3932284366,
dlsr=1 (0:000ms), diff=40497665
Internal RTCP NTP clock skew detected: lsr=3972782030, now=3932284371,
dlsr=1 (0:000ms), diff=40497660
[Jun 29 22:30:27] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '#'
received on SIP/[NEAR END], duration 0 ms
[Jun 29 22:30:28] DTMF[2744]: channel.c:2297 __ast_read: DTMF end '#'
received on SIP/[NEAR END], duration 0 ms
Internal RTCP NTP clock skew detected: lsr=3973111808, now=3932613755,
dlsr=1 (0:000ms), diff=40498054
Internal RTCP NTP clock skew detected: lsr=3973111808, now=3932613760,
dlsr=1 (0:000ms), diff=40498049
== Spawn extension (dodial, s, 10) exited non-zero on 'SIP/[NEAR END]'
-- Executing [h at dodial:1] GotoIf("SIP/[NEAR END]", "1?2:14") in new
stack
-- Goto (dodial,h,2)
2. It's worth noting this is performed in a callback situation where near
end was called by Asterisk and then offered a calling card menu. After
authenticating, the destination number is entered and [FAR END] is called.
Once connected the tester attempted to use ** to disconnect AND ## (had
been previously used for hangup in features.conf) but had to hang up the
near end instead.
Issue History
Date Modified Username Field Change
======================================================================
06-06-07 15:13 rushowr New Issue
06-06-07 15:13 rushowr Issue Monitored: rushowr
06-06-07 15:13 rushowr Asterisk Version => 1.4.4
06-06-07 15:13 rushowr SVN Branch (only for SVN checkou => N/A
06-06-07 15:13 rushowr Disclaimer on File? => No
06-06-07 17:45 russell Note Added: 0064682
06-06-07 17:45 russell Status new => feedback
06-06-07 19:02 file Note Added: 0064690
06-06-07 19:49 rushowr Note Added: 0064699
06-07-07 14:17 rushowr Note Added: 0064754
06-07-07 14:18 file Note Added: 0064755
06-07-07 15:23 rushowr Note Added: 0064763
06-07-07 15:27 rushowr Note Added: 0064765
06-07-07 15:39 rushowr Note Added: 0064768
06-07-07 15:42 file Note Added: 0064769
06-07-07 15:46 rushowr Note Added: 0064770
06-07-07 15:48 file Note Added: 0064771
06-08-07 15:04 rushowr Note Added: 0064834
06-11-07 15:42 rushowr Note Added: 0064932
06-11-07 19:42 rushowr Note Added: 0064947
06-12-07 09:10 rushowr Note Added: 0064968
06-12-07 09:13 file Note Added: 0064969
06-12-07 09:18 file Note Added: 0064971
06-12-07 09:26 file Note Added: 0064972
06-12-07 12:02 rushowr Note Added: 0064992
06-12-07 14:37 rushowr Note Added: 0065003
06-18-07 13:26 file Note Added: 0065291
06-18-07 13:36 rushowr Note Added: 0065293
06-18-07 13:39 file Note Added: 0065295
06-18-07 13:42 rushowr Note Added: 0065296
06-20-07 11:29 rushowr Note Added: 0065433
06-25-07 10:18 file Note Added: 0065644
06-27-07 14:17 rushowr Note Added: 0065780
06-27-07 14:47 file Note Added: 0065783
06-27-07 14:53 rushowr Note Added: 0065784
06-28-07 08:14 loloski Issue Monitored: loloski
======================================================================
More information about the Asterisk-bugs
mailing list