[Home]

Summary:ASTERISK-09611: H and h parameters do not hang up when * is dialed
Reporter:Sherwood McGowan (rushowr)Labels:
Date Opened:2007-06-06 15:13:11Date Closed:2011-06-07 14:02:38
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.
Comments:By: Russell Bryant (russell) 2007-06-06 17:45:03

This works fine for me.  Can you provide the configuration that doesn't work?

I tried calling between two SIP phones with this simple extension and it worked ...

exten => 5001,1,Dial(SIP/5001||hH)
By: Joshua C. Colp (jcolp) 2007-06-06 19:02:39

I was able to reproduce this issue actually in one case... when directrtpsetup was turned on. That option does not check to see whether DTMF is needed, so it has the potential to directly setup the media streams when DTMF may need to be gathered on the media stream using inband/RFC2833.

Another issue might be a misconfigured/not set dtmfmode setting on the devices in question in sip.conf
By: Sherwood McGowan (rushowr) 2007-06-06 19:49:25

Thank you both for checking this out so quickly.

I'll doublecheck the sip.conf, but we were already able to receive DTMF transmissions from the client device in question during previous testing of a calling card system which used the READ app to get input. However, I will check the sip.conf and get back to you ASAP.
By: Sherwood McGowan (rushowr) 2007-06-07 14:17:20

FEEDBACK:

I checked our sip.conf and here's our pertinent settings:
relaxdtmf=yes
dtmfmode = rfc2833

Additionally, as mentioned before, we were able to read DTMF from the client devices via the dialplan in other cases using the READ application. Am I wrong in believing that this should signify that the h/H Dial arguments should also work?

Lastly, as far as I know directrtpsetup is not turned on, judging by the fact that the command exists in no configuration file for our installation. Is it on by default? Where should it be configured?

Hopefully this helps, because we're counting on this feature at this time.
By: Joshua C. Colp (jcolp) 2007-06-07 14:18:54

It should be disabled... can you please attach the console output of a call where this fails though so I can check something?
By: Sherwood McGowan (rushowr) 2007-06-07 15:23:22

Here's the relevant output:

   -- Executing [222@outbound:1] Goto("SIP/shervan-08218088", "DTMF_test|222|1") in new stack
   -- Goto (DTMF_test,222,1)
   -- Executing [222@DTMF_test:1] Answer("SIP/shervan-08218088", "") in new stack
   -- Executing [222@DTMF_test:2] Dial("SIP/shervan-08218088", "SIP/diamondcard/0043335720395|55|Hg") in new stack
   -- Called diamondcard/0043335720395
   -- SIP/diamondcard-081ce948 is ringing
   -- SIP/diamondcard-081ce948 is making progress passing it to SIP/shervan-08218088
   -- SIP/diamondcard-081ce948 answered SIP/shervan-08218088
   -- Packet2Packet bridging SIP/shervan-08218088 and SIP/diamondcard-081ce948
   -- Executing [222@DTMF_test:3] Read("SIP/shervan-08218088", "INPUT|prepaid-enter-dest|15") in new stack
   -- Accepting a maximum of 15 digits.
   -- <SIP/shervan-08218088> Playing 'prepaid-enter-dest' (language 'en')
   -- User entered nothing.
   -- Executing [222@DTMF_test:4] Verbose("SIP/shervan-08218088", "2|INPUT: ") in new stack
 == INPUT:
   -- Executing [222@DTMF_test:5] SayDigits("SIP/shervan-08218088", "") in new stack
   -- Executing [222@DTMF_test:6] Hangup("SIP/shervan-08218088", "") in new stack
 == Spawn extension (DTMF_test, 222, 6) exited non-zero on 'SIP/shervan-08218088'

Here's the dialplan code involved (only the DTMF_test context):
By: Sherwood McGowan (rushowr) 2007-06-07 15:27:05

Sorry, testing was not completely done correctly, will resubmit shortly after finished the test case.
By: Sherwood McGowan (rushowr) 2007-06-07 15:39:10

Test case:
Dialplan configured as shown in AEL format here:

context DTMF_test {
_222 => {
Answer();
Read(INPUT1|prepaid-enter-dest|15);
Verbose(2|INPUT1: ${INPUT1});
Saydigits(${INPUT1});
Dial(SIP/diamondcard/0043335720395|55|Hg);
Read(INPUT2|prepaid-enter-dest|15);
Verbose(2|INPUT2: ${INPUT2});
Saydigits(${INPUT2});
Hangup();
}
}

222 is called and processed in DTMF_test. The call is answered and to prove DTMF is working, the tester is asked to enter a "destination" of 15 digits. We then output (console and audio) the number given (INPUT1). The call is then placed using H and g (g so we can execute more commands after the remote side hangs up). After the call is ended, we get DTMF from the tester again and output as well (INPUT2).

