I have 2 problems with Asterisk + Cisco SPA 504G phones. Before posting this question, I’ve done my research, asked some questions, but I am not very good in “computer software, actually I have no knowledge at all”… Here’s the thing! Also, I used incrediblePBX 11 that includes Asterisk.
#1
When parking slots are full, and a user use Speed dial via the CISCO IP phone (I programmed one of the soft keys to park the calls:Key: fnc=sd;ext=70@10.0.1.103;nme=Park), the call will fail and it will automatically hangs up.
I found that someone who has the exact problem as me posted this at http://asterisk.inmte.com/viewtopic.php?p=91004&sid=202bf43a6e3ab98d6b8cacf2c2dcb4bb:
[quote]features.conf
parkext => 700
parkpos => 701-702
context => parkedcalls
On the Cisco phone, I programmed one of the soft keys to park the calls:
Key: fnc=sd;ext=700@10.0.1.103;vid=1;nme=Park
I can either press this key or dial #700 to park the call. Both work smoothly.
The problem happens when I try to park a call when the parking lot is full:
-
if I try to park it with dialing #700,I get a warning message saying that it can’t be done. The existing call (that I tried to park) stays on as intended. This is the desired behavior.
-
On the other hand, if I try to park it via using the Key (which sends a REFER), Asterisk responds with a SIP 503 message (which the phone processes correctly telling me that its an invalid transfer). However, the existing call is gone - both caller and callee’s phones show as if there is a call, but they are not connected to each other. There is no SIP BYE. Asterisk CLI says :
Spawn extension (callee) exited non-zero on ‘Parking\SIP\caller’…
Is there something that can be done not to lose the call?
I noticed that parking with dialing #700 and parking with the key button seem to be handled differently in the Asterisk code with different results in this case:
#700 goes thru xfer_park_call_helper and eventually masq_call_transfer in features.c.
Key method (REFER) goes thru sip_park_thread in chan_sip.c, ast_park_call_exten and park_call_full in features.c.[/quote]
The person says he solved the problem on his last post:
[quote]I noticed that there are two different ways to park a call in Asterisk:
masq_park_call and park_call_full in features.c
masq_park_call behaves exactly the way we want it - if there is no parking space left, it plays a failure message and hangs up the masqueraded chan keeping the original channels intact.
In the other way (which covers our case), this doesn’t happen.[/quote]
Now, because I am pretty new, how do we change the park_call_fullto masq_park_call in incrediblePBX? I am not sure how the other dude did it… I can’t even find the feature.conf file anywhere, and not sure how to edit it.
#2
Someone posted this, and I HAVE the exact same problem (only is my parkext is 70):
[quote]features.conf
parkext => 700
parkpos => 701-702
context => parkedcalls
I defined one of the unused keys to park the calls:
Key2:
fnc=sd;ext=700 at 10.0.1.103;vid=1;nme=Park
I also defined two other keys to pickup/unpark the calls:
Key3:
fnc=blf+sd+cp;sub=701 at 10.0.1.103
Key4:
fnc=blf+sd+cp;sub=702 at 10.0.1.103
Parking using these works smoothly.
I answer the incoming call, press Key2 to park the call. Call is parked, Key3 turns red showing there is a parked call.
If I want to unpark the call, I hit Key3 and the call is unparked.
My problem happens when Key3 and Key4 are idle (no parked calls): I answer the incoming call and without first parking the car, I hit one of the idle keys (Key3 or Key4), the phone sends a REFER message, and the incoming call hangs up.
I’m trying to find out why the call hangs up and how to prevent that? [/quote]
I posted the same question to the CISCO IP forum, but the developpers told me the problem is related to IncrediblePBX/Asterisk and not their phone, therefore asking me to post in this forum for help.
Would gradly appreciated if some food fellow/dev can help me out!! I am trying to solve this almost last problem, after giving up on key system, and learning on call parking until these problems occured. Maybe problems #1 and 2 are related?