## Transfer causes hangup

Chorca · August 14, 2007, 7:22pm

Hey everyone. I just redid our asterisk box with a fresh install of Debian Etch and the latest version of asterisk (1.4.10.1) I downlaoded RC1 here, and everything seems to be working properly.

I found, however, that i am not able to do transfers via the ## method. I test this by placing a call between two phones internally, then attempting to do a transfer. I get the “Transfer” prompt, enter the extension, the phone hangs up like it should, but unfortunately, so does the other phone!

I looked through the logs here, and i can’t see much that might be causing it, so i’m going to post the offending portion. I’m not sure that it’s supposed to be jumping out of the dial macro, it just dumps the call and you’re left with a disconnected call on the other end. using the transfer button on the phone appears to work fine, however.

The following is the result of Ext. 300 calling Ext. 1002, who then attempts to transfer the call to Ext. 1004:

[quote][Aug 14 14:40:06] VERBOSE[4991] logger.c: – Executing [s@macro-dial:10] Dial(“SIP/300-0822b890”, “SIP/1002|12|tr”) in new stack
[Aug 14 14:40:06] VERBOSE[4991] logger.c: – Called 1002
[Aug 14 14:40:06] VERBOSE[4991] logger.c: – SIP/1002-082613d0 is ringing
[Aug 14 14:40:07] VERBOSE[2252] logger.c: RTCP SR transmission error, rtcp halted
[Aug 14 14:40:07] VERBOSE[4991] logger.c: – SIP/1002-082613d0 answered SIP/300-0822b890
[Aug 14 14:40:07] VERBOSE[4991] logger.c: – fixed jitterbuffer created on channel SIP/1002-082613d0
[Aug 14 14:40:07] VERBOSE[4991] logger.c: – fixed jitterbuffer created on channel SIP/300-0822b890
[Aug 14 14:40:12] VERBOSE[4991] logger.c: – Started music on hold, class ‘default’, on SIP/300-0822b890
[Aug 14 14:40:12] VERBOSE[4991] logger.c: – <SIP/1002-082613d0> Playing ‘pbx-transfer’ (language ‘en’)
[Aug 14 14:40:12] VERBOSE[2252] logger.c: RTCP SR transmission error, rtcp halted
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Stopped music on hold on SIP/300-0822b890
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Transferring SIP/300-0822b890 to ‘1004’ (context from-internal-xfer) priority 1
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – fixed jitterbuffer destroyed on channel SIP/1002-082613d0
[Aug 14 14:40:16] DEBUG[4991] app_macro.c: Executed application: Dial
[Aug 14 14:40:16] VERBOSE[4991] logger.c: == Channel ‘SIP/300-0822b890’ jumping out of macro ‘dial’
[Aug 14 14:40:16] DEBUG[4991] app_macro.c: Executed application: Macro
[Aug 14 14:40:16] VERBOSE[4991] logger.c: == Channel ‘SIP/300-0822b890’ jumping out of macro ‘exten-vm’
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Executing [h@from-internal-xfer:1] Macro(“SIP/300-0822b890”, “hangupcall”) in new stack
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Executing [s@macro-hangupcall:1] ResetCDR(“SIP/300-0822b890”, “w”) in new stack
[Aug 14 14:40:16] DEBUG[4991] cdr_addon_mysql.c: cdr_mysql: inserting a CDR record.
[Aug 14 14:40:16] DEBUG[4991] 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 (‘2007-08-14 14:40:06’,’“test” <300>’,‘300’,‘1002’,‘from-internal’, ‘SIP/300-0822b890’,‘SIP/1002-082613d0’,‘Dial’,‘SIP/1002|12|tr’,10,9,‘ANSWERED’,3,’’)
[Aug 14 14:40:16] DEBUG[4991] app_macro.c: Executed application: ResetCDR
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Executing [s@macro-hangupcall:2] NoCDR(“SIP/300-0822b890”, “”) in new stack
[Aug 14 14:40:16] DEBUG[4991] app_macro.c: Executed application: NoCDR
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Executing [s@macro-hangupcall:3] GotoIf(“SIP/300-0822b890”, “1?skiprg”) in new stack
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Goto (macro-hangupcall,s,6)
[Aug 14 14:40:16] DEBUG[4991] app_macro.c: Executed application: GotoIf
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Executing [s@macro-hangupcall:6] GotoIf(“SIP/300-0822b890”, “1?skipblkvm”) in new stack
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Goto (macro-hangupcall,s,9)
[Aug 14 14:40:16] DEBUG[4991] app_macro.c: Executed application: GotoIf
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Executing [s@macro-hangupcall:9] GotoIf(“SIP/300-0822b890”, “1?theend”) in new stack
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Goto (macro-hangupcall,s,11)
[Aug 14 14:40:16] DEBUG[4991] app_macro.c: Executed application: GotoIf
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – Executing [s@macro-hangupcall:11] Hangup(“SIP/300-0822b890”, “”) in new stack
[Aug 14 14:40:16] VERBOSE[4991] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘SIP/300-0822b890’ in macro ‘hangupcall’
[Aug 14 14:40:16] VERBOSE[4991] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘SIP/300-0822b890’
[Aug 14 14:40:16] VERBOSE[4991] logger.c: – fixed jitterbuffer destroyed on channel SIP/300-0822b890[/quote]

As i said… i’m really not too sure what’s going on here, i checked the logs from doing a phone button transfer and it seems to go into the macros just fine, so i’m stumped. Any insight?

plindheimer · August 14, 2007, 7:58pm

a cli trace may be more useful here.

Chorca · August 14, 2007, 8:37pm

Well this certainly sounds stupid. I just spent the last half hour trying to find how to get a CLI trace, but it seems noone asks that question. I guess i’ll have to. How would i go about getting a CLI trace? I can’t seem to get the text from the CLI into a readable file.

Chorca · August 14, 2007, 8:38pm

Ah what the heck. it’s semi-readable.

[quote]
== Parsing ‘/etc/asterisk/asterisk.conf’: Found
== Parsing ‘/etc/asterisk/extconfig.conf’: Found
Connected to Asterisk 1.4.10.1 currently running on asttest (pid = 2141)
asttestCLI>
Verbosity is at least 20
e[KasttestCLI>
– Executing [1002@from-internal:1] e[1;36;40mMacroe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mexten-vm|1002|1002e[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:1] e[1;36;40mMacroe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40muser-calleride[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:1] e[1;36;40mNoOpe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40muser-callerid: device 300e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:2] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mAMPUSER=300e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:3] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m0?reporte[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:4] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m0?starte[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:5] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mREALCALLERIDNUM=300e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:6] e[1;36;40mNoOpe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mREALCALLERIDNUM is 300e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:7] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mAMPUSER=300e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:8] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mAMPUSERCIDNAME=teste[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:9] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m0?reporte[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:10] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mAMPUSERCID=300e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:11] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mCALLERID(all)=“test” <300>e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:12] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mREALCALLERIDNUM=300e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:13] e[1;36;40mNoOpe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mTTL: ARG1: 1002e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:14] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m0?continuee[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:15] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m__TTL=64e[0;37;40m”) in new stack
– Executing [s@macro-user-callerid:16] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m1?continuee[0;37;40m”) in new stack
– Goto (macro-user-callerid,s,23)
– Executing [s@macro-user-callerid:23] e[1;36;40mNoOpe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mUsing CallerID “test” <300>e[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:2] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mFROMCONTEXT=exten-vme[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:3] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mVMBOX=1002e[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:4] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mEXTTOCALL=1002e[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:5] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mCFUEXT=e[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:6] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mCFBEXT=e[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:7] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mRT=12e[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:8] e[1;36;40mMacroe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mrecord-enable|1002|INe[0;37;40m”) in new stack
– Executing [s@macro-record-enable:1] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m0?2:4e[0;37;40m”) in new stack
– Goto (macro-record-enable,s,4)
– Executing [s@macro-record-enable:4] e[1;36;40mDeadAGIe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mrecordingcheck|20070814-162652|1187123212.540e[0;37;40m”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/recordingcheck
recordingcheck|20070814-162652|1187123212.540: Inbound recording not enabled
– AGI Script recordingcheck completed, returning 0
– Executing [s@macro-record-enable:5] e[1;36;40mNoOpe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mNo recording needede[0;37;40m”) in new stack
– Executing [s@macro-exten-vm:9] e[1;36;40mMacroe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mdial|12|tTr|1002e[0;37;40m”) in new stack
– Executing [s@macro-dial:1] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m1?diale[0;37;40m”) in new stack
– Goto (macro-dial,s,3)
– Executing [s@macro-dial:3] e[1;36;40mAGIe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mdialparties.agie[0;37;40m”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/dialparties.agi

e[Kasttest*CLI>
dialparties.agi: Starting New Dialparties.agi
== Parsing ‘/etc/asterisk/manager.conf’: Found
== Manager ‘admin’ logged on from 127.0.0.1
dialparties.agi: Caller ID name is ‘test’ number is '300’
dialparties.agi: USE_CONFIRMATION: 'FALSE’
dialparties.agi: RINGGROUP_INDEX: ''
dialparties.agi: Methodology of ring is ‘none’
– dialparties.agi: Added extension 1002 to extension map
– dialparties.agi: Extension 1002 cf is disabled
– dialparties.agi: Extension 1002 do not disturb is disabled
> dialparties.agi: extnum 1002 has: cw: 1; hascfb: 0 [] hascfu: 0 []
> dialparties.agi: ExtensionState: 0

e[Kasttest*CLI>
– dialparties.agi: dbset CALLTRACE/1002 to 300
== Manager ‘admin’ logged off from 127.0.0.1
– AGI Script dialparties.agi completed, returning 0
– Executing [s@macro-dial:10] e[1;36;40mDiale[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mSIP/1002|12|tTre[0;37;40m”) in new stack
– Called 1002

e[Kasttest*CLI>
– SIP/1002-08286438 is ringing

e[Kasttest*CLI>
– SIP/1002-08286438 answered SIP/300-08261370

e[Kasttest*CLI>
– fixed jitterbuffer created on channel SIP/1002-08286438

e[Kasttest*CLI>
– fixed jitterbuffer created on channel SIP/300-08261370

e[Kasttest*CLI>
– Started music on hold, class ‘default’, on SIP/300-08261370
– <SIP/1002-08286438> Playing ‘pbx-transfer’ (language ‘en’)

e[Kasttest*CLI>
– Stopped music on hold on SIP/300-08261370

e[Kasttest*CLI>
– Transferring SIP/300-08261370 to ‘1004’ (context from-internal-xfer) priority 1
– fixed jitterbuffer destroyed on channel SIP/1002-08286438
== Channel ‘SIP/300-08261370’ jumping out of macro ‘dial’
== Channel ‘SIP/300-08261370’ jumping out of macro ‘exten-vm’
– Executing [h@from-internal-xfer:1] e[1;36;40mMacroe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mhangupcalle[0;37;40m”) in new stack
– Executing [s@macro-hangupcall:1] e[1;36;40mResetCDRe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40mwe[0;37;40m”) in new stack

e[Kasttest*CLI>
– Executing [s@macro-hangupcall:2] e[1;36;40mNoCDRe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40me[0;37;40m”) in new stack
– Executing [s@macro-hangupcall:3] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m1?skiprge[0;37;40m”) in new stack
– Goto (macro-hangupcall,s,6)
– Executing [s@macro-hangupcall:6] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m1?skipblkvme[0;37;40m”) in new stack
– Goto (macro-hangupcall,s,9)
– Executing [s@macro-hangupcall:9] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40m1?theende[0;37;40m”) in new stack
– Goto (macro-hangupcall,s,11)
– Executing [s@macro-hangupcall:11] e[1;36;40mHangupe[0;37;40m(“e[1;35;40mSIP/300-08261370e[0;37;40m”, “e[1;35;40me[0;37;40m”) in new stack
== Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘SIP/300-08261370’ in macro ‘hangupcall’
== Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘SIP/300-08261370’
– fixed jitterbuffer destroyed on channel SIP/300-08261370

e[Kasttest*CLI> [/quote]

plindheimer · August 14, 2007, 9:58pm

not a whole lot more there. Are you able to transfer with the transfer button on the phone (assuming it can generate a ‘sip transfer?’

Chorca · August 15, 2007, 1:46am

yes. The transfers work fine if you use the phone’s transfer button. We’ve got mostly Snom300’s, there’s a Grandstream GXP-2000 as well, they’re all able to transfer using their dedicated buttons and have it go through ok. The issue only happens when using the ## transfers. I’ve also tried transferring calls into the parking lot, and that works just fine using the ##70# sequence. The issue is going between extensions.

plindheimer · August 15, 2007, 2:35am

well it’s a bit drawing at straws, but maybe try changing features.conf to a single # for transferring and see if the same problem is there?

Chorca · August 15, 2007, 2:44am

I’ll give it a shot tomorrow morning when i go in and i’ll post what happens.

dirk · August 15, 2007, 7:57am

I’ve also got this issue, it’s not major as we dont plan on using ## anyway as the phones have their own transfer button that works, but it would be handy to use ## if we need to transfer a call off a non-sip handset.

This is a recent problem, the ## did work in the past, the only thing that’s changed is the version of asterisk and freepbx. Currently, I dont know which app is to blame, but I’ve recently upgraded to 1.4.10 and then 1.4.10.1 and I think the issue came into play around that time.

Chorca · August 15, 2007, 12:17pm

Naw, just tried changing it and it’s not working still.

Dirk, you may be on to something. I haven’t been upgrading small versions, mainly big leaps. I switch back and forth between a couple machines, so i can keep one running while the other is being installed and whatnot. It worked fine with asterisk 1.4.5 and freepbx beta1, so it’s kind of a leap to 1.4.10.1 and RC1. Though, if you noticed it happening without changing freepbx versions, maybe this is something to throw at the asterisk people and see if there’s any info there.

The reason we use it is because we have a couple phones without feature keys (like the Linksys SPA-901) that you have to use feature codes to transfer and do things with. The other issue is that doing a blind transfer to a parking lot using the phone’s transfer button will result in the transferring user not hearing which parking slot was used for the call, so they’re unable to tell the person which slot to pick up the call on.

rjenkinsgb · August 15, 2007, 1:18pm

For information, I had # transfer working fine on a customers site using asterisk/zaptel 1.2.x

I’ve just tried it on my test system which has Zaptel 1.4.4 & Asterisk 1.4.10 and it does not work.

The # key now goes to the ‘directory’ whether in a call or not. On the 1.2 system it gave Directory if not in a call & blind transfer if in a call.

On the other hand, the R (Recall) button works fine and allows attended transfers.

Chorca · August 15, 2007, 6:28pm

You can disable the directory from within Feature Codes in FreePBX, or change it to a different key there. You can also use features.conf to change the transfer to ## instead of just #.

plindheimer · August 15, 2007, 8:50pm

from what I’m reading, sounds like an Asterisk problem. As mentioned, disable ‘#’ in the feature codes so that FreePBX does not confuse any issues. Beyond that - it really is nothing more than the features.conf settings and those have not changed. So I would say with high confidence that the issue is in Asterisk.

I must say - you guys/gals who are all testing Asterisk 1.4 are doing a great service back to the Asterisk community. I see a lot of people struggling with their issues… I hope that Asterisk and the Digium crowd appreciate what the FreePBX community has been doing for them by the exposure we have provided to their new release…

Keep up the great work everyone!

jacknab · October 2, 2007, 1:34pm

I use ## to transfer calls, since my agents do not use sip phones, they are remote agents working from home using there land-line phone. Is there a way to set the timeout for the ## feature.

Honestly I would not like to have it time out I would like to have an option were they could press a number to have it then timeout and return to the customer. "Because since not using sip phone we are unable to place a caller on hold, this would place the caller on hold and play MOH for them.

compused · October 15, 2007, 11:08pm

Hi
Could it be a freepbx issue, rather than an asterisk issue?

I upgraded from 2.2.0rc3 to 2.3.0…thats when blind transfer stopped working

Changing the ## setting in features.conf to *81 made no difference

So downgraded to 2.2.3…still not working. I noticed the freepbx gui said I was (still) running 2.3.0 but it was the old gui (ie not the new 2.3.0 gui)

My next plan is to downgrad again to 2.2.0

Rgds
Michael Daly
Melbourne
Australia

plindheimer · October 15, 2007, 11:45pm

unlikely to be a FreePBX issue (but if it is, we are always happy to hear about it so we can fix it). Transfer requires two things. It needs to be set in features.conf and then then the dial options need to be set with t or T in the General settings so Asterisk knows to listen for the transfer request. Beyond that, it’s pretty much Asterisk handling it for you.

As far as downgrading, FreePBX doesn’t really know how to “downgrade.” So the database is still going to reflect the highest version you upgraded to and you may very likely get other issues that crop up. 2.3.0 is by far the most stable version that has been out. I would highly recommend reloading it. (Not that 2.2 was unstable, but there were many many bugs that were 2.2. or prior bugs that were fixed in 2.3 and never back ported to 2.2, and there are not current plans to do so at this time.)

Philippe Lindheimer - FreePBX Project Lead
http//freepbx.org - IRC #freepbx

compused · October 16, 2007, 12:55am

thanks for this response, and yes, there is at least one of the ‘other issues’

so I can go back to 2.3.0

I have the dial options set as directed

but the main issue is that ## stopped working immediately after the freepbx upgrade to 2.3.0, the CLI remains blank after:

(extension no. )

is dialed so maybe I should upgrade asterisk…am currently running asterisk version 1.2.13…should
freepbx 2.3.0 be compatible with 1.2.13 ?

does paid support fully cover asterisk as well as freepbx?

Michael Daly
Melbourne
Australia

compused · October 16, 2007, 5:42am

HI
I upgraded to 2.30 again, upgraded all modules this time, and pressed ## more rapidly ie less time in between the two #‘s, & this time its workin’

Also, I read in an Australain Whirlpool forum posting, that under the ‘general section’ in freepbx, to set:
Asterisk Outbound Dial command options: rW
(if there is a t there get rid of it )
But I did not have to change this!

Michael Daly
Melbourne
Australia

plindheimer · October 16, 2007, 7:03am

setting outbound dial commands r can be very bad, especially if you have any sort of digital trunks (VoIP, PRI, etc). You don’t want ‘r’ in almost all cases. As far as W, that’s just to enable the ability to record calls.

Philippe Lindheimer - FreePBX Project Lead
http//freepbx.org - IRC #freepbx

percykwong · October 18, 2007, 5:26am

I had the same problem tonight with 1.4.13. Seems I’m not the only one. I was hanging out in the #asterisk channel on irc and it seems to be a problem with 1.4.13. A downgrade to 1.4.12.1 and addons-1.4.3 did the trick… It’s all smooth and working again for me.