Here's the output:

   -- Executing [222@outbound:1] Goto("SIP/shervan-08242498", "DTMF_test|222|1") in new stack
   -- Goto (DTMF_test,222,1)
   -- Executing [222@DTMF_test:1] Answer("SIP/shervan-08242498", "") in new stack
   -- Executing [222@DTMF_test:2] Read("SIP/shervan-08242498", "INPUT1|prepaid-enter-dest|15") in new stack
   -- Accepting a maximum of 15 digits.
   -- <SIP/shervan-08242498> Playing 'prepaid-enter-dest' (language 'en')
Internal RTCP NTP clock skew detected: lsr=3915557371, now=3885031324, dlsr=1 (0:000ms), diff=30526048Internal RTCP NTP clock skew detected: lsr=3915557371, now=3885031361, dlsr=1 (0:000ms), diff=30526011Internal RTCP NTP clock skew detected: lsr=3915561435, now=3885035317, dlsr=1 (0:000ms), diff=30526119Internal RTCP NTP clock skew detected: lsr=3915561435, now=3885035360, dlsr=1 (0:000ms), diff=30526076Internal RTCP NTP clock skew detected: lsr=3915888066, now=3885362141, dlsr=1 (0:000ms), diff=30525926Internal RTCP NTP clock skew detected: lsr=3915888066, now=3885362146, dlsr=1 (0:000ms), diff=30525921    -- User entered '004'
   -- Executing [222@DTMF_test:3] Verbose("SIP/shervan-08242498", "2|INPUT1: 004") in new stack
 == INPUT1: 004
   -- Executing [222@DTMF_test:4] SayDigits("SIP/shervan-08242498", "004") in new stack
   -- <SIP/shervan-08242498> Playing 'digits/0' (language 'en')
   -- <SIP/shervan-08242498> Playing 'digits/0' (language 'en')
Internal RTCP NTP clock skew detected: lsr=3916216795, now=3885691258, dlsr=1 (0:000ms), diff=30525538Internal RTCP NTP clock skew detected: lsr=3916216795, now=3885691262, dlsr=1 (0:000ms), diff=30525534    -- <SIP/shervan-08242498> Playing 'digits/4' (language 'en')
   -- Executing [222@DTMF_test:5] Dial("SIP/shervan-08242498", "SIP/diamondcard/0043335720395|55|Hg") in new stack
   -- Called diamondcard/0043335720395
Internal RTCP NTP clock skew detected: lsr=3916482019, now=3885956029, dlsr=1 (0:000ms), diff=30525991Internal RTCP NTP clock skew detected: lsr=3916482019, now=3885956034, dlsr=1 (0:000ms), diff=30525986Internal RTCP NTP clock skew detected: lsr=3916547555, now=3886021865, dlsr=1 (0:000ms), diff=30525691Internal RTCP NTP clock skew detected: lsr=3916547555, now=3886021870, dlsr=1 (0:000ms), diff=30525686    -- SIP/diamondcard-0821b598 is ringing
   -- SIP/diamondcard-0821b598 is making progress passing it to SIP/shervan-08242498
   -- SIP/diamondcard-0821b598 answered SIP/shervan-08242498
   -- Packet2Packet bridging SIP/shervan-08242498 and SIP/diamondcard-0821b598
   -- Executing [222@DTMF_test:6] Read("SIP/shervan-08242498", "INPUT2|prepaid-enter-dest|15") in new stack
   -- Accepting a maximum of 15 digits.
   -- <SIP/shervan-08242498> Playing 'prepaid-enter-dest' (language 'en')
   -- User entered nothing.
   -- Executing [222@DTMF_test:7] Verbose("SIP/shervan-08242498", "2|INPUT2: ") in new stack
 == INPUT2:
   -- Executing [222@DTMF_test:8] SayDigits("SIP/shervan-08242498", "") in new stack
   -- Executing [222@DTMF_test:9] Hangup("SIP/shervan-08242498", "") in new stack
 == Spawn extension (DTMF_test, 222, 9) exited non-zero on 'SIP/shervan-08242498'


Notes:
As you can see above, INPUT1 shows DTMF is working properly, but when the tester pressed * on the calling phone (shervan), nothing happened. Furthermore, when the call was manually ended on the called phone (diamondcard), the DTMF no longer registered, as reflected in the console and audio output of INPUT2.

Additional note, on one of the test calls, pressing * on the calling phone (shervan) resulted in loss of audio but not disconnection. All other test calls had no effect when using the * key.

