Blind transfer issue with SPA IP phones.

Unanswered Question
Jul 16th, 2009
User Badges:

We have been seeing a scenario where calls some blind transferred calls are being dropped by Linksys SPA desk phone units. The scenario is as follows:

EP A is a Linksys. EP A receives any call. EP A transfers call to EP B (does not matter which device).

At this point, regardless if EP B is a Linksys or other CPE, if the call is BLIND TRANSFERRED back to EP A, it will be dropped by EP A.

Unfortunately the calls appear to be dropped 90% of the time the scenario occurs but there are occasions where the call is received successfully. I have made some SIP and syslog captures for these calls which I can provide directly to Cisco staff if required.

Call A:
PSTN -> SPA942 blind transfer-> SPA922 blind transfer -> SPA942 (this call fails on the 2nd blind transfer) – SPA942 sends “500 Internal server error”

Call B:
PSTN -> SPA942 blind transfer-> SPA922 blind transfer -> SPA942 (successful)

Call C:
PSTN -> SPA942 blind transfer-> SPA922 blind transfer -> SPA942 (this call fails on the 2nd blind transfer) – SPA942 sends “400 Bad request”

Call D:
PSTN -> SPA942 blind transfer-> SPA922 blind transfer -> SPA942 blind transfer -> SPA922 blind transfer -> SPA942 (this call fails on the 4th blind transfer) – SPA942 sends “500 Internal server error”

This scenario can happen at any point during the life of a call. For example: If a call is received by any CPE, and then transferred to a Linksys CPE, and THEN the above scenario is tested, it will still fail.

We have tested the same scenario with other CPE vendors and all transfers appear to function correctly.

Please note it is always the target phone which drops the call.

Tested devices were all using the 6.1.5a firmware version.

Is anybody able to shed some light on this?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
arunskariah Fri, 07/17/2009 - 23:15
User Badges:

Yes Cisco Australia had offered this same solution however the issue occurs the same way whether the xfer of bxfer soft keys are used. Please note that it is the target phone that is dropping the INVITE message, not the initiator so it does not appear to be a problem with the transfer function on the phone initiating the transfer request.


A tfr to B

B is receiving the INVITE which A sends but it is being dropped. A appears to be sending the invite correctly.

I can private message these captures to you if you'd like to see the actual packet contents.

Patrick Born Mon, 07/20/2009 - 09:32
User Badges:
  • Cisco Employee,

Hi Arun,

Yes, please send the traces of the issue to me at paborn at

For completeness, also:

Please confirm what you are using for call-control. If SPA9000, please provide its config too:

Once received, I'll share with Engineering.




erickjohnson Tue, 12/01/2009 - 17:26
User Badges:


What was the result of this issue?

I am seeing similar behavior (described below) on a SPA-942 (fw version 5.1.15(a))

In my example Bob is on a Polycom 550 and calls Alice on a Linksys SPA942.

Bob blind transfers Alice to Ron.  Bob, Alice, and Ron all communicate through

the same outbound proxy server.

SIP traces (described below) show Alice accepts the SIP REFER but then later

responds to Bob with a SIP NOTIFY that contains the body

"SIP/2.0 600 Busy Everywhere"

SIP traces off of the Linksys (over the LAN to syslogd) show an INVITE is

sent out to Ron, however the trace off of the wire at the proxy server shows

that this INVITE never gets sent.

The "Blind Attn-Xfer Enable" on the linksys is set to "yes" on the line in use.

All other lines are disabled.

I have an ngrep'd SIP trace between the Linksys and the proxy server, as well as

the Linksys debugging capture described here:

I also have the configuration for the Linksys phone saved as an HTML file as

described here:

I would prefer not attaching the files to the post as they contain information

not appropriate for a public forum.  Please let me know who I may contact

with this information to get this issue resolved.

Also to note - this issue is repeatable 100% of the time.  The issue also occurs

regardless of whether Bob is a polycom, an eyebeam, or an asterisk box.


Erick Johnson

erickjohnson Tue, 12/01/2009 - 19:19
User Badges:

update: I have updated to fw 6.1.5(a) with no change in results


This Discussion