Jeff,
thanks very much for picking this up. You quickly spotted my mistake - I had
the bind_meta_data call in the local extensions but not added it to the
group extension (100).
Appreciate you taking the time to have a look and point out my silly
mistake - all working now,
regards
Dave
----- Original Message -----
From: "Jeff Lenk" <jl...@frontiernet.net>
To: <freeswitch-users@lists.freeswitch.org>
Sent: Wednesday, November 25, 2009 3:54 AM
Subject: Re: [Freeswitch-users] Call Transfer Help Please
>
> I do not see the meta app getting added in your log
> ->
> Dialplan: sofia/internal/1...@192.168.1.50 Action bind_meta_app(*
>
> Without this no meta actions will occur
>
>
>
> Dave Stevenson wrote:
>>
>> Hi again folks,
>>
>> I have posted a dump into the Pastebin (11276), could someone have a look
>> and perhaps suggest where the problem might be please ?
>>
>> I'm sure you'll be able to work it out, but the log is for a call where
>> :-
>>
>> incoming on PSTN Line (ext 1000)
>> Group exts, 111, 1001, 1001
>> Answered on 111 and requested transfer to 1001 with no success
>>
>> regards
>> Dave
>>
>>
>> ----- Original Message -----
>> From: Dave Stevenson
>> To: freeswitch-users@lists.freeswitch.org
>> Sent: Tuesday, November 24, 2009 10:36 PM
>> Subject: Re: [Freeswitch-users] Call Transfer Help Please
>>
>>
>> Hi Mike,
>>
>> thanks for the reply. I am using the pre-compiled Windows binary - is
>> there a 1.0.5 pre-release of that yet ?
>>
>> FreeSwitch reports its version as 1.0.4 (14460) but this is not
>> correct,
>> I was sure that I had previously loaded a later SVN Version, but just did
>> it again, unless I'm not doing it right, the version number does not seem
>> to be getting updated. The current build in the precompiled binaries area
>> is reported to be 15604 and I've downloaded and installed that - although
>> when the installer runs it tells me that it is version 15376. Either way,
>> the "Version" command in FreeSwitch reports 1.0.4 (14460).
>>
>> The Transfer still does not work for me from the extension which
>> answers
>> the call.
>>
>> Sorry if my earlier questions were unclear ...
>> "What are the correct LISTEN_TO and RESPOND_ON entries in
>> dialplan.xml
>> ?"
>> What is the correct "transfer" data string in features.xml ?
>> I don't understand this question(s)
>>
>> I was looking for clarification of the second two arguments in the
>> bind_meta_app data call, i.e, that the "b" and "s" were the correct
>> values
>> and also that the "is transfer" "transfer" data argument was "-bleg"
>>
>> That is, that the arguments in the default dialplan are correct for
>> this
>> scenario - which they appear to be based on your previous reply to my
>> query.
>>
>> So, is there anything else that I can check to see why this is not
>> working ?
>>
>>
>> regards
>> Dave
>>
>>
>>
>> ----- Original Message -----
>> From: Michael Jerris
>> To: freeswitch-users@lists.freeswitch.org
>> Sent: Tuesday, November 24, 2009 8:19 PM
>> Subject: Re: [Freeswitch-users] Call Transfer Help Please
>>
>>
>>
>>
>> On Nov 24, 2009, at 5:29 AM, Dave Stevenson wrote:
>>
>>
>> Hi,
>>
>> I'm trying to setup call transfer for a phone without a transfer
>> button. I was on IRC last night and got some pointers to how this is
>> setup
>> in dialplan.xml and features.xml and what "bind meta app" does.
>>
>> Once it became clear how the transfer is initiated and that the
>> transfer, in the default config, can only be initiated by the "b" leg of
>> the call, I was able to make this work as configured in the defaults,
>> i.e,
>> to initiate a transfer (for an internal call) from the dialled extension
>> to a new extension.
>>
>> Now the problem . . .
>>
>> I have an incoming PSTN line that rings a group of extensions, what
>> I want to be able to do is to give whoever answers the PSTN call ability
>> to transfer the call on to another extension.
>>
>> There is an ATA (Linksys SPA3101) set up on the PSTN line with a
>> FreeSwitch extension of 1000, it rings the extension phones in the group.
>>
>> I'd hoped that the default transfer setup would handle this without
>> modification - the incoming call on extension 1000 would be the "a" leg,
>> the answering extension would be the "b" leg and a transfer from "b"
>> would
>> work as per the default config. This does not work for me though.
>>
>> I'm struggling a bit with the "bind meta app" options and can't
>> seem
>> to make it do what I want.
>>
>> Could someone please confirm that what I'm trying to do is feasible
>> and perhaps suggest the right parameters to use in dialplan.xml and
>> features.xml please ?
>>
>> Relevant section in the "is_transfer" section in features.xml
>> <action application="transfer" data="-bleg ${digits} XML default"/>
>>
>> And in default.xml from
>> <action application="bind_meta_app" data="1 b s
>> execute_extension::dx XML features"/> to
>>
>>
>> I've tried posting a call log to the Pastebin (11252/3) but there
>> was an error - it looks like the dump was too big. Not sure what the
>> maximum size on pastebin dumps is ?
>>
>>
>> My understanding (or lack of) of "a" and "b" are in the scenario
>> described is not helping ...
>>
>> Is the "a" leg the call coming in on the PSTN line (on Ext 1000) ?
>>
>>
>> Yes, the calling leg
>>
>>
>> Is the answering extension the "b" leg ?
>>
>>
>> Yes
>>
>>
>> What are the correct LISTEN_TO and RESPOND_ON entries in
>> dialplan.xml ?
>>
>>
>> I don't understand this question
>>
>>
>> What is the correct "transfer" data string in features.xml ?
>>
>>
>>
>> ditto
>>
>>
>> Or am I totally on the wrong track here ?
>>
>>
>>
>> You should just need to make sure that the bind meta is called in
>> this
>> scenario so the b leg is able to do it, thats it.
>>
>>
>> If it is possible to do what I want, and changes are required to
>> the
>> dialplan.xml and/or features.xml files, is it possible to have different
>> logic in there such that the actions are different whether it is the "a"
>> leg or "b" leg that's requesting the transfer ?
>>
>> regards
>> Dave
>>
>> FreeSwitch Version 1.0.4 (14460)
>>
>>
>> also, try the latest 1.0.5. pre release or svn trunk to confirm this
>> is not an issue that has already been fixed.
>>
>>
>> Mike
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> --
> View this message in context:
> http://n2.nabble.com/Call-Transfer-Help-Please-tp4056930p4062810.html
> Sent from the freeswitch-users mailing list archive at Nabble.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
>
_______________________________________________
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
