My understanding of: - blind transfer: A calls B, B dials C and A
rings C while A and B are immediately disconnected
B dials C is not a part of a blind transfer, just a second unrelated
call. Have you checked the diagrams I sent?
A blind transfer would be A calls B, B transfers A to C, A calls C.
- attended transfer: A calls B, B calls C, B talks to C while A is
on-hold, B transfers A to C so A and B are disconnected
Sounds right. An important part here is that A's call to C replaces B's
call with C because when B transferred A, its refer message indicated
the dialog that has to be replaced.
In my network I have Jitsi clients as well as other SIP softphones
(eg. SJphone), all registered to the same PBX. If I repeat the same
steps for a blind transfer with SJphone, all's as I expect it to be.
However, if I use Jitsi, instead of a blind transfer, I'm getting an
attended transfer (according to my definitions above),
Well, as I said, this might be a "definitions" problem so it would be
helpful if we could agree on using the SIP/IETF ones. Right now I really
don't get it.
Jitsi has a different interface for Blind and Attended transfers. A
blind transfer pops up a new "Transfer Call" dialog that lets you
transfer to any number (screenshot attached).
When an attended transfer is possible jitsi brings up a menu with the
possible calls that you can replace (screenshot attached).
Unless you use the latter I don't see how Jitsi could ever do an
attended transfer. If you use the latter then Jitsi can only do an
If you want a blind transfer, you have to use the "Transfer Call" dialog.
Is this what you are doing?
ie. B can't
disconnect from A and let A ring C (B actually dials C until C picks
the phone up - meanwhile, A is left in stand-by until B decides to
transfer A to C).
OK, that's a bit more helpful, but I still don't understand. Why does B
dial anyone? B should just be sending a Refer here. If B really dials
someone then, yes, A would be placed on hold. This is not because of any
transfer, but because Jitsi to automaticall places all calls on hold
when a new one connects.
I hope I've explained it clearly. If it were an Asterisk bug or
misconfiguration then I suppose I couldn't perform blind trasnfers
with SJphone. Or maybe SJphone is buggy or doesn't comply to
I really think this is mostly an explanation problem. I just don't get
it when you say: blind transfers behave like attended ones. An attended
transfer is the replacement of one call to another. A blind transfer is
a single call to any destination where no previous calls exists. I don't
see how a call can be replaced if it doesn't exist. I am hence confused :).
I might try with yet another softphone (I currently have
Linphone but doesn't seem to support blind transfers via GUI).
I guess I might need to do a sip debug on this.
Yup, or you can also send us the logs so that we can have a look at the
On 24.04.13, 13:34, Vieri wrote:
--- On Wed, 4/24/13, Emil Ivov <email@example.com> wrote:
It would probably help if you can elaborate on your definition of
attended transfer, because it feels to me that that this is where
some of the confusion is coming from.
The only difference between a blind  and an attended 
transfer is that with the former the transferee would start a new
call to the transfer target whereas in the latter she would replace
an existing call. In order for Jitsi to mistakenly perform an
attended transfer it would therefore need to accidentally create
and include in it's REFER request a replaces header with the proper
values for remote and local tags and call ID.
Obviously this is quite unlikely so I assume that what you are
experiencing is Asterisk behaving on way when calls are being
forwarded to the PSTN and another way when calls are transferred
to internal extensions. I am afraid that the most probably cause
that I can come up with is a misconfiguration (or a bug?) in
Hope this helps, Emil
 Blind Transfer Sample Flow:
http://tools.ietf.org/html/rfc5359#section-2.4  Attended
Transfer Sample Flow:
--sent from my mobile
On Apr 24, 2013 12:36 PM, "Vieri" <firstname.lastname@example.org> wrote:
I'm having issues with recent Jitsi builds when
performing blind transfers.
Jitsi clients and SIP hardphones connect to an Asterisk
PBX in our LAN. This PBX can route calls to DECT phones and other
extension types via a PRI link to another PBX.
If *any* extension (any type, from any PBX) calls any
Jitsi client (asterisk PBX) and the Jitsi client tries to do a
blind transfer to an extension within the "remote PRI-connected"
PBX, it succeeds.
However, if the Jitsi client tries to do the same to an
extension within the Asterisk PBX (eg. another Jitsi client) then
it "fails". It doesn't perform a blind transfer but an attended
Why is that?
Of course if I use the Asterisk built-in blind transfer
feature code, Jitsi can successfully do a blind transfer.
I'm not sure the Jitsi log reveals anything regarding
this unless I enable SIP debugging and I specifically dump it.
Before I do this, could this be a known issue / expected behavior /