Remote pickup of on-hold extensions
Hi all, I have a scenario that I'm thinking of implementing, but not sure if it's possible, so here's the details: Extensions 200 to 250 are regular internal sip phones, contained in a call group (Ext 1000) Extensions 300 to 305 are SIP-GSM and SIP-PSTN gateways with SIP client firmware, namely those cheap GOIP GSM units on ebay, plus an SPA3000. These are to be configured with the logon credentials of the extension and behave as a typical SIP client. The dialplan will route incoming and outgoing calls via these gateways as if they were trunks. They will restricted privileges to prevent toll fraud. The phones will either be Yealink T28p or Grandstream GXP2124, it depends if GS can respond with a fix for their horrible AGC or not. The gateways will be subscribed to the phone's DSS keys as BLF's. Now, all this so far is reasonably straight forward. The next part is the tricky part (you might've guessed where this is going....) Let's say a call comes in on 300, routes to the call group and is picked up by 1000, who then puts the call on hold. The BLF key for 300 shows it as busy/on hold. 1000 then calls 1001 to take the call. 1001 then presses BLF 300, which causes the call to be transferred to them and automatically answered. So is there any way in freeswitch to replicate this behavior? I know it's possible to do SAA, but this gets tricky if I want to have time based call groups, or to share incoming lines between branches. The method above allows the lines to be present on all phones, while still configuring call groups in the usual way and more or less replicating old key system behavior. Cheers, Francis
Personally I'd just use the Blind Transfer features on your handsets. 1000 picks up the call, presses transfer on the phone, then dials 1001 and hangs up. 1001 rings and is connected to the transferred call. Sure you'e not got the BLF, but the idea works fine. You could use call parking, but that has more steps to it. On 2 November 2012 04:16, <sms@icefire.qza.net.au> wrote:
Hi all,
I have a scenario that I'm thinking of implementing, but not sure if it's possible, so here's the details:
Extensions 200 to 250 are regular internal sip phones, contained in a call group (Ext 1000)
Extensions 300 to 305 are SIP-GSM and SIP-PSTN gateways with SIP client firmware, namely those cheap GOIP GSM units on ebay, plus an SPA3000. These are to be configured with the logon credentials of the extension and behave as a typical SIP client.
The dialplan will route incoming and outgoing calls via these gateways as if they were trunks. They will restricted privileges to prevent toll fraud. The phones will either be Yealink T28p or Grandstream GXP2124, it depends if GS can respond with a fix for their horrible AGC or not. The gateways will be subscribed to the phone's DSS keys as BLF's.
Now, all this so far is reasonably straight forward. The next part is the tricky part (you might've guessed where this is going....)
Let's say a call comes in on 300, routes to the call group and is picked up by 1000, who then puts the call on hold. The BLF key for 300 shows it as busy/on hold. 1000 then calls 1001 to take the call. 1001 then presses BLF 300, which causes the call to be transferred to them and automatically answered.
So is there any way in freeswitch to replicate this behavior? I know it's possible to do SAA, but this gets tricky if I want to have time based call groups, or to share incoming lines between branches. The method above allows the lines to be present on all phones, while still configuring call groups in the usual way and more or less replicating old key system behavior.
Cheers, Francis
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
I've thought about those options... the obstacle is mostly the users, who aren't the most trainable people in the world, and they're used to the present key system which allows them to have pretty colored buttons that they only press once. I dread the attempt to explain the concept of transferring a call, and the question will inevitably come back: "Why can't we have line keys like the last system?" Calls will likely get lost or dropped, and of course, the system gets blamed ;-) The other option, again if possible, is to program a soft key as a one-touch "Park" key that announces the park extension number, which could also be assigned to a BLF, then parks the call. Then we have one touch park, one touch retrieve. I have to sell this to them in such a way that it doesn't come across as a feature downgrade, or we may end up stuck with the present system until it dies and no inter-branch connectivity. I suppose it's the same old predicament... things would be so simple if management just said yes :)
Personally I'd just use the Blind Transfer features on your handsets. 1000 picks up the call, presses transfer on the phone, then dials 1001 and hangs up. 1001 rings and is connected to the transferred call. Sure you'e not got the BLF, but the idea works fine. You could use call parking, but that has more steps to it.
On 2 November 2012 04:16, <sms@icefire.qza.net.au> wrote:
Hi all,
I have a scenario that I'm thinking of implementing, but not sure if it's possible, so here's the details:
Extensions 200 to 250 are regular internal sip phones, contained in a call group (Ext 1000)
Extensions 300 to 305 are SIP-GSM and SIP-PSTN gateways with SIP client firmware, namely those cheap GOIP GSM units on ebay, plus an SPA3000. These are to be configured with the logon credentials of the extension and behave as a typical SIP client.
The dialplan will route incoming and outgoing calls via these gateways as if they were trunks. They will restricted privileges to prevent toll fraud. The phones will either be Yealink T28p or Grandstream GXP2124, it depends if GS can respond with a fix for their horrible AGC or not. The gateways will be subscribed to the phone's DSS keys as BLF's.
Now, all this so far is reasonably straight forward. The next part is the tricky part (you might've guessed where this is going....)
Let's say a call comes in on 300, routes to the call group and is picked up by 1000, who then puts the call on hold. The BLF key for 300 shows it as busy/on hold. 1000 then calls 1001 to take the call. 1001 then presses BLF 300, which causes the call to be transferred to them and automatically answered.
So is there any way in freeswitch to replicate this behavior? I know it's possible to do SAA, but this gets tricky if I want to have time based call groups, or to share incoming lines between branches. The method above allows the lines to be present on all phones, while still configuring call groups in the usual way and more or less replicating old key system behavior.
Cheers, Francis
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director
*T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
You can one-touch park using the valet_park application, and you set up your BLF keys to monitor/park/unpark calls on the parking extesions. For example, for a 10 slot (700 to 709) lot you'd have: <extension name="parkinglot"> <condition field="destination_number" expression="^(park+)?(70\d)$"> <action application="valet_park" data="lot $1" /> </condition> </extension> Then set you BLF keys to monitor/dial park+700 to park+709 and if your handsets support it properly and are configured correctly, just pressing one of the free line keys should park the call in that slot, and illuminate the LED. You can also dial 700-709 directly, if you wanted to. Is that a bit closer? On 3 November 2012 10:46, <sms@icefire.qza.net.au> wrote:
I've thought about those options... the obstacle is mostly the users, who aren't the most trainable people in the world, and they're used to the present key system which allows them to have pretty colored buttons that they only press once. I dread the attempt to explain the concept of transferring a call, and the question will inevitably come back: "Why can't we have line keys like the last system?" Calls will likely get lost or dropped, and of course, the system gets blamed ;-)
The other option, again if possible, is to program a soft key as a one-touch "Park" key that announces the park extension number, which could also be assigned to a BLF, then parks the call. Then we have one touch park, one touch retrieve.
I have to sell this to them in such a way that it doesn't come across as a feature downgrade, or we may end up stuck with the present system until it dies and no inter-branch connectivity.
I suppose it's the same old predicament... things would be so simple if management just said yes :)
Personally I'd just use the Blind Transfer features on your handsets. 1000 picks up the call, presses transfer on the phone, then dials 1001 and hangs up. 1001 rings and is connected to the transferred call. Sure you'e not got the BLF, but the idea works fine. You could use call parking, but that has more steps to it.
On 2 November 2012 04:16, <sms@icefire.qza.net.au> wrote:
Hi all,
I have a scenario that I'm thinking of implementing, but not sure if it's possible, so here's the details:
Extensions 200 to 250 are regular internal sip phones, contained in a call group (Ext 1000)
Extensions 300 to 305 are SIP-GSM and SIP-PSTN gateways with SIP client firmware, namely those cheap GOIP GSM units on ebay, plus an SPA3000. These are to be configured with the logon credentials of the extension and behave as a typical SIP client.
The dialplan will route incoming and outgoing calls via these gateways as if they were trunks. They will restricted privileges to prevent toll fraud. The phones will either be Yealink T28p or Grandstream GXP2124, it depends if GS can respond with a fix for their horrible AGC or not. The gateways will be subscribed to the phone's DSS keys as BLF's.
Now, all this so far is reasonably straight forward. The next part is the tricky part (you might've guessed where this is going....)
Let's say a call comes in on 300, routes to the call group and is picked up by 1000, who then puts the call on hold. The BLF key for 300 shows it as busy/on hold. 1000 then calls 1001 to take the call. 1001 then presses BLF 300, which causes the call to be transferred to them and automatically answered.
So is there any way in freeswitch to replicate this behavior? I know it's possible to do SAA, but this gets tricky if I want to have time based call groups, or to share incoming lines between branches. The method above allows the lines to be present on all phones, while still configuring call groups in the usual way and more or less replicating old key system behavior.
Cheers, Francis
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director
*T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
On 05.11.2012 17:57, Andrew Cassidy wrote:
You can one-touch park using the valet_park application, and you set up your BLF keys to monitor/park/unpark calls on the parking extesions.
For example, for a 10 slot (700 to 709) lot you'd have:
<extension name="parkinglot"> <condition field="destination_number" expression="^(park+)?(70\d)$"> <action application="valet_park" data="lot $1" /> </condition> </extension>
Then set you BLF keys to monitor/dial park+700 to park+709 and if your handsets support it properly and are configured correctly, just pressing one of the free line keys should park the call in that slot, and illuminate the LED.
You can also dial 700-709 directly, if you wanted to.
Is that a bit closer?
Recently I've thought and read about this. The callcenter which I implement will have some other users which want (as on old system phones) to see on the phone a LED blinking when other line is ringing. But I understood that LED call presence is not fully implemented in FS. Is it so? Or it depends on the phone? -- Mimiko desu.
Certainly is! Thanks, I'll give this a go. I'm going to have a shot at configuring GSM_OPEN later this week so hopefully I'll have a success to report back. I've purchased the two freeswitch books and I'm slowly inching through them. I'll try reproducing my first scenario when I've digested enough information. The primary difference I see between key system behavior and SAA/BLA/Park is that in a KS, the line always has the same address (line 1, line 2 etc) regardless of call state or ring assignments. The latter configurations overcome the difficulty of managing large numbers of calls/channels, at the expense of the former, this makes sense for large systems. I'm liking freeswitch so far, it seems a whole lot more configurable than Asterisk.
You can one-touch park using the valet_park application, and you set up your BLF keys to monitor/park/unpark calls on the parking extesions.
For example, for a 10 slot (700 to 709) lot you'd have:
<extension name="parkinglot"> <condition field="destination_number" expression="^(park+)?(70\d)$"> <action application="valet_park" data="lot $1" /> </condition> </extension>
Then set you BLF keys to monitor/dial park+700 to park+709 and if your handsets support it properly and are configured correctly, just pressing one of the free line keys should park the call in that slot, and illuminate the LED.
You can also dial 700-709 directly, if you wanted to.
Is that a bit closer?
On 3 November 2012 10:46, <sms@icefire.qza.net.au> wrote:
I've thought about those options... the obstacle is mostly the users, who aren't the most trainable people in the world, and they're used to the present key system which allows them to have pretty colored buttons that they only press once. I dread the attempt to explain the concept of transferring a call, and the question will inevitably come back: "Why can't we have line keys like the last system?" Calls will likely get lost or dropped, and of course, the system gets blamed ;-)
The other option, again if possible, is to program a soft key as a one-touch "Park" key that announces the park extension number, which could also be assigned to a BLF, then parks the call. Then we have one touch park, one touch retrieve.
I have to sell this to them in such a way that it doesn't come across as a feature downgrade, or we may end up stuck with the present system until it dies and no inter-branch connectivity.
I suppose it's the same old predicament... things would be so simple if management just said yes :)
Personally I'd just use the Blind Transfer features on your handsets. 1000 picks up the call, presses transfer on the phone, then dials 1001 and hangs up. 1001 rings and is connected to the transferred call. Sure you'e not got the BLF, but the idea works fine. You could use call parking, but that has more steps to it.
On 2 November 2012 04:16, <sms@icefire.qza.net.au> wrote:
Hi all,
I have a scenario that I'm thinking of implementing, but not sure if it's possible, so here's the details:
Extensions 200 to 250 are regular internal sip phones, contained in a call group (Ext 1000)
Extensions 300 to 305 are SIP-GSM and SIP-PSTN gateways with SIP client firmware, namely those cheap GOIP GSM units on ebay, plus an SPA3000. These are to be configured with the logon credentials of the extension and behave as a typical SIP client.
The dialplan will route incoming and outgoing calls via these gateways as if they were trunks. They will restricted privileges to prevent toll fraud. The phones will either be Yealink T28p or Grandstream GXP2124, it depends if GS can respond with a fix for their horrible AGC or not. The gateways will be subscribed to the phone's DSS keys as BLF's.
Now, all this so far is reasonably straight forward. The next part is the tricky part (you might've guessed where this is going....)
Let's say a call comes in on 300, routes to the call group and is picked up by 1000, who then puts the call on hold. The BLF key for 300 shows it as busy/on hold. 1000 then calls 1001 to take the call. 1001 then presses BLF 300, which causes the call to be transferred to them and automatically answered.
So is there any way in freeswitch to replicate this behavior? I know it's possible to do SAA, but this gets tricky if I want to have time based call groups, or to share incoming lines between branches. The method above allows the lines to be present on all phones, while still configuring call groups in the usual way and more or less replicating old key system behavior.
Cheers, Francis
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director
*T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director
*T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Andrew Cassidy
-
Mimiko
-
sms＠icefire.qza.net.au