[nc_mark]

hi all,
i manage our broadsoft voip platform, and we're looking at the spa-841 for deployment. looks like a great phone - until a couple of our pbx tech's tossed a few real-worlds at me with this phone... and i'm having some issues getting it to pass the test for them (but a cisco 7960 will).
problem:
party "a" calls party "b" on the 841.
party "b" now wants to do a supervised xfer to party "c"
xfer call from "b" to "c" is made okay.
but the attempt to link "a" to "c" and drop "b" fails the whole call.
we're running the most up-to-date code on the 841.
blind xfer does work as expected.
any thoughts... anyone seen this?
what am i doing wrong? we are doing as the sipura docs say.
thanks,
mark

[mberlant]

I would have a look at a couple of parameters. With any luck, one is set wrong.

On the Phone page, make sure that Att[e]n[ded] Transfer Serv[ice] is set to Yes. Then, on each Ext page make sure that Blind Attn-Xfer Enable is set to Yes.

If we're lucky, changing one of these will get you going.

[nc_mark]

tried those already. :-(
i'm open for other ideas. :-)
i assume that the function does work okay elsewhere? (such as outside of broadsoft?)
the fact that doing an xfer on the cisco 7960 works as expected does make me think we isolated this issue to the 841. broadsoft does support both phones out-of-the-box.

[nc_mark]

just got to thinking about this problem...
we're using cisco voice gateways in our shop, and all audio mixing, in the case of cisco's, is done on the phone that is adding the third party.
for example:
if you have party "a" speaking to party "b", and party "a" now brings party "c" into the conversation via conf call, the mixing for this is done on party "a" phone - not the voice gateway like many people would think it should be. that is there are two streams going to party "a" phone... one for "b" and one for "c".
yes, hard to believe, and we didn't believe it until we did it in the lab... but it's how cisco does it.
so...
perhaps this has something to do with the problem?
i happened on another post from a broadvoice user (and broadvoice uses broadsoft, as do we), and he said he had the same problem... he changed from one of their proxy pops to another and "schablink" it started working! (the supervised xfer that is)
so i'm wondering if maybe they are using two different types of voice gateways at two different locations - not an uncommon thing to do in our world.
** i'm still holding out hope that someone can prove this idea wrong and come up with a fix **