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 ?

----- Original Message -----

From: Michael Jerris

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