Summary: | ASTERISK-08305: [patch] When using L option on Dial, instead of warning asterisk disconnects the call | ||
Reporter: | Richard Wilkinson (rickead2000) | Labels: | |
Date Opened: | 2006-12-07 14:38:46.000-0600 | Date Closed: | 2006-12-12 22:40:12.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Applications/app_dial |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 8541.patch | |
Description: | When using the L option in a Dial command to limit the length of a call and providing values to provide a warning at, asterisk disconnects the call at the first warning value. e.g. DIAL (SIP/1234,30,L(180000:60000:30000)) Will disconnect the call when there are 60s to go, instead of providing a warning. ****** ADDITIONAL INFORMATION ****** Dec 7 20:26:56 VERBOSE[22167] logger.c: AGI Rx << EXEC DIAL SIP/1234|30|L(180000:60000:30000) "" Dec 7 20:26:56 VERBOSE[22167] logger.c: -- AGI Script Executing Application: (DIAL) Options: (SIP/1234|30|L(180000:60000:30000)) Dec 7 20:26:56 VERBOSE[22167] logger.c: -- Limit Data for this call: Dec 7 20:26:56 VERBOSE[22167] logger.c: -- - timelimit = 180000 Dec 7 20:26:56 VERBOSE[22167] logger.c: -- - play_warning = 60000 Dec 7 20:26:56 VERBOSE[22167] logger.c: -- - play_to_caller= yes Dec 7 20:26:56 VERBOSE[22167] logger.c: -- - play_to_callee= no Dec 7 20:26:56 VERBOSE[22167] logger.c: -- - warning_freq = 30000 Dec 7 20:26:56 VERBOSE[22167] logger.c: -- - start_sound = UNDEF Dec 7 20:26:56 VERBOSE[22167] logger.c: -- - warning_sound = timeleft Dec 7 20:26:56 VERBOSE[22167] logger.c: -- - end_sound = UNDEF Dec 7 20:26:56 DEBUG[22167] chan_sip.c: Setting NAT on RTP to 524288 Dec 7 20:26:56 DEBUG[22167] chan_sip.c: Outgoing Call for 1234 Dec 7 20:26:56 VERBOSE[22167] logger.c: -- Called 1234 Dec 7 20:26:56 DEBUG[20929] chan_sip.c: Acked pending invite 102 Dec 7 20:26:56 DEBUG[20929] chan_sip.c: Stopping retransmission on '2f355fc04814f1a4286b85c30e4c2469@lvdx.com' of Request 102: Match Found Dec 7 20:26:56 DEBUG[20929] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '2f355fc04814f1a4286b85c30e4c2469@domain.com' Request 103: Found Dec 7 20:27:03 DEBUG[20929] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '2f355fc04814f1a4286b85c30e4c2469@domain.com' Request 103: Found Dec 7 20:27:03 DEBUG[20918] channel.c: Avoiding initial deadlock for 'SIP/1234-00652dd0' Dec 7 20:27:03 VERBOSE[22167] logger.c: -- SIP/1234-00652dd0 is ringing Dec 7 20:27:03 DEBUG[22167] channel.c: Driver for channel 'SIP/70-aca16320' does not support indication 3, emulating it Dec 7 20:29:04 DEBUG[22167] channel.c: Nobody there, continuing... Dec 7 20:29:04 DEBUG[22167] channel.c: Bridge stops bridging channels SIP/70-aca16320 and SIP/1234-00652dd0 Dec 7 20:29:04 DEBUG[22167] chan_sip.c: update_call_counter(1234) - decrement call limit counter Dec 7 20:29:04 DEBUG[22167] app_dial.c: Exiting with DIALSTATUS=ANSWER. | ||
Comments: | By: Serge Vecher (serge-v) 2006-12-07 14:44:27.000-0600 I think this was recently fixed, can you please check out 1.2 from svn and check? By: Anthony LaMantia (alamantia) 2006-12-07 16:11:57.000-0600 yes, I also recall a patch resolving this issue or one much like it. if you can please test this out with the latest 1.2svn branch and see if the problem is still happening on this build. By: Richard Wilkinson (rickead2000) 2006-12-10 16:16:35.000-0600 Latest 1.2svn branch is still broken! By: Tony Howat (tonyh) 2006-12-11 08:52:49.000-0600 This bug applies to zaptel calls as well as SIP. Looks like ASTERISK-8155 was the same thing. I can also confirm that latest 1.2svn is still broken. By: Serge Vecher (serge-v) 2006-12-11 10:41:41.000-0600 murf: can you please investigate these claims? By: Serge Vecher (serge-v) 2006-12-11 10:42:55.000-0600 tonyh, rickhead2000: please specify which revisions you've observed these in 1.2 branch... thanks. By: Tony Howat (tonyh) 2006-12-11 12:17:39.000-0600 I tried full 1.2 SVN checkout today, r48233 of channel.c. My issue is with a normal zaptel call, and it's still exhibiting the same behaviour - ie. hanging the call up instead of warning. Thanks for looking at this... By: Tony Howat (tonyh) 2006-12-11 12:33:34.000-0600 -- Executing Dial("Zap/1-1", "Zap/g1/07xxxxxx43||L(60000:30000:5000)") in new stack -- Limit Data for this call: -- - timelimit = 60000 -- - play_warning = 30000 -- - play_to_caller= yes -- - play_to_callee= no -- - warning_freq = 5000 -- - start_sound = UNDEF -- - warning_sound = xtest/warn -- - end_sound = xtest/terminate -- Requested transfer capability: 0x00 - SPEECH -- Called g1/07xxxxxxx43 -- Zap/2-1 is proceeding passing it to Zap/1-1 -- Zap/2-1 is ringing -- Zap/2-1 answered Zap/1-1 (after 30s) -- Hungup 'Zap/2-1' == Spawn extension (extdialbridge, 1, 107) exited non-zero on 'Zap/1-1' > cdr_odbc: Query Successful! -- Hungup 'Zap/1-1' Note that samples etc are there, this stuff worked previously under 1.2.7 for me. By: cmaj (cmaj) 2006-12-11 20:15:48.000-0600 Same problem in 1.4 beta 3. By: Steve Murphy (murf) 2006-12-12 07:49:14.000-0600 Amazing! I can reproduce the problem! How on EARTH did I not see this problem with the previous bug? OK, enough fooling around. I'll analyze the code that's there, and rewrite it if I have to, to make it work. And if this problem extends into 1.4 and up, I'll get it there, too. By: Tony Howat (tonyh) 2006-12-12 08:27:33.000-0600 Excellent stuff murf... thanks! By: Steve Murphy (murf) 2006-12-12 13:59:58.000-0600 I have uploaded small patch. This is a matter of one bug's fix creating another; the fix I made previously for 8386 was valid, and fixed the problem, however, a subsequent bug fix on a DTMF issue broke the code. Hopefully, they are now both happily working. Try out my patch, and see if works. If it does, I'll commit it to 1.2. By: Steve Murphy (murf) 2006-12-12 14:36:39.000-0600 I just did a 1.4 stock latest svn build and install, and tested the L(x:y:z) in dial, and it works fine. cmaj, you need to tell me EXACTLY what you did to 1.4, when it fails, or I won't be able to fix it. By: Richard Wilkinson (rickead2000) 2006-12-12 15:26:08.000-0600 murf - I can confirm that patch resolves the issue when patched against the latest 1.2svn - nice work! By: Steve Murphy (murf) 2006-12-12 22:35:12.000-0600 working patch applied to 1.2 with r.48434. and blocked from 1.4 via r.48435 |