blind transfer context
Hello, When doing blind transfer, the context used by freeswitch is the one of the transferee instead of the transferer like in attended transfer scenarios. I would like it to use the transferer context. The variable force_transfer_context can be used to force this to a specific context. My problem is that force_transfer_context must be set in the transferee channel which makes it quite complicated if for example I bridge to a groups of users that use different contexts (need an answer hook to set that variable), or in chain transfer scenarios (need to re-set the variable to the context of the new bridged user). Wouldn't it be more logical to use the force_transfer_context variable from the channel performing the transfer to have blind transfers behave the same way as attended ones (using the transferer's context)? Thanks, François.
Pastebin your relevant configs and debug logs. I want to lab this up to see if I can reproduce it. -MC On Thu, Nov 18, 2010 at 2:35 AM, François Delawarde < fdelawarde@wirelessmundi.com> wrote:
Hello,
When doing blind transfer, the context used by freeswitch is the one of the transferee instead of the transferer like in attended transfer scenarios. I would like it to use the transferer context.
The variable force_transfer_context can be used to force this to a specific context. My problem is that force_transfer_context must be set in the transferee channel which makes it quite complicated if for example I bridge to a groups of users that use different contexts (need an answer hook to set that variable), or in chain transfer scenarios (need to re-set the variable to the context of the new bridged user).
Wouldn't it be more logical to use the force_transfer_context variable from the channel performing the transfer to have blind transfers behave the same way as attended ones (using the transferer's context)?
Thanks, François.
_______________________________________________ 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
Hello, I pastebined a very simple configuration for you to reproduce: http://pastebin.freeswitch.org/14552 We have user 100 in context "public", 101 and 102 in context "local". Scenario: 1. 100 calls destination "123" 2. 101 answers, and transfers to 102 In step 2., if 101 does an attended transfer, it will of course use its own context (local) and the transfer will work. Now if 101 does a blind transfer instead, it will use the context of the other leg (100 => public) and it will not work. I think it should behave the same way for both types of transfer by default. A workaround is to set force_transfer_context (uncomment the line on the "public" dialplan) in the channel to be transfered, which can be a pain with more complex configurations. Thanks, François. On Thu, 2010-11-18 at 15:10 -0800, Michael Collins wrote:
Pastebin your relevant configs and debug logs. I want to lab this up to see if I can reproduce it. -MC
On Thu, Nov 18, 2010 at 2:35 AM, François Delawarde <fdelawarde@wirelessmundi.com> wrote: Hello,
When doing blind transfer, the context used by freeswitch is the one of the transferee instead of the transferer like in attended transfer scenarios. I would like it to use the transferer context.
The variable force_transfer_context can be used to force this to a specific context. My problem is that force_transfer_context must be set in the transferee channel which makes it quite complicated if for example I bridge to a groups of users that use different contexts (need an answer hook to set that variable), or in chain transfer scenarios (need to re-set the variable to the context of the new bridged user).
Wouldn't it be more logical to use the force_transfer_context variable from the channel performing the transfer to have blind transfers behave the same way as attended ones (using the transferer's context)?
Thanks, François.
_______________________________________________ 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
_______________________________________________ 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
Small correction in scenario: 1. 100 calls destination "555" (not "123") François. On Fri, 2010-11-19 at 12:04 +0100, François Delawarde wrote:
Hello,
I pastebined a very simple configuration for you to reproduce: http://pastebin.freeswitch.org/14552
We have user 100 in context "public", 101 and 102 in context "local".
Scenario: 1. 100 calls destination "123" 2. 101 answers, and transfers to 102
In step 2., if 101 does an attended transfer, it will of course use its own context (local) and the transfer will work. Now if 101 does a blind transfer instead, it will use the context of the other leg (100 => public) and it will not work.
I think it should behave the same way for both types of transfer by default. A workaround is to set force_transfer_context (uncomment the line on the "public" dialplan) in the channel to be transfered, which can be a pain with more complex configurations.
Thanks, François.
On Thu, 2010-11-18 at 15:10 -0800, Michael Collins wrote:
Pastebin your relevant configs and debug logs. I want to lab this up to see if I can reproduce it. -MC
On Thu, Nov 18, 2010 at 2:35 AM, François Delawarde <fdelawarde@wirelessmundi.com> wrote: Hello,
When doing blind transfer, the context used by freeswitch is the one of the transferee instead of the transferer like in attended transfer scenarios. I would like it to use the transferer context.
The variable force_transfer_context can be used to force this to a specific context. My problem is that force_transfer_context must be set in the transferee channel which makes it quite complicated if for example I bridge to a groups of users that use different contexts (need an answer hook to set that variable), or in chain transfer scenarios (need to re-set the variable to the context of the new bridged user).
Wouldn't it be more logical to use the force_transfer_context variable from the channel performing the transfer to have blind transfers behave the same way as attended ones (using the transferer's context)?
Thanks, François.
_______________________________________________ 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
_______________________________________________ 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
force_transfer_dialplan force_transfer_context You can't tell if a transfer is blind or attended. /b On Nov 19, 2010, at 5:04 AM, François Delawarde wrote:
Hello,
I pastebined a very simple configuration for you to reproduce: http://pastebin.freeswitch.org/14552
We have user 100 in context "public", 101 and 102 in context "local".
Scenario: 1. 100 calls destination "123" 2. 101 answers, and transfers to 102
In step 2., if 101 does an attended transfer, it will of course use its own context (local) and the transfer will work. Now if 101 does a blind transfer instead, it will use the context of the other leg (100 => public) and it will not work.
I think it should behave the same way for both types of transfer by default. A workaround is to set force_transfer_context (uncomment the line on the "public" dialplan) in the channel to be transfered, which can be a pain with more complex configurations.
Thanks, François.
Problem is those variables must be set on the channel that has to be transfered and not the channel that performs the transfer. I thought it would be more logical to use the transferer context by default (just like in attended xfers), and for those variables to be set on the transferer's side. François. On Fri, 2010-11-19 at 08:32 -0600, Brian West wrote:
force_transfer_dialplan force_transfer_context
You can't tell if a transfer is blind or attended.
/b
On Nov 19, 2010, at 5:04 AM, François Delawarde wrote:
Hello,
I pastebined a very simple configuration for you to reproduce: http://pastebin.freeswitch.org/14552
We have user 100 in context "public", 101 and 102 in context "local".
Scenario: 1. 100 calls destination "123" 2. 101 answers, and transfers to 102
In step 2., if 101 does an attended transfer, it will of course use its own context (local) and the transfer will work. Now if 101 does a blind transfer instead, it will use the context of the other leg (100 => public) and it will not work.
I think it should behave the same way for both types of transfer by default. A workaround is to set force_transfer_context (uncomment the line on the "public" dialplan) in the channel to be transfered, which can be a pain with more complex configurations.
Thanks, François.
_______________________________________________ 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
Just as a comment, I have recently employed the functionality of force_transfer_context, and it is great exactly as it is. In my scenario I need to control how the channel RECEIVING a transfer/REFER handles that transfer. For example, I never want incoming calls to directly access certain call paths on my box. But, if a channel receives a REFER to off-box destination X, I want to handle that (even though my default context for incoming calls doesn't allow for destination X). So I have a context that is not associated with my SIP profile for incoming calls. And that context has routing logic for destination X. And I use force_transfer_context so that, when a channel is bridged and gets a REFER to destination X, the ROUTING state sends the channel through my special context for handling transfers. It's awesome!!! And just as another note on your comment, Francois - a transferer has total control over where he transfers another channel (e.g. you can use dialplan context and extension, etc etc. right in transfer app). These channel vars - force_transfer_context and force_transfer_dialplan - allow for controlling how a channel reacts to getting a transfer/REFER thrown at it. Anyway, just a comment.... On Fri, Nov 19, 2010 at 11:45 AM, François Delawarde < fdelawarde@wirelessmundi.com> wrote:
Problem is those variables must be set on the channel that has to be transfered and not the channel that performs the transfer.
I thought it would be more logical to use the transferer context by default (just like in attended xfers), and for those variables to be set on the transferer's side.
François.
On Fri, 2010-11-19 at 08:32 -0600, Brian West wrote:
force_transfer_dialplan force_transfer_context
You can't tell if a transfer is blind or attended.
/b
On Nov 19, 2010, at 5:04 AM, François Delawarde wrote:
Hello,
I pastebined a very simple configuration for you to reproduce: http://pastebin.freeswitch.org/14552
We have user 100 in context "public", 101 and 102 in context "local".
Scenario: 1. 100 calls destination "123" 2. 101 answers, and transfers to 102
In step 2., if 101 does an attended transfer, it will of course use its own context (local) and the transfer will work. Now if 101 does a blind transfer instead, it will use the context of the other leg (100 => public) and it will not work.
I think it should behave the same way for both types of transfer by default. A workaround is to set force_transfer_context (uncomment the line on the "public" dialplan) in the channel to be transfered, which can be a pain with more complex configurations.
Thanks, François.
_______________________________________________ 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
_______________________________________________ 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
Could you pastebin your dialplan? I'd like to let others try it out. Once it's confirmed we'll wikify it. -MC On Fri, Nov 19, 2010 at 9:08 AM, S W <steve.d.ward@gmail.com> wrote:
Just as a comment, I have recently employed the functionality of force_transfer_context, and it is great exactly as it is.
In my scenario I need to control how the channel RECEIVING a transfer/REFER handles that transfer.
For example, I never want incoming calls to directly access certain call paths on my box. But, if a channel receives a REFER to off-box destination X, I want to handle that (even though my default context for incoming calls doesn't allow for destination X).
So I have a context that is not associated with my SIP profile for incoming calls. And that context has routing logic for destination X. And I use force_transfer_context so that, when a channel is bridged and gets a REFER to destination X, the ROUTING state sends the channel through my special context for handling transfers.
It's awesome!!!
And just as another note on your comment, Francois - a transferer has total control over where he transfers another channel (e.g. you can use dialplan context and extension, etc etc. right in transfer app).
These channel vars - force_transfer_context and force_transfer_dialplan - allow for controlling how a channel reacts to getting a transfer/REFER thrown at it.
Anyway, just a comment....
On Fri, Nov 19, 2010 at 11:45 AM, François Delawarde < fdelawarde@wirelessmundi.com> wrote:
Problem is those variables must be set on the channel that has to be transfered and not the channel that performs the transfer.
I thought it would be more logical to use the transferer context by default (just like in attended xfers), and for those variables to be set on the transferer's side.
François.
On Fri, 2010-11-19 at 08:32 -0600, Brian West wrote:
force_transfer_dialplan force_transfer_context
You can't tell if a transfer is blind or attended.
/b
On Nov 19, 2010, at 5:04 AM, François Delawarde wrote:
Hello,
I pastebined a very simple configuration for you to reproduce: http://pastebin.freeswitch.org/14552
We have user 100 in context "public", 101 and 102 in context "local".
Scenario: 1. 100 calls destination "123" 2. 101 answers, and transfers to 102
In step 2., if 101 does an attended transfer, it will of course use its own context (local) and the transfer will work. Now if 101 does a blind transfer instead, it will use the context of the other leg (100 => public) and it will not work.
I think it should behave the same way for both types of transfer by default. A workaround is to set force_transfer_context (uncomment the line on the "public" dialplan) in the channel to be transfered, which can be a pain with more complex configurations.
Thanks, François.
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
I can go ahead and start a wiki page on this. Feedback is welcome. I tried to make a general template-type single code file people can use and work with. http://pastebin.freeswitch.org/14560 On Fri, Nov 19, 2010 at 2:48 PM, Michael Collins <msc@freeswitch.org> wrote:
Could you pastebin your dialplan? I'd like to let others try it out. Once it's confirmed we'll wikify it. -MC
On Fri, Nov 19, 2010 at 9:08 AM, S W <steve.d.ward@gmail.com> wrote:
Just as a comment, I have recently employed the functionality of force_transfer_context, and it is great exactly as it is.
In my scenario I need to control how the channel RECEIVING a transfer/REFER handles that transfer.
For example, I never want incoming calls to directly access certain call paths on my box. But, if a channel receives a REFER to off-box destination X, I want to handle that (even though my default context for incoming calls doesn't allow for destination X).
So I have a context that is not associated with my SIP profile for incoming calls. And that context has routing logic for destination X. And I use force_transfer_context so that, when a channel is bridged and gets a REFER to destination X, the ROUTING state sends the channel through my special context for handling transfers.
It's awesome!!!
And just as another note on your comment, Francois - a transferer has total control over where he transfers another channel (e.g. you can use dialplan context and extension, etc etc. right in transfer app).
These channel vars - force_transfer_context and force_transfer_dialplan - allow for controlling how a channel reacts to getting a transfer/REFER thrown at it.
Anyway, just a comment....
On Fri, Nov 19, 2010 at 11:45 AM, François Delawarde < fdelawarde@wirelessmundi.com> wrote:
Problem is those variables must be set on the channel that has to be transfered and not the channel that performs the transfer.
I thought it would be more logical to use the transferer context by default (just like in attended xfers), and for those variables to be set on the transferer's side.
François.
On Fri, 2010-11-19 at 08:32 -0600, Brian West wrote:
force_transfer_dialplan force_transfer_context
You can't tell if a transfer is blind or attended.
/b
On Nov 19, 2010, at 5:04 AM, François Delawarde wrote:
Hello,
I pastebined a very simple configuration for you to reproduce: http://pastebin.freeswitch.org/14552
We have user 100 in context "public", 101 and 102 in context "local".
Scenario: 1. 100 calls destination "123" 2. 101 answers, and transfers to 102
In step 2., if 101 does an attended transfer, it will of course use its own context (local) and the transfer will work. Now if 101 does a blind transfer instead, it will use the context of the other leg (100 => public) and it will not work.
I think it should behave the same way for both types of transfer by default. A workaround is to set force_transfer_context (uncomment the line on the "public" dialplan) in the channel to be transfered, which can be a pain with more complex configurations.
Thanks, François.
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
And here we have a start on the wiki page http://wiki.freeswitch.org/wiki/Force_transfer_context_example On Fri, Nov 19, 2010 at 3:34 PM, S W <steve.d.ward@gmail.com> wrote:
I can go ahead and start a wiki page on this. Feedback is welcome.
I tried to make a general template-type single code file people can use and work with.
http://pastebin.freeswitch.org/14560
On Fri, Nov 19, 2010 at 2:48 PM, Michael Collins <msc@freeswitch.org>wrote:
Could you pastebin your dialplan? I'd like to let others try it out. Once it's confirmed we'll wikify it. -MC
On Fri, Nov 19, 2010 at 9:08 AM, S W <steve.d.ward@gmail.com> wrote:
Just as a comment, I have recently employed the functionality of force_transfer_context, and it is great exactly as it is.
In my scenario I need to control how the channel RECEIVING a transfer/REFER handles that transfer.
For example, I never want incoming calls to directly access certain call paths on my box. But, if a channel receives a REFER to off-box destination X, I want to handle that (even though my default context for incoming calls doesn't allow for destination X).
So I have a context that is not associated with my SIP profile for incoming calls. And that context has routing logic for destination X. And I use force_transfer_context so that, when a channel is bridged and gets a REFER to destination X, the ROUTING state sends the channel through my special context for handling transfers.
It's awesome!!!
And just as another note on your comment, Francois - a transferer has total control over where he transfers another channel (e.g. you can use dialplan context and extension, etc etc. right in transfer app).
These channel vars - force_transfer_context and force_transfer_dialplan - allow for controlling how a channel reacts to getting a transfer/REFER thrown at it.
Anyway, just a comment....
On Fri, Nov 19, 2010 at 11:45 AM, François Delawarde < fdelawarde@wirelessmundi.com> wrote:
Problem is those variables must be set on the channel that has to be transfered and not the channel that performs the transfer.
I thought it would be more logical to use the transferer context by default (just like in attended xfers), and for those variables to be set on the transferer's side.
François.
On Fri, 2010-11-19 at 08:32 -0600, Brian West wrote:
force_transfer_dialplan force_transfer_context
You can't tell if a transfer is blind or attended.
/b
On Nov 19, 2010, at 5:04 AM, François Delawarde wrote:
Hello,
I pastebined a very simple configuration for you to reproduce: http://pastebin.freeswitch.org/14552
We have user 100 in context "public", 101 and 102 in context "local".
Scenario: 1. 100 calls destination "123" 2. 101 answers, and transfers to 102
In step 2., if 101 does an attended transfer, it will of course use its own context (local) and the transfer will work. Now if 101 does a blind transfer instead, it will use the context of the other leg (100 => public) and it will not work.
I think it should behave the same way for both types of transfer by default. A workaround is to set force_transfer_context (uncomment the line on the "public" dialplan) in the channel to be transfered, which can be a pain with more complex configurations.
Thanks, François.
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
Hi Steve, Thanks for your view on this. My point was that by default a blind transfer acts differently from an attended transfer as it uses the transferee's context instead of the transferer's. It can in some way be controlled as you mention, but having to implement something quite complex only to have blind and attended xfers behaving in the same way seems a bit overkill. For example, if I wish to use the B-leg's context as transfer_context for the A-leg (as in attended xfers), then when bridging to a group it can become a bit complicated: <action application="bridge" data="user/100@example.com,user/101@example.com,..."/> In that case, I would have to use a lua script to set the force_transfer_context to the B-leg's context on answer (because beforehand you wouldn't know who is going to take the call), so that if a transfer happens, it goes in the correct context. François. On Fri, 2010-11-19 at 15:39 -0500, S W wrote:
And here we have a start on the wiki page
http://wiki.freeswitch.org/wiki/Force_transfer_context_example
On Fri, Nov 19, 2010 at 3:34 PM, S W <steve.d.ward@gmail.com> wrote: I can go ahead and start a wiki page on this. Feedback is welcome.
I tried to make a general template-type single code file people can use and work with.
http://pastebin.freeswitch.org/14560
On Fri, Nov 19, 2010 at 2:48 PM, Michael Collins <msc@freeswitch.org> wrote: Could you pastebin your dialplan? I'd like to let others try it out. Once it's confirmed we'll wikify it. -MC
On Fri, Nov 19, 2010 at 9:08 AM, S W <steve.d.ward@gmail.com> wrote: Just as a comment, I have recently employed the functionality of force_transfer_context, and it is great exactly as it is.
In my scenario I need to control how the channel RECEIVING a transfer/REFER handles that transfer.
For example, I never want incoming calls to directly access certain call paths on my box. But, if a channel receives a REFER to off-box destination X, I want to handle that (even though my default context for incoming calls doesn't allow for destination X).
So I have a context that is not associated with my SIP profile for incoming calls. And that context has routing logic for destination X. And I use force_transfer_context so that, when a channel is bridged and gets a REFER to destination X, the ROUTING state sends the channel through my special context for handling transfers.
It's awesome!!!
And just as another note on your comment, Francois - a transferer has total control over where he transfers another channel (e.g. you can use dialplan context and extension, etc etc. right in transfer app).
These channel vars - force_transfer_context and force_transfer_dialplan - allow for controlling how a channel reacts to getting a transfer/REFER thrown at it.
Anyway, just a comment....
On Fri, Nov 19, 2010 at 11:45 AM, François Delawarde <fdelawarde@wirelessmundi.com> wrote: Problem is those variables must be set on the channel that has to be transfered and not the channel that performs the transfer.
I thought it would be more logical to use the transferer context by default (just like in attended xfers), and for those variables to be set on the transferer's side.
François.
On Fri, 2010-11-19 at 08:32 -0600, Brian West wrote: > force_transfer_dialplan > force_transfer_context > > > You can't tell if a transfer is blind or attended. > > > /b > > On Nov 19, 2010, at 5:04 AM, François Delawarde wrote: > > > Hello, > > > > I pastebined a very simple configuration for you to reproduce: > > http://pastebin.freeswitch.org/14552 > > > > We have user 100 in context "public", 101 and 102 in context > > "local". > > > > Scenario: > > 1. 100 calls destination "123" > > 2. 101 answers, and transfers to 102 > > > > In step 2., if 101 does an attended transfer, it will of course use > > its > > own context (local) and the transfer will work. Now if 101 does a > > blind > > transfer instead, it will use the context of the other leg (100 => > > public) and it will not work. > > > > I think it should behave the same way for both types of transfer by > > default. A workaround is to set force_transfer_context (uncomment > > the > > line on the "public" dialplan) in the channel to be transfered, > > which > > can be a pain with more complex configurations. > > > > Thanks, > > François. > >
> _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
Francois, Thanks for the example in your situation. I think that, to control what you want the channel to do on a transfer, still does not need to be overly complex. It looks like you are first bridging to specific endpoints. You have various options available to you for setting force_transfer_context on the a-leg when the bridge happens (even an using execute_on_answer or api_on_answer or whatever). The b-leg that answers can execute the appropriate set onto the a-leg (even using uuid_setvar or something else). Then, any subsequent transfer would involve the context you desire. - Steve On Mon, Nov 22, 2010 at 1:23 AM, François Delawarde < fdelawarde@wirelessmundi.com> wrote:
Hi Steve,
Thanks for your view on this. My point was that by default a blind transfer acts differently from an attended transfer as it uses the transferee's context instead of the transferer's.
It can in some way be controlled as you mention, but having to implement something quite complex only to have blind and attended xfers behaving in the same way seems a bit overkill.
For example, if I wish to use the B-leg's context as transfer_context for the A-leg (as in attended xfers), then when bridging to a group it can become a bit complicated:
<action application="bridge" data="user/100@example.com,user/ 101@example.com,..."/>
In that case, I would have to use a lua script to set the force_transfer_context to the B-leg's context on answer (because beforehand you wouldn't know who is going to take the call), so that if a transfer happens, it goes in the correct context.
François.
On Fri, 2010-11-19 at 15:39 -0500, S W wrote:
And here we have a start on the wiki page
http://wiki.freeswitch.org/wiki/Force_transfer_context_example
On Fri, Nov 19, 2010 at 3:34 PM, S W <steve.d.ward@gmail.com> wrote: I can go ahead and start a wiki page on this. Feedback is welcome.
I tried to make a general template-type single code file people can use and work with.
http://pastebin.freeswitch.org/14560
On Fri, Nov 19, 2010 at 2:48 PM, Michael Collins <msc@freeswitch.org> wrote: Could you pastebin your dialplan? I'd like to let others try it out. Once it's confirmed we'll wikify it. -MC
On Fri, Nov 19, 2010 at 9:08 AM, S W <steve.d.ward@gmail.com> wrote: Just as a comment, I have recently employed the functionality of force_transfer_context, and it is great exactly as it is.
In my scenario I need to control how the channel RECEIVING a transfer/REFER handles that transfer.
For example, I never want incoming calls to directly access certain call paths on my box. But, if a channel receives a REFER to off-box destination X, I want to handle that (even though my default context for incoming calls doesn't allow for destination X).
So I have a context that is not associated with my SIP profile for incoming calls. And that context has routing logic for destination X. And I use force_transfer_context so that, when a channel is bridged and gets a REFER to destination X, the ROUTING state sends the channel through my special context for handling transfers.
It's awesome!!!
And just as another note on your comment, Francois - a transferer has total control over where he transfers another channel (e.g. you can use dialplan context and extension, etc etc. right in transfer app).
These channel vars - force_transfer_context and force_transfer_dialplan - allow for controlling how a channel reacts to getting a transfer/REFER thrown at it.
Anyway, just a comment....
On Fri, Nov 19, 2010 at 11:45 AM, François Delawarde <fdelawarde@wirelessmundi.com> wrote: Problem is those variables must be set on the channel that has to be transfered and not the channel that performs the transfer.
I thought it would be more logical to use the transferer context by default (just like in attended xfers), and for those variables to be set on the transferer's side.
François.
On Fri, 2010-11-19 at 08:32 -0600, Brian West wrote: > force_transfer_dialplan > force_transfer_context > > > You can't tell if a transfer is blind or attended. > > > /b > > On Nov 19, 2010, at 5:04 AM, François Delawarde wrote: > > > Hello, > > > > I pastebined a very simple configuration for you to reproduce: > > http://pastebin.freeswitch.org/14552 > > > > We have user 100 in context "public", 101 and 102 in context > > "local". > > > > Scenario: > > 1. 100 calls destination "123" > > 2. 101 answers, and transfers to 102 > > > > In step 2., if 101 does an attended transfer, it will of course use > > its > > own context (local) and the transfer will work. Now if 101 does a > > blind > > transfer instead, it will use the context of the other leg (100 => > > public) and it will not work. > > > > I think it should behave the same way for both types of transfer by > > default. A workaround is to set force_transfer_context (uncomment > > the > > line on the "public" dialplan) in the channel to be transfered, > > which > > can be a pain with more complex configurations. > > > > Thanks, > > François. > >
>
_______________________________________________
> 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
_______________________________________________
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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
It's a very cool feature to be able to force this transfer context, and there are several options indeed for my scenario. I currently have to use a lua script that is called "on_answer" and sets the force_transfer_context to the other leg's context. I don't argue that it can't be done, but I believe that in most situations you would want blind transfer and attended transfer to behave the same way: using the transferer's context. It would be nice to have that behavior by default. François. On Mon, 2010-11-22 at 05:13 -0800, S W wrote:
Francois,
Thanks for the example in your situation. I think that, to control what you want the channel to do on a transfer, still does not need to be overly complex.
It looks like you are first bridging to specific endpoints. You have various options available to you for setting force_transfer_context on the a-leg when the bridge happens (even an using execute_on_answer or api_on_answer or whatever). The b-leg that answers can execute the appropriate set onto the a-leg (even using uuid_setvar or something else). Then, any subsequent transfer would involve the context you desire.
- Steve
On Mon, Nov 22, 2010 at 1:23 AM, François Delawarde <fdelawarde@wirelessmundi.com> wrote: Hi Steve,
Thanks for your view on this. My point was that by default a blind transfer acts differently from an attended transfer as it uses the transferee's context instead of the transferer's.
It can in some way be controlled as you mention, but having to implement something quite complex only to have blind and attended xfers behaving in the same way seems a bit overkill.
For example, if I wish to use the B-leg's context as transfer_context for the A-leg (as in attended xfers), then when bridging to a group it can become a bit complicated:
<action application="bridge" data="user/100@example.com,user/101@example.com,..."/>
In that case, I would have to use a lua script to set the force_transfer_context to the B-leg's context on answer (because beforehand you wouldn't know who is going to take the call), so that if a transfer happens, it goes in the correct context.
François.
On Fri, 2010-11-19 at 15:39 -0500, S W wrote: > And here we have a start on the wiki page > > http://wiki.freeswitch.org/wiki/Force_transfer_context_example > > On Fri, Nov 19, 2010 at 3:34 PM, S W <steve.d.ward@gmail.com> wrote: > I can go ahead and start a wiki page on this. Feedback is > welcome. > > I tried to make a general template-type single code file > people can use and work with. > > http://pastebin.freeswitch.org/14560 > > > > > > On Fri, Nov 19, 2010 at 2:48 PM, Michael Collins > <msc@freeswitch.org> wrote: > Could you pastebin your dialplan? I'd like to let > others try it out. Once it's confirmed we'll wikify > it. > -MC > > > > On Fri, Nov 19, 2010 at 9:08 AM, S W > <steve.d.ward@gmail.com> wrote: > Just as a comment, I have recently employed > the functionality of force_transfer_context, > and it is great exactly as it is. > > In my scenario I need to control how the > channel RECEIVING a transfer/REFER handles > that transfer. > > For example, I never want incoming calls to > directly access certain call paths on my box. > But, if a channel receives a REFER to off-box > destination X, I want to handle that (even > though my default context for incoming calls > doesn't allow for destination X). > > So I have a context that is not associated > with my SIP profile for incoming calls. And > that context has routing logic for destination > X. And I use force_transfer_context so that, > when a channel is bridged and gets a REFER to > destination X, the ROUTING state sends the > channel through my special context for > handling transfers. > > It's awesome!!! > > And just as another note on your comment, > Francois - a transferer has total control over > where he transfers another channel (e.g. you > can use dialplan context and extension, etc > etc. right in transfer app). > > These channel vars - force_transfer_context > and force_transfer_dialplan - allow for > controlling how a channel reacts to getting a > transfer/REFER thrown at it. > > Anyway, just a comment.... > > > > On Fri, Nov 19, 2010 at 11:45 AM, François > Delawarde <fdelawarde@wirelessmundi.com> > wrote: > Problem is those variables must be set > on the channel that has to be > transfered and not the channel that > performs the transfer. > > I thought it would be more logical to > use the transferer context by > default (just like in attended xfers), > and for those variables to be set > on the transferer's side. > > François. > > > > On Fri, 2010-11-19 at 08:32 -0600, > Brian West wrote: > > force_transfer_dialplan > > force_transfer_context > > > > > > You can't tell if a transfer is > blind or attended. > > > > > > /b > > > > On Nov 19, 2010, at 5:04 AM, > François Delawarde wrote: > > > > > Hello, > > > > > > I pastebined a very simple > configuration for you to reproduce: > > > > http://pastebin.freeswitch.org/14552 > > > > > > We have user 100 in context > "public", 101 and 102 in context > > > "local". > > > > > > Scenario: > > > 1. 100 calls destination "123" > > > 2. 101 answers, and transfers to > 102 > > > > > > In step 2., if 101 does an > attended transfer, it will of course > use > > > its > > > own context (local) and the > transfer will work. Now if 101 does a > > > blind > > > transfer instead, it will use the > context of the other leg (100 => > > > public) and it will not work. > > > > > > I think it should behave the same > way for both types of transfer by > > > default. A workaround is to set > force_transfer_context (uncomment > > > the > > > line on the "public" dialplan) in > the channel to be transfered, > > > which > > > can be a pain with more complex > configurations. > > > > > > Thanks, > > > François. > > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ 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
I think I see a little better where you are coming from - in my experience I have found the current default behavior of transfers (blind and otherwise) in freeswitch to be exactly what is needed. But I see that you mention wanting to make changes to blind and attended transfers consistently. I have actually implemented separate dialplan paths and a lua script for dealing separately with blind and attended transfers in my own applications. But I have found there is necessary reason for things to be done that way. Not all transfers are created equal in SIP. (And that presents a challenge. =p) For example, in a fully attended transfer, the a-leg's session is simply adjusted so that its communication is now with a different endpoint. But in a blind transfer, the a-leg is essentially told to tear its session down and start a brand new session. The great difference in flow of activity between different types of 'transfer' and 'forwarding' give very different hooks into modifying the operations. Even though the word 'transfer' is used in the name of both these operations, they really are very, very different operations. So, then, blind xfer and attended xfer never behave the same way under the hood. That makes it difficult, at times impractical, and at times impossible to have flags that single-handedly encompass changes in the behavior to all types of transfer. I definitely do not take issue with the validity of the needs in your situation, Francois. Actually, I sympathize because I've had to implement specific control of transfer myself in a few different applications, as I mentioned. I just wanted to throw this information out there because I have found it helpful for myself to remind myself of the details of what can possibly happen with SIP transfers. It usually helps me to understand why or why not certain control points may be available to me and how to use dialplan, lua scripts, etc. to provide the control I need. Hopefully this discussion is helpful to others reading this thread, too. Hope the transferring keeps going well for you, Francois! :-) On Mon, Nov 22, 2010 at 5:39 AM, François Delawarde < fdelawarde@wirelessmundi.com> wrote:
It's a very cool feature to be able to force this transfer context, and there are several options indeed for my scenario. I currently have to use a lua script that is called "on_answer" and sets the force_transfer_context to the other leg's context.
I don't argue that it can't be done, but I believe that in most situations you would want blind transfer and attended transfer to behave the same way: using the transferer's context. It would be nice to have that behavior by default.
François.
On Mon, 2010-11-22 at 05:13 -0800, S W wrote:
Francois,
Thanks for the example in your situation. I think that, to control what you want the channel to do on a transfer, still does not need to be overly complex.
It looks like you are first bridging to specific endpoints. You have various options available to you for setting force_transfer_context on the a-leg when the bridge happens (even an using execute_on_answer or api_on_answer or whatever). The b-leg that answers can execute the appropriate set onto the a-leg (even using uuid_setvar or something else). Then, any subsequent transfer would involve the context you desire.
- Steve
On Mon, Nov 22, 2010 at 1:23 AM, François Delawarde <fdelawarde@wirelessmundi.com> wrote: Hi Steve,
Thanks for your view on this. My point was that by default a blind transfer acts differently from an attended transfer as it uses the transferee's context instead of the transferer's.
It can in some way be controlled as you mention, but having to implement something quite complex only to have blind and attended xfers behaving in the same way seems a bit overkill.
For example, if I wish to use the B-leg's context as transfer_context for the A-leg (as in attended xfers), then when bridging to a group it can become a bit complicated:
<action application="bridge" data="user/100@example.com,user/101@example.com,..."/>
In that case, I would have to use a lua script to set the force_transfer_context to the B-leg's context on answer (because beforehand you wouldn't know who is going to take the call), so that if a transfer happens, it goes in the correct context.
François.
On Fri, 2010-11-19 at 15:39 -0500, S W wrote: > And here we have a start on the wiki page > > http://wiki.freeswitch.org/wiki/Force_transfer_context_example > > On Fri, Nov 19, 2010 at 3:34 PM, S W <steve.d.ward@gmail.com> wrote: > I can go ahead and start a wiki page on this. Feedback is > welcome. > > I tried to make a general template-type single code file > people can use and work with. > > http://pastebin.freeswitch.org/14560 > > > > > > On Fri, Nov 19, 2010 at 2:48 PM, Michael Collins > <msc@freeswitch.org> wrote: > Could you pastebin your dialplan? I'd like to let > others try it out. Once it's confirmed we'll wikify > it. > -MC > > > > On Fri, Nov 19, 2010 at 9:08 AM, S W > <steve.d.ward@gmail.com> wrote: > Just as a comment, I have recently employed > the functionality of force_transfer_context, > and it is great exactly as it is. > > In my scenario I need to control how the > channel RECEIVING a transfer/REFER handles > that transfer. > > For example, I never want incoming calls to > directly access certain call paths on my box. > But, if a channel receives a REFER to off-box > destination X, I want to handle that (even > though my default context for incoming calls > doesn't allow for destination X). > > So I have a context that is not associated > with my SIP profile for incoming calls. And > that context has routing logic for destination > X. And I use force_transfer_context so that, > when a channel is bridged and gets a REFER to > destination X, the ROUTING state sends the > channel through my special context for > handling transfers. > > It's awesome!!! > > And just as another note on your comment, > Francois - a transferer has total control over > where he transfers another channel (e.g. you > can use dialplan context and extension, etc > etc. right in transfer app). > > These channel vars - force_transfer_context > and force_transfer_dialplan - allow for > controlling how a channel reacts to getting a > transfer/REFER thrown at it. > > Anyway, just a comment.... > > > > On Fri, Nov 19, 2010 at 11:45 AM, François > Delawarde <fdelawarde@wirelessmundi.com> > wrote: > Problem is those variables must be set > on the channel that has to be > transfered and not the channel that > performs the transfer. > > I thought it would be more logical to > use the transferer context by > default (just like in attended xfers), > and for those variables to be set > on the transferer's side. > > François. > > > > On Fri, 2010-11-19 at 08:32 -0600, > Brian West wrote: > > force_transfer_dialplan > > force_transfer_context > > > > > > You can't tell if a transfer is > blind or attended. > > > > > > /b > > > > On Nov 19, 2010, at 5:04 AM, > François Delawarde wrote: > > > > > Hello, > > > > > > I pastebined a very simple > configuration for you to reproduce: > > > > http://pastebin.freeswitch.org/14552 > > > > > > We have user 100 in context > "public", 101 and 102 in context > > > "local". > > > > > > Scenario: > > > 1. 100 calls destination "123" > > > 2. 101 answers, and transfers to > 102 > > > > > > In step 2., if 101 does an > attended transfer, it will of course > use > > > its > > > own context (local) and the > transfer will work. Now if 101 does a > > > blind > > > transfer instead, it will use the > context of the other leg (100 => > > > public) and it will not work. > > > > > > I think it should behave the same > way for both types of transfer by > > > default. A workaround is to set > force_transfer_context (uncomment > > > the > > > line on the "public" dialplan) in > the channel to be transfered, > > > which > > > can be a pain with more complex > configurations. > > > > > > Thanks, > > > François. > > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
This is how it should work see when you attended transfer you're making a third call. Using YOUR context.. when you blind transfer you're not.. you're redirecting the caller so yes this would use their context, dialplan and permissions. /b On Nov 22, 2010, at 3:23 AM, François Delawarde wrote:
Thanks for your view on this. My point was that by default a blind transfer acts differently from an attended transfer as it uses the transferee's context instead of the transferer's.
Ok, I now see what you and Steve mean, that with those stupid REFERs in the SIP protocol, attended and blind transfers are very different things. I'll try to explain this detail to my users (they were used to do blind and attended xfers indifferently), and if they are unhappy I'll threaten to re-install their old * PBX. This ultimate threat should garantee they will stop using blind transfers right away! Oh, and any way to disable blind xfers only? François. On Mon, 2010-11-22 at 08:56 -0600, Brian West wrote:
This is how it should work see when you attended transfer you're making a third call. Using YOUR context.. when you blind transfer you're not.. you're redirecting the caller so yes this would use their context, dialplan and permissions.
/b
On Nov 22, 2010, at 3:23 AM, François Delawarde wrote:
Thanks for your view on this. My point was that by default a blind transfer acts differently from an attended transfer as it uses the transferee's context instead of the transferer's.
_______________________________________________ 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
On Mon, Nov 22, 2010 at 8:23 AM, François Delawarde < fdelawarde@wirelessmundi.com> wrote:
Ok, I now see what you and Steve mean, that with those stupid REFERs in the SIP protocol, attended and blind transfers are very different things.
I'll try to explain this detail to my users (they were used to do blind and attended xfers indifferently), and if they are unhappy I'll threaten to re-install their old * PBX. This ultimate threat should garantee they will stop using blind transfers right away!
Oh, and any way to disable blind xfers only?
What kind of phones? If they're Polycoms then you probably can disable "blind x-fer" in the configs, although I confess I've never tried it. -MC
On Mon, 2010-11-22 at 09:41 -0800, Michael Collins wrote:
Oh, and any way to disable blind xfers only?
What kind of phones? If they're Polycoms then you probably can disable "blind x-fer" in the configs, although I confess I've never tried it.
I was asking more for the FS side, if it was possible to disable only one of blind or attended transfer (as they are so different). Anything to do with the "manual-redirect" or "disable-transfer" parameters? Thanks, François.
No because you have NO way of knowing if its blind or attended. /b On Nov 22, 2010, at 12:00 PM, François Delawarde wrote:
On Mon, 2010-11-22 at 09:41 -0800, Michael Collins wrote:
Oh, and any way to disable blind xfers only?
What kind of phones? If they're Polycoms then you probably can disable "blind x-fer" in the configs, although I confess I've never tried it.
I was asking more for the FS side, if it was possible to disable only one of blind or attended transfer (as they are so different).
Anything to do with the "manual-redirect" or "disable-transfer" parameters?
Thanks, François.
participants (4)
-
Brian West
-
François Delawarde
-
Michael Collins
-
S W