Hope this is helpful. It looks like we may be experiencing a larger problem with Asterisk's handling of DTMF after a call is connected, even when it's later disconnected.
By: Joshua C. Colp (jcolp) 2007-06-07 15:42:49

What sort of device is shervan? And can you please turn on RFC2833 compensation in sip.conf by setting rfc2833compensate=yes and try again?
By: Sherwood McGowan (rushowr) 2007-06-07 15:46:35

"shervan" is an xlite softphone being used for testing. However, I've experienced this before on other systems using various devices.

Where is rfc2833compensate supposed to be placed in sip.conf? General section or per device?
By: Joshua C. Colp (jcolp) 2007-06-07 15:48:13

It can be in either.
By: Sherwood McGowan (rushowr) 2007-06-08 15:04:41

file, I did as you suggested but there was no change in the results of the test. Where shall we go from here?
By: Sherwood McGowan (rushowr) 2007-06-11 15:42:14

Also tried setting SIP dtmfmode to "auto" to no avail
By: Sherwood McGowan (rushowr) 2007-06-11 19:42:26

One last note, we also used this with a SIP to PSTN provider and used inband, rfc2833, and auto dtmf modes to no avail. We also tried running the test on a call to the test phone initiated by a call file on the server, and it also did not register DTMF tones.
By: Sherwood McGowan (rushowr) 2007-06-12 09:10:57

Gentlemen, I have a partial answer to this. We remembered that 1.4 removes itself from the media stream now, unlike 1.2 which stayed in the stream. Therefore, DTMF would no longer be recognized after the call is connected. We forced canreinvite=no and we now can get DTMF during the call.

However, there's still an issue.....We have post-far-end disconnect executions that allow the near end (the caller) to enter information via DTMF but without the forced canreinvite=no, it didn't work. Technically, Asterisk should re-enter the media stream once the far-end has disconnected, since there's nowhere else for the media stream to go.

Does this make sense or should I try to clear up my convoluted thought process?
By: Joshua C. Colp (jcolp) 2007-06-12 09:13:58

From the output you provided previously, a reinvite never happened. Did you change something to make it happen? As well Asterisk should reinvite audio back to itself once that bridge is over... if not please try the 1.4 SVN version, I may have fixed that already (I remember mucking with that stuff).
By: Joshua C. Colp (jcolp) 2007-06-12 09:18:38

Scratch that, fix coming in a sec.
By: Joshua C. Colp (jcolp) 2007-06-12 09:26:31

Okay 1.4 as of revision 68922 should reinvite back the media to Asterisk at the end... but that still begs the question - if Asterisk is configured properly with dtmfmode set to rfc2833 on both sides it should NOT have reinvited. It would have known it had to keep RTP to get at the RTP for your H option.
By: Sherwood McGowan (rushowr) 2007-06-12 12:02:32

Answers to varies questions posed follow:

1. Reinvite configuration: No, we did not configure anything for reinvites, additionally, let me review the other changes I made and I'll see if something else was the cause.

2. Regarding both ends' DTMF modes, yes they were both rfc2833.

I'll test the fix this afternoon and will post the results here :) Thanks for all your hard work so far!
By: Sherwood McGowan (rushowr) 2007-06-12 14:37:51

I updated my source tree, recompiled, and installed. I then removed canreinvite=no from the sip configuration for the shervan device to test the functionality of your fix. Unfortunately, it still does not catch the * DTMF tone during the call, nor does it recognize DTMF tones in the post-call dialplan executions.
By: Joshua C. Colp (jcolp) 2007-06-18 13:26:53

I have to see the sip.conf configuration and latest console output. It should *not* be reinviting and doesn't in my tests... so something in my configuration must differ.
By: Sherwood McGowan (rushowr) 2007-06-18 13:36:17

Here's the general configuration and the shervan device.

[general]
rfc2833compensate=yes
bindport=5060
bindaddr=0.0.0.0
pendantic=yes
maxexpiry=3600
defaultexpiry=3600
disallow=all ; First disallow all codecs
allow=ilbc
allow=alaw
allow=ulaw
allow=gsm
language=en
relaxdtmf=yes
rtptimeout=60
rtpholdtimeout=300
dtmfmode = rfc2833


[shervan]
type=peer
host=dynamic
canreinvite=no
disallow=all
allow=gsm
allow=ulaw
allow=alaw
accountcode=9
username=shervan
password=abc123
context=outbound
callerid=12223334444
By: Joshua C. Colp (jcolp) 2007-06-18 13:39:11

and the provider?
By: Sherwood McGowan (rushowr) 2007-06-18 13:42:32

