Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Polycom VVX300 Call park and retrieval with FreePBX
- Thread starter raist3001
- Start date
curlycord
Programmer
This is from Yealink in 2015
You can't use the same button to park/retrieve a call when the code for them is not same.
To some pbx servers like freeswitch use a same park/retrieve code and you can configure a BLF to achieve it.
So question I would have does the FreePBX use the same codes.
This is what the user was trying to program
linekey.2.label="Park1"
linekey.2.line="0"
linekey.2.pickup_value ="*55701"
linekey.2.type="16"
linekey.2.value="701"
________________________________________
Add me to LinkedIN
=----(((((((((()----=
Toronto, CAN
You can't use the same button to park/retrieve a call when the code for them is not same.
To some pbx servers like freeswitch use a same park/retrieve code and you can configure a BLF to achieve it.
So question I would have does the FreePBX use the same codes.
This is what the user was trying to program
linekey.2.label="Park1"
linekey.2.line="0"
linekey.2.pickup_value ="*55701"
linekey.2.type="16"
linekey.2.value="701"
________________________________________
Add me to LinkedIN
=----(((((((((()----=
Toronto, CAN
- Thread starter
- #3
Wading through the tons of wiki documents on the Sangoma website, it appears that the Polycom needs to have one park button created which will send parked calls to the next available park location, and then you need to have multiple park retrieval buttons. So if a user has 3 parking spots, they need 4 buttons. One to park and 3 to retrieve from the locations. I've tested this, and it works. However, Others have said that I need to create a new parking lot in freepbx to have the same park numbers for retrieval but have not found any instructions on doing so. I believe that may be a function of Parking Pro with FreePBX?
curlycord
Programmer
it appears that the Polycom needs to have one park button created which will send parked calls to the next available park location"
This would be correct according to Polycom as well.
This is from the engineers at Polycom:
Hopefully something in here can help the guy but it will take some back and forth and a lot of trial and error
When BLF is used for a park orbit, the intent is for the "resource type" to be "automata". The "resource type" affects the behaviour when pressing the BLF key and a call is active either locally or at that resource.
Automata invokes park (ie: blind transfers using REFER) and pickup events (INVITE w/ replaces or by star code). Pickup attempts may occur on both ringing lines (flashing green) AND on an already confirmed line (solid red).
Normal resource type only performs directed call pickups on ringing lines and won't try to pickup, retrieve or intercept anything on an already confirmed line– if tried, you will instead place a normal call to that destination.
When a BLF is showing ringing state or confirmed state, your automata BLF will try one of 2 things:
If you have no current calls, touching the key tries to pickup
If you have an active call, touching the key tries to park the active call, even if the BLF shows that there is already something there
For the state of a park orbit, different vendors use different states. Originally, we only accepted the "early" (using RFC terminology) which is the same as ringing state. This is how Metaswitch and SipX do it. It seems that the Asterisk uses the confirmed state.
I am unsure when when it changed, but originally we could only perform a pickup on a ringing line and never on an acive line (as evidenced by the SPIP SW still on 4.0.x). I gave a quick test on UCS 5.4.5 and see that my VVX tried to send a INVITE w/ replaces to pickup while its BLF line showed active so somewhere along the line, we opened up our solution space a bit.
Now onto the mechanics. Legacy Star codes versus native SIP methods.
The guys capture and description in the forum implies asterisk is using both.
His park works and is using the native SIP REFER with a refer-to: 72@IPAddress
Notifications go out to all the phones in frames 1179-1181. IT is CRUCIAL to note that in that NOTIFY there is no target URI information or call-id and tag information. Without that data, the phone CANNOT construct an INVITE with Replaces and so we MUST use star codes to pickup the call
His pickup fails. I assume this is in frame 2825.
The phone is most likely still configured in its default mode and using native SIP for its actions and so in the absence of needed tag, call-id and target uri info for the resource it is monitoring does its best to do something… and all it can do is try to call that configured address at 72@IPADDRESS and thus pickup fails
Had we used configuration to manipulate the pickup method, we could have had it send something different based on our static configuration. We have some parameters that let us manipulate the mechanics of the signaling but it will take some tweaking on their part to fine tune it into a working setup.
Ideally Asterisk has some configuration to provide more info in the dialog NOTIFYs but I'm not familiar with Asterisk administration so I'll leave that alone for now.
I have an old BLF technical brief on this subject that you can read or share around. Its not a formal doc and so isn't posted on any web site.
If I had to take a pure guess at how to handle this I would suggest the following configuration:
other related params we aren't using:
call.directedCallPickupString="xxx" -> We use this parameter for when retrieving from a call in early state (flashing green). Asterisk seems to be using the "confirmed" state for park so I don't think we need use this parameter. If in doubt, set to "*2" as well
for interest sake, here's what a complete BLF dialog notify should look like with all relevant fields:
And here is what the asterisk is sending. Not much to work with!
Message Body
End
Seems to be a dead horse with Polycom for some reason but their forum master suggests to call an authorized Polycom vendor to put in a request....however this has been done and still nothing.
Posting on the actual Asterisk forum might help if Polycom is not budging on this to see if somebody has found a work around.
Outta Ammo!
________________________________________
Add me to LinkedIN
=----(((((((((()----=
Toronto, CAN
This would be correct according to Polycom as well.
This is from the engineers at Polycom:
Hopefully something in here can help the guy but it will take some back and forth and a lot of trial and error
When BLF is used for a park orbit, the intent is for the "resource type" to be "automata". The "resource type" affects the behaviour when pressing the BLF key and a call is active either locally or at that resource.
Automata invokes park (ie: blind transfers using REFER) and pickup events (INVITE w/ replaces or by star code). Pickup attempts may occur on both ringing lines (flashing green) AND on an already confirmed line (solid red).
Normal resource type only performs directed call pickups on ringing lines and won't try to pickup, retrieve or intercept anything on an already confirmed line– if tried, you will instead place a normal call to that destination.
When a BLF is showing ringing state or confirmed state, your automata BLF will try one of 2 things:
If you have no current calls, touching the key tries to pickup
If you have an active call, touching the key tries to park the active call, even if the BLF shows that there is already something there
For the state of a park orbit, different vendors use different states. Originally, we only accepted the "early" (using RFC terminology) which is the same as ringing state. This is how Metaswitch and SipX do it. It seems that the Asterisk uses the confirmed state.
I am unsure when when it changed, but originally we could only perform a pickup on a ringing line and never on an acive line (as evidenced by the SPIP SW still on 4.0.x). I gave a quick test on UCS 5.4.5 and see that my VVX tried to send a INVITE w/ replaces to pickup while its BLF line showed active so somewhere along the line, we opened up our solution space a bit.
Now onto the mechanics. Legacy Star codes versus native SIP methods.
The guys capture and description in the forum implies asterisk is using both.
His park works and is using the native SIP REFER with a refer-to: 72@IPAddress
Notifications go out to all the phones in frames 1179-1181. IT is CRUCIAL to note that in that NOTIFY there is no target URI information or call-id and tag information. Without that data, the phone CANNOT construct an INVITE with Replaces and so we MUST use star codes to pickup the call
His pickup fails. I assume this is in frame 2825.
The phone is most likely still configured in its default mode and using native SIP for its actions and so in the absence of needed tag, call-id and target uri info for the resource it is monitoring does its best to do something… and all it can do is try to call that configured address at 72@IPADDRESS and thus pickup fails
Had we used configuration to manipulate the pickup method, we could have had it send something different based on our static configuration. We have some parameters that let us manipulate the mechanics of the signaling but it will take some tweaking on their part to fine tune it into a working setup.
Ideally Asterisk has some configuration to provide more info in the dialog NOTIFYs but I'm not familiar with Asterisk administration so I'll leave that alone for now.
I have an old BLF technical brief on this subject that you can read or share around. Its not a formal doc and so isn't posted on any web site.
If I had to take a pure guess at how to handle this I would suggest the following configuration:
Code:
call.parkedCallRetrieveMethod="legacy"
call.parkedCallRetrieveString="*2" -> this is the string we send when the call is in "confirmed" state (solid red)
voipPort.SIP.useCompleteUriForRetrieve="0"
voIpProt.SIP.useLocalTargetUriforLegacyPickup="0"
voIpProt.SIP.strictReplacesHeader="0"call.directedCallPickupString="xxx" -> We use this parameter for when retrieving from a call in early state (flashing green). Asterisk seems to be using the "confirmed" state for park so I don't think we need use this parameter. If in doubt, set to "*2" as well
for interest sake, here's what a complete BLF dialog notify should look like with all relevant fields:
Code:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="9" state="partial" entity="sip:3339951742@as-dev.vancouver.polycom.com">
<dialog id="id03d1667c" call-id="BW121335770060117130519749@172.24.31.180" local-tag="C4ACD189-342D66F0" remote-tag="2016120192-1483733615770-" direction="recipient">
<state>confirmed</state>
<local>
<identity display="Brad Marusiak 1742">sip:3339951742@as-dev.vancouver.polycom.com</identity>
<target uri="sip:1742@10.242.16.28">
<param pname="x-line-id" pval="0" />
</target>
</local>
<remote>
<identity display="Brad Marusiak 1741">sip:3339951741@as-dev.vancouver.polycom.com</identity>
<target uri="sip:1741@as-dev.vancouver.polycom.com">
</target>
</remote>
</dialog>
</dialog-info>And here is what the asterisk is sending. Not much to work with!
Message Body
Code:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="34" state="full" entity="sip:72@192.168.106.254">
<dialog id="72">
<state>confirmed</state>
</dialog>
</dialog-info>Seems to be a dead horse with Polycom for some reason but their forum master suggests to call an authorized Polycom vendor to put in a request....however this has been done and still nothing.
Posting on the actual Asterisk forum might help if Polycom is not budging on this to see if somebody has found a work around.
Outta Ammo!
________________________________________
Add me to LinkedIN
=----(((((((((()----=
Toronto, CAN
- Status
Similar threads
- Locked
- Question
- Question