[Home]

Summary:ASTERISK-15779: Transfer fails
Reporter:Ismailov Rafael (timehider)Labels:
Date Opened:2010-03-09 10:16:18.000-0600Date Closed:2010-05-10 11:00:57
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) log_sip.txt
( 1) log.txt
( 2) r260757_debug.txt
( 3) r260757_siptrace.pcap
( 4) siptrace
( 5) user.txt
Description:I use transfer button on Cisco Phone with sip firmware, at first push it calls the person to which I want to transfer the call. When the person answers and I push transfer button second time, to transfer the call, on display appear notice that "transfer failed". Both of calls are put onhold. Transfered person hear lagging music on hold or silence.

****** ADDITIONAL INFORMATION ******

I'd tested it on Cisco phones 7940/7960 with sip firmware 8-12-00. Blind transfer works fine.
Both calls can be resumed.
Comments:By: Leif Madsen (lmadsen) 2010-03-10 10:27:56.000-0600

A SIP trace of this call is definitely going to be needed. The information presented thus far does not give enough detail to determine where the problem lies.
By: Ismailov Rafael (timehider) 2010-03-10 10:45:58.000-0600

New file attached. Other information?
By: Paul Belanger (pabelanger) 2010-04-28 15:52:26

Seems this fell through the cracks.  Are you able to try again using the latest trunk version? This way we can re-triage the issue.
By: David Woolley (davidw) 2010-04-28 17:36:45

Asterisk is rejecting (on the NOTIFY) REFER/Replaces with:

SIP/2.0 481 Call leg/transaction does not exist

However the callid does seem to exist.  The to-tag and from-tag are also good, unless they are the wrong way round.
By: Ismailov Rafael (timehider) 2010-05-04 07:57:11

I had tried again on trunk-r260757 but seems the problem is still here.
By: Leif Madsen (lmadsen) 2010-05-04 16:17:35

Do you get the same issue whether you put someone on hold or not? The reason I ask is because of issue ASTERISK-16050
By: Ismailov Rafael (timehider) 2010-05-05 10:48:03

Blind transfer feature seems to work well. Only the transfer with putting the caller on hold leeds to message: Transfer failure. Seems that issue 0017284 is the same as mine.

I'll explain it. In my case when the transfer failure appears both calls are set on hold and if transfering phone then hangs up then both calls are disconnected.
Seems that the signal for transfering the call in issue 0017284 is a hang up, so the transfer failure appears, both calls are set on hold but because transfering phone is already hanged up both calls then disconnect.
By: David Woolley (davidw) 2010-05-05 10:59:41

As I noted on ASTERISK-1704284, hangup doesn't signal Asterisk to complete the transfer.  As far as Asterisk, or any other proper SIP user agent, is concerned, there are two completely separate calls, which, incidentally would require two separate hangups.

It is quite possible that hanging up the phone handset causes the phone to complete the transfer, but not by sending hangup (BYE method).

Your trace actually shows an attempt to properly complete a transfer, by sending a REFER request, with a Replaces attribute, on the Refer-To header.  It does not show a hangup.  I cannot see anything wrong with that request, but Asterisk is saying that it doesn't know about the call that the transferred channel is being connected to.

Blind transfers don't use a Replaces attribute, so there is no question of finding and matching another call.
By: David Woolley (davidw) 2010-05-05 11:13:03

The basic way that SIP transfer work is that:

The initial call is set up, in either direction;

The enquriy call is set up, as a completely separate call;

The initial call is sent a REFER request, specifying the SIP address used for the second call and the call ID and other identifying tags for the second call;

Conceptually the first caller then makes a new call to the number of the second callee, passing the identifying information for that call;

It also uses NOTIFY requests to forward its progress on that call to the transferror;

The device on the second line matches up the call identity, and, instead of starting a new transferred call, joins the two calls together;

The two remote parties then send BYEs to the the transferror.

Because you are not talking directly to the two remote parties, but actually to Asterisk, the call following the REFER happens purely internally in Asterisk, although the NOTIFYs are still generated.

In this case, the NOTIFY is saying that the "remote" end of internal call failed to match the call id and other information against any call, even though it looks to me that a matching call is still in progress.
By: David Woolley (davidw) 2010-05-06 04:21:06

If it applies to the version you are using, the bug that is fixed by the patch for ASTERISK-1704284 would produce the the failure that you are observing.
By: Ismailov Rafael (timehider) 2010-05-06 09:15:24

It seem's that in the latest revision the problem is solved (r261451). But I'll test it for some more time, because at first time it appeared after a while from the moment of starting asterisk.


By: Leif Madsen (lmadsen) 2010-05-10 11:00:56

Closing this issue as fixed. Please reopen if you feel it has not been resolved.