Sorry missed that. Keep in mind however that this is not limited to UA-Asterisk-UA conversations, if the provider hangs up DTMF no longer works on post-call processing either.

(sanitized version)
[diamondcard]
type=peer
username=25811
fromuser=25811
disallow=all
allow=gsm
allow=ilbc
By: Sherwood McGowan (rushowr) 2007-06-20 11:29:46

The console output was identical to the output previously submitted, I saw no change. Please let me know if you require me to post them again.
By: Joshua C. Colp (jcolp) 2007-06-25 10:18:18

I've tried numerous ways yet again on my setup to make this happen and using the config you provided it works great... I therefore need access to your setup. Also: are you still using 1.4.4?
By: Sherwood McGowan (rushowr) 2007-06-27 14:17:36

Using the latest 1.4 checked out from SVN (SVN-branch-1.4-r66160M)

Allowing access to this particular setup is not possible, but if necessary I can create a demo setup for you to connect with
By: Joshua C. Colp (jcolp) 2007-06-27 14:47:15

I basically just need a system I can SSH into that exhibits this issue so I can look at it live and make changes/test/poke at it.
By: Sherwood McGowan (rushowr) 2007-06-27 14:53:29

I'll get together with the boss and see about setting one up. Keep in mind that it may be on a very low end server in my home office (300mhz) just purely because if I can't get permission for the dev servers we use, I have to use my personal system at home.
By: Sherwood McGowan (rushowr) 2007-06-29 07:34:02

I'll be working on this shortly, I'm leaving on a week long vacation but will return to try and get this all hammered out.
By: Sherwood McGowan (rushowr) 2007-06-29 15:35:34

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@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.
By: Sherwood McGowan (rushowr) 2007-07-12 13:31:22

No updated thoughts? The configuration is exactly as it is in bug ASTERISK-9781, as it is on the same server. I'll talk to the boss today about getting you onto our server but I'm sure he'll ask about an NDA. Is this ok or should I put together a test server at my home office?
By: Joshua C. Colp (jcolp) 2007-07-13 09:26:50

No updated thoughts as access is needed... if an NDA could be avoided it would be nice.
By: Sherwood McGowan (rushowr) 2007-07-13 14:06:40

File, I'll make a test server but it won't be until next week.
By: Sherwood McGowan (rushowr) 2007-07-18 08:23:46

I've returned from vacation and will set you up on my test server. I'll warn you now, it's a very low end system (300mhz). For security purposes, I'll need to know how to send you the connection information, I don't want to post it on this public list.
By: Joshua C. Colp (jcolp) 2007-07-18 08:25:18

jcolp@digium.com is my email.
By: Sherwood McGowan (rushowr) 2007-07-18 08:34:24

Getting together with the boss now, we're setting up a vserver for you to connect to. Should be ready in about a day. Sorry for the delays, it's a busy summer and we're in the final phases of testing a BIG solution.
By: Sherwood McGowan (rushowr) 2007-07-24 14:49:58

File, I'm setting up that DTMF testing server now, will have login details for you shortly.
By: Sherwood McGowan (rushowr) 2007-07-24 15:15:57

Login details sent, the server's a Virtual server so we dont have to worry about messing around within a company testing server.

I'll have testing dialplan stuff done tomorrow.
By: Sherwood McGowan (rushowr) 2007-07-26 12:58:29

File, sorry there was an issue with that Vserver. I'm sending you new details today. Please let me know when you get them
By: Sherwood McGowan (rushowr) 2007-07-26 14:23:12

File the first test bed is done. You'll need to set up two SIP rfc2833 compatible clients and then dial 111 while connected to the server. You'll be prompted for enter destination, enter the number of the second client. It'll be repeated back to you and then it will dial the other client. Then you can try * for hangup
By: Sherwood McGowan (rushowr) 2007-07-30 14:55:32

Server is temporarily offline, will update when it's available again.
By: Joshua C. Colp (jcolp) 2007-08-03 09:54:54

Have you tried it yet with your X-Lite to see if that was the cause?
By: Sherwood McGowan (rushowr) 2007-08-03 12:46:26

File, sorry the boss has had me on other things. On Monday I'll be checking this out and testing.

Did you ever try the 111 callback test? That's one of the other situations that we noticed this bug.
By: Joshua C. Colp (jcolp) 2007-08-06 09:41:20

No, I did not. If the system becomes available again though and you can test using the previous client as was used before please give me a shout on Jabber.
By: Sherwood McGowan (rushowr) 2007-08-06 10:32:59

Sounds like a plan, will do
By: Joshua C. Colp (jcolp) 2007-09-04 08:15:33

It's been a month without any further comments on this... if it's still an issue on Asterisk's side grab me on Jabber and reopen.