asterisk users - Dec 2010 - transfer from sip to dahdi, connects caller to MOH stream and not target

The setup is this:
2 sip handsets (a Cisco 7960 and a 7961) exten 401/402
1 fxs/dahdi cordless phone, exten 201
rhino fxo/fxs analog card
asterisk 1.4.31

This is running on a Soekris 5501 with Astlinux 0.7.2

While I do have FXO capabilities, no POTS lines are connected.

When a call comes in (VoIP, either SIP or IAX) it is usually answered on one
of the SIP Cisco phones(x 401 or 402). If it is for my wife, then I would
like to transfer the call to the fxs/dahdi analog cordless phone (x 201). At
one time this worked, but about a year or so ago it stopped.

What is happening now is that the call comes in (x 401), is transferred via
the cisco transfer soft button to (x 201), ... during this time the caller
was put on hold or rather was automatically connected to the MOH process...
, When (x 201) answers the phone, they are connected to the MOH process and
cannot hear or talk to the original caller.

In testing, if I leave the (x 201) call open, the original outside call is
kept open as well (the original caller hears nothing). A look at the
"active
sessions" confirms this. When either (x 201) or original caller hang up,
the
call/connection is terminated.

I can transfer calls from one Cisco to the other without issue.

I have looked around at my configs, but don't see anything that would cause
this... but truthfully I don't even know where to begin with something like
this. I checked the logs to see if there was something helpful there but did
not see anything. My only though is that it is something with the way the
Cisco internal transfer process happens... but again, I don't know where to
begin to test that theory.

Has anyone seen or heard of this? Know how to resolve to expected behavior?
I appreciate any pointers.

John R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20101217/85d89daf/attachment.htm>

John Reynolds wrote:
> Has anyone seen or heard of this? Know how to resolve to expected 
> behavior?  I appreciate any pointers. 
John,

Without seeing any of your dial plan or any of the output from your 
console during the failed transfer, nobody is going to be able to help.

Why don't you start by posting the relevant part of your code that does 
the dialing and shows up the console output during a test transfer?

Doug


-- 
Ben Franklin quote:

"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety."