Pressing * during a call over SIP or IAX trunk terminates it

Hello - newbie to this forum but been using Asterisk for some time - beaten this time though!

Using A@H 2.8 as a starting point, (Asterisk 1.2.7.1 / Zaptel 1.0.5) I have upgraded to Asterisk 1.2.11, Zaptel 1.0.8 and Libpri 1.2.3.

All seems to work as expected, but during a call placed via a SIP or IAX trunk (either to another Asterisk (IAX) or an analogue gateway (SIP)) if * is pressed all voice traffic ceases. The call still stays active. Data is still passing over the LAN (ie lights on switch flash). Server utilisation goes up to 100% until the call is ended - then returns to normal.

I have tested with recording on / off / on demand - always the same.

asterisk -r doesn’t give anything helpful, even with sip debugging on.

/var/log/asterisk/full shows the following, in this case over a SIP trunk, at the point when * is pressed on the phone:

channel.c: Got DTMF on channel (SIP/208-092182e8)
Sep 1 13:52:34 DEBUG[7140] channel.c: Bridge stops bridging channels SIP/208-092182e8 and SIP/clipcomm-0922e7b0
Sep 1 13:52:34 DEBUG[7140] res_features.c: Feature interpret: chan=SIP/208-092182e8, peer=SIP/clipcomm-0922e7b0, sense=1, features=16
Sep 1 13:52:34 DEBUG[7140] res_features.c: Set time limit to 500
Sep 1 13:52:34 VERBOSE[7140] logger.c: – Attempting native bridge of SIP/208-092182e8 and SIP/clipcomm-0922e7b0
Sep 1 13:52:34 DEBUG[7140] channel.c: Nobody there, continuing…

… “Dead air” on the phone at this point, through to hanging up the phone…

Sep 1 13:52:55 DEBUG[7140] channel.c: Bridge stops because we’re zombie or need a soft hangup: c0=SIP/208-092182e8, c1=SIP/clipcomm-0922e7b0, flags: No,Yes,No,No
Sep 1 13:52:55 DEBUG[7140] channel.c: Bridge stops bridging channels SIP/208-092182e8 and SIP/clipcomm-0922e7b0
Sep 1 13:52:55 DEBUG[7140] res_features.c: Timed out for feature!
Sep 1 13:52:55 WARNING[7140] res_features.c: Bridge failed on channels SIP/208-092182e8 and SIP/clipcomm-0922e7b0
Sep 1 13:52:55 DEBUG[7140] chan_sip.c: update_call_counter(1471) - decrement call limit counter
Sep 1 13:52:55 DEBUG[7140] app_dial.c: Exiting with DIALSTATUS=ANSWER.
Sep 1 13:52:55 VERBOSE[7140] logger.c: == Spawn extension (macro-dialout-trunk, s, 14) exited non-zero on ‘SIP/208-092182e8’ in macro ‘dialout-trunk’
Sep 1 13:52:55 VERBOSE[7140] logger.c: == Spawn extension (macro-dialout-trunk, s, 14) exited non-zero on ‘SIP/208-092182e8’
Sep 1 13:52:55 DEBUG[7140] cdr_addon_mysql.c: cdr_mysql: inserting a CDR record.
Sep 1 13:52:55 DEBUG[7140] cdr_addon_mysql.c: cdr_mysql: SQL command as follows: INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode) VALUES (‘2006-09-01 13:52:28’,’“Polycom IP300” <208>’,‘208’,‘41471’,‘from-internal’, ‘SIP/208-092182e8’,‘SIP/clipcomm-0922e7b0’,‘Dial’,‘SIP/clipcomm/1471|120|W’,27,27,‘ANSWERED’,3,’’)
Sep 1 13:52:55 DEBUG[7140] chan_sip.c: update_call_counter(208) - decrement call limit counter

Via an IAX trunk it is slightly different:

Sep 1 14:14:27 VERBOSE[7203] logger.c: – Called iaxoutone/01xxxxxxxxx
Sep 1 14:14:27 VERBOSE[2761] logger.c: – Call accepted by xxx.xxx.xxx.xxx (format ulaw)
Sep 1 14:14:27 VERBOSE[2761] logger.c: – Format for call is ulaw
Sep 1 14:14:29 VERBOSE[7203] logger.c: – IAX2/iaxoutone-1 is ringing
Sep 1 14:14:29 DEBUG[7203] channel.c: Driver for channel ‘SIP/208-0920fc28’ does not support indication 3, emulating it
Sep 1 14:14:29 DEBUG[7203] channel.c: Prodding channel 'SIP/208-0920fc28’
Sep 1 14:14:29 DEBUG[7203] channel.c: Scheduling timer at 160 sample intervals
Sep 1 14:14:29 VERBOSE[7203] logger.c: – IAX2/iaxoutone-1 is making progress passing it to SIP/208-0920fc28
Sep 1 14:14:29 DEBUG[2761] chan_iax2.c: Ooh, voice format changed to 4
Sep 1 14:14:29 DEBUG[7203] channel.c: Scheduling timer at 0 sample intervals
Sep 1 14:14:42 VERBOSE[7203] logger.c: – IAX2/iaxoutone-1 stopped sounds
Sep 1 14:14:42 VERBOSE[7203] logger.c: – IAX2/iaxoutone-1 answered SIP/208-0920fc28
Sep 1 14:14:42 DEBUG[2763] chan_sip.c: Stopping retransmission on ‘919ef401-827280d3-8c286928@10.0.0.20’ of Response 2: Match Found
Sep 1 14:14:44 DEBUG[7203] channel.c: Got DTMF on channel (SIP/208-0920fc28)
Sep 1 14:14:44 DEBUG[7203] channel.c: Bridge stops bridging channels SIP/208-0920fc28 and IAX2/iaxoutone-1
Sep 1 14:14:44 DEBUG[7203] res_features.c: Feature interpret: chan=SIP/208-0920fc28, peer=IAX2/iaxoutone-1, sense=1, features=16
Sep 1 14:14:44 DEBUG[7203] res_features.c: Set time limit to 500
Sep 1 14:14:44 DEBUG[7203] channel.c: Nobody there, continuing…
Sep 1 14:14:46 DEBUG[2761] channel.c: Dropping voice to exceptionally long queue on IAX2/iaxoutone-1

…at which point the last line above is repeated contiunuously until I end the call at which point the log says:

Sep 1 14:14:49 DEBUG[7203] channel.c: Bridge stops because we’re zombie or need a soft hangup: c0=SIP/208-0920fc28, c1=IAX2/iaxoutone-1, flags: No,Yes,No,No
Sep 1 14:14:49 DEBUG[7203] channel.c: Bridge stops bridging channels SIP/208-0920fc28 and IAX2/iaxoutone-1
Sep 1 14:14:49 DEBUG[7203] res_features.c: Timed out for feature!
Sep 1 14:14:49 WARNING[7203] res_features.c: Bridge failed on channels SIP/208-0920fc28 and IAX2/iaxoutone-1
Sep 1 14:14:49 DEBUG[7203] chan_iax2.c: We’re hanging up IAX2/iaxoutone-1 now…
Sep 1 14:14:49 VERBOSE[7203] logger.c: – Hungup 'IAX2/iaxoutone-1’
Sep 1 14:14:49 DEBUG[7203] app_dial.c: Exiting with DIALSTATUS=ANSWER.

I reverted my system back to 1.2.7.1 etc and this issue doesn’t happen.

Sorry this is a long and messy post but does anyone have any ideas? I know I have a working system with the previous version, so I am able to rule out many potential factors and none of the configuration is changed during the upgrade (as far as I can tell)

Many thanks,

Alan

Update to previous post;

I have commented out as follows:

[featuremap]
; automon => *1 ; One Touch Record

…from features.conf

It seems as though there is a timeout/lock/loop after the * is pressed which I will investigate further.

Strange as features.conf has not changed from the basis A@H 2.8 - I have just compared it with an un-upgraded system.

Alan

Carnegi,

Did you ever resolve this problem? My version of * does the same thing, but I need the automon and blindxfer features enabled, so I can’t just comment them out.

are you specifying a featuredigittimeout in features.conf ?

Yes, but after doing some research I see that this is a known bug with my version of *. It’s been fixed in the final version of both 1.2 path and 1.4.

See here: bugs.digium.com/view.php?id=7982