[Freeswitch-users] blind transfer context
S W
steve.d.ward at gmail.com
Mon Nov 22 06:21:32 PST 2010
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 at 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 at 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 at example.com,user/101 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20101122/55c02179/attachment-0001.html
More information about the FreeSWITCH-users
mailing list