[Home]

Summary:ASTERISK-09083: Early B3 not working properly in case of a cause code != 16 being returned from the remote party (calling from SIP to mISDN)
Reporter:Gary Hawkins (garyhawkins01)Labels:
Date Opened:2007-03-23 09:01:36Date Closed:2007-07-11 19:59:04
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_misdn
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) misdn.conf
( 1) misdn-log.txt
( 2) sip.txt
( 3) verbose.txt
Description:Since Asterisk 1.4.1, I have been able to receive announcements from the exchange when the call is terminated with a cause code != 16.  For example, if I call a number which returns cause code 1, I should hear 'The number you have dialled has not been recognised; please check and try again' from the exchange.  Instead mISDN seems to return Busy and this is passed back to the SIP phone, causing the SIP phone to disconnect the call straightaway as 'Busy'.  If I then add Hangup(${HANGUPCAUSE}) into the dialplan immediately after the Dial statement, I get the correct cause code sent back to the SIP channel but I still get no early B3 audio.

****** ADDITIONAL INFORMATION ******

Attached:

misdn.conf
Verbose log for a call to a number which is unallocated (cause code 1)
SIP log for a similar call
mISDN log for a similar call

I am using a Fritz! PCI card, latest mISDN CVS (as of today 23/3/2007) and Asterisk 1.4 SVN r59145.  But I have been able to observe the same effect on Asterisk 1.4.1 and 1.4.2 releases too.
Comments:By: Andreas Anderson (aanderson) 2007-03-25 10:53:50

a quick fix for this problem (reverting a change that was done in svn):

                       if (ch->ast) {
                               ch->ast->hangupcause=bc->cause;
-                               ast_queue_control(ch->ast, AST_CONTROL_BUSY);
+//                             ast_queue_control(ch->ast, AST_CONTROL_BUSY);
                       }
                       ch->need_busy=0;
                       break;
By: Gary Hawkins (garyhawkins01) 2007-03-25 11:21:19

gallium123: the quick fix you posted works for me.
By: crich (crich) 2007-03-26 01:55:43

The problem here is, that we need to send a CONTROL_BUSY when the called party *is* busy, else this channel won't jump into the busy extension. I would suggest to apply the following patch, that should work for both cases:

Index: channels/chan_misdn.c
===================================================================
--- channels/chan_misdn.c       (Revision 59198)
+++ channels/chan_misdn.c       (Arbeitskopie)
@@ -3863,7 +3863,8 @@

                       if (ch->ast) {
                               ch->ast->hangupcause=bc->cause;
-                               ast_queue_control(ch->ast, AST_CONTROL_BUSY);
+                               if (bc->cause==17) /* jump to busy-exten, else we listen to inband info*/
+                                       ast_queue_control(ch->ast, AST_CONTROL_BUSY);
                       }
                       ch->need_busy=0;
                       break;
By: crich (crich) 2007-03-26 01:59:37

alternatively you could also handle the problem in the busy extension, there you could just wait(xx) as long as anouncement is played and then send the hangup then.

This is even much more preferably then either my patch or the one posted above, because it makes it possible for the user to decide what should happen when a "Not Normal" Call Clearing happened.

With either patch above we assume that a human user is making the call and is listening to the inband anouncement. If we wanted to automate calls (like in call centers) it could make sense to just drop calls to not existing numbers instead of waiting till the anouncement is played.

Therefor i suggest for your case to use the busy extension and to wait there for maybe 30 Seconds, so the user can listen to the inband anouncement.


By: Andreas Anderson (aanderson) 2007-03-26 04:37:19

I disagree with your second comment:

1. It changes the behaviour from asterisk 1.4.0 to >=1.4.1. Bad, brakes many installations.

2. Why send a call that is not busy to the busy extension?! The are 126 cause codes that do not signal a busy, so why handle them as such?

I think you should eighter revert to the original version or apply your patch, but changing the behaviour of a stable version was allways considered a no-no...
By: Gary Hawkins (garyhawkins01) 2007-03-26 05:10:30

I agree with galium123's first comment.  We should not be changing chan_misdn's behaviour in a stable tree.  Secondly, I don't think it makes sense to mark cause codes as 'busy' when they are most obviously not.  For this reason, I prefer your patch, crich.  This works better for me because the early B3 audio for cause code 17 from my telco is the 'engaged tone' (i.e. busy tone) and is not an actual announcement.  Therefore, passing through cause code 17 to the SIP channel is perfectly acceptable for me.  However, some others (e.g. 1, 19, 63) do have meaningful announcements.

However, I would like to see this functionality configurable in a future version, or SVN trunk version of Asterisk.  Perhaps we could have a new configuration option 'early_b3_causecodeaudio' which if set to 'true' would cause Asterisk to exhibit the 1.4.0 behaviour (which would be the default so as not to change the status quo) and if set to 'false' would use the new >= 1.4.1 behaviour (but calls NOT marked as 'busy' as per galium123's second comment above).  Personally, after having played with the ability to generate my own announcements over the weekend for certain cause codes I think it is a useful feature, mainly because I think some of the telco announcements aren't very informative, but it should be something the user chooses to implement, because recording 127 cause code announcements is time consuming, for one (and for the most part most of the cause codes are so rare it isn't worth doing properly anyway.)

What do you think?
By: crich (crich) 2007-03-26 05:27:10

Gal:

i agree.

Gary:

I agree too, i have thought of making it configureable ... but i don't like to add that much configoptions, because we already have so much.. :)

i will put my patch into svn which should be the best solution right now. and in trunk we might make this configureable..

the big problem here is that asterisk does only *know* cause 17 = busy, that's the only one which can be used to make the dialplan know about something different then "normal call clearing"..

so what we really might need is a way to tell asterisk that the call has ended, but we don't want to "hang it up" right now.  That only works with busy at the moment..

i would suggest to have something like:

ast_queue_control(ast, AST_CONTROL_LEAVE_DIAL_WITHOUT_HANGUP)
By: crich (crich) 2007-03-27 10:00:08

I've added my patch to svn (1.2 and 1.4) revision: 59254.
By: Gary Hawkins (garyhawkins01) 2007-03-27 13:32:57

crich: Thank you -- your patch works fine for me, revision 59256.  The 1.4 tree is now back to normal :-)
By: crich (crich) 2007-06-06 03:43:21

resolved in 1.4 branch