Problems with call transfer

I’ve installed 2 differnt asterisk system, both using 1.6.2 and 1.8 versions.

And I’ve found same problem on both: If I make a call lets say to 12345678 (even local internal extensions calls) and the other party answers, then I can transfer the call If I want

But in the other side, If someone calls me, and I answer, and then I want to transfer the call, automatically the call hungs up:
From the CLI:

-- Started music on hold, class 'default', on SIP/sipprov-00000214
-- Stopped music on hold on SIP/sipprov-00000214

== Spawn extension (extensions, 1000, 1) exited non-zero on ‘SIP/sipprov-00000214’

For example the exten => 1000 dialplan is:

exten => 1000,1,NoOp()
exten => 1000,n,Answer
exten => 1000,n,Dial(SIP/ext1000,tT)
exten => 1000,n,Hangup

And sip.conf SIP ext 1000 is:


Can’t understand what can be happening!! :frowning: :frowning:

I’ve read all about Dial cmd docs and also tried multiple softphones and hardphones to checkout is not a problem of the phone (zoiper, ekiga, sjphone…)

Any ideas?

You should not be doing an Answer prior to the Dial. The Dial will attempt to ring a device and either it will be answered or not.

Ok, I deleted all Answers prior to all Dial commands… but this not resolved the problem :frowning:

Recently I’ve tried this with Zoiper softphone and same problem

But then I tried with Phone Thomson TB30 and it worked!

So no I believe this has something to do with softphones? SIP configuration? I followed the basic things, registrar and port, user and password nothing more… nothing else?

I’ve tried Zoiper with an IAX account and no success :frowning:

I have something new now.

I’ve downloaded a Bria trial version, and found it brings two options to transfer

  • Transfer Call
  • Call then transfer

With the first option, it doesn’t work, same as other softphones

But with Call then transfer, it works!

I did tried a Thomson TB30 and a Polycom IP450 and the did exactly the same transfer opertion: call then transfer.

This way,everything work fine.
But I don’t like this method, since the one that tranfers has to wait until other answers, instead of transfering the call and the counterpart has to wait, and you leave the phone unattended…

Maybe with this we can find something more clear about the problem

Ok, now I have clearly found the problem: I cannot do blind transfers.

I’m using Asterisk 1.8 with the configuration of the above messages.

But attended transfer work well. This is my dilema

In general, you are right that this is the correct behaviour, but it will work (and sometimes is required) to answer the call and begin dialing internal lines. The only difference is that even if no-one answers in the line, the caller will still be billed for the call because Asterisk answered the line. This is sometimes required if you have, for example, DISA or a requirement to use functions that cannot be passed before a line is answered. If you have no need to answer the line, then don’t do it.

Does call parking work for you? If you can park the call then that is one way around the problem (at least, until it’s solved) and may indicate the root of the problem.

You mean call park = hold the line? Example, you are talking and you hold the line (start moh)?

If is this, then yes, if not, I must find it out :smile:


Under the CLI i’ve found an error that repeats always I try to do a blind transfer:

[Nov 18 19:48:20] WARNING[1354]: chan_sip.c:3383 retrans_pkt: Retransmission timeout reached on transmission 4c702bb208f8806316b50e08696c8258@ for seqno 102 (Critical Request) – See doc/sip-retransmit.txt.
Packet timed out after 32000ms with no response

I’ve checked out by the way that parked calls work perfectly.

Can this error help a little bit more for a possible solution?

You mean call park = hold the line? Example, you are talking and you hold the line (start moh)?

If is this, then yes, if not, I must find it out :smile:


No, a call park is where you transfer a call to an extension (it’s typically 700 on Asterisk) and then a third party calls the extension and gets connected to the call. For example, if you do an attended transfer to 700 then Asterisk will say to you “Seven Zero One” and hang up the call. Anyone who calls 701 will then be connected to the parked call. The caller you transferred will be given Music-On-Hold until they are answered. Typically, a default of 300 seconds (5 minutes) is given to the person expecting the call to dial that extension before it is sent back to the person who parked it.

It’s a useful feature (enabled in /etc/asterisk/features.conf) in a situation where a receptionist picks up a call, parks it and then makes an announcement over a PA system for the person to find a phone, pick it up and dial the required parking space in order to be connected.

Anyway, I digress, any problems with this I suspect will help with finding the real fault or, at the very least, give you an indication or clue as to what’s wrong.

Yes, it says seven zero one, call park works well

I believe this has somthing to do with sip protocol, but I don’t know how to sip debug…

Where can I find some info about sip debuging?

All I know is to activate in CLI sip set debug on… but problem is basically that loggin is not good enough… it is possible to debug sip log into a file?


OK, now that we know that call parking works with an attended transfer, can you try an unattended transfer to 700? The call will still be parked in the first slot (701) but Asterisk won’t be able to tell you that. If the call is aborted there then it’s more likely to be a problem with the transfer mechanism itself rather than the SIP protocol. Call parking is an internal structure of Asterisk and isn’t SIP, IAX, Zap or whatever.

I’m building up a picture here to know where to look further but I’ve never heard of this behaviour before…

Me extension 10, call extension 20

Extension 20 makes an unattended transfer to 700

Extension 20 hears “701”

Extension transfers 700 to 10

10 still hears MoH

Extension 20 calls extension 701

extension 20 can talk with extension 10 back.

So Call Park works perfect.

I definitely Belive problems has something to do with SIP channel… problem is debugging. I don’t know how to debug SIP to a File instead of debugging directly from CLI (that is pretty difficult since messages pass too quickly)