[Home]

Summary:ASTERISK-10278: Doing an attended transfer, asterisk tries multiple times a native bridge
Reporter:Theo Belder (tbelder)Labels:
Date Opened:2007-09-11 03:28:36Date Closed:2007-10-08 09:44:38
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) snom.cap
( 1) thomson.cap
( 2) verbose3.txt
( 3) verbosedebug.txt
Description:When doing an attended transfer, the cli shows 'Native bridging SIP/403-090e0088 and SIP/401-090e1790' more then 200 times. You can see it in verbose3.txt
Although the transfer is successful.

Using Thomson 2030st and hanging up the transferred call, both phones rings again. You can see this in thomson.cap
Using Snoms, this isn't happening. You can see this in snom.cap


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

verbose3.txt shows a simple transfer, verbosedebug show also a simple transfer with debugging (debug level 4, verbose level 4, sip debugging):
SIP/403 calls SIP/401 -> answered
SIP/401 calls SIP/404 -> answered
SIP/401 performs a attended transfer
SIP/403 and SIP/404 hang up

thomson.cap: trace on the network inferface of the asterisk box
SIP/1606 calls SIP/1605 -> answered
SIP/1605 calls SIP/1604 -> answered
SIP/1605 performs a attended transfer
SIP/1606 and SIP/1604 hang up
SIP/1606 and SIP/1065 are ringing again

snom.cap: trace on the network inferface of the asterisk box
SIP/1612 calls SIP/1611 -> answered
SIP/1611 calls SIP/1613 -> answered
SIP/1611 performs a attended transfer
SIP/1612 and SIP/1613 hang up

snom.cap and thomson.cap are made at another asterisk box yesterday, but shows the same cli messages.


When turning off canreinvite, these problems aren't happened....
Comments:By: Ramon Peek-Fares (ramonpeek) 2007-10-08 06:24:00

Hello everyone!
I'm a colleague of the reporter of this issue (tbelder)
And I've looked into this issue as well

It seems the CLI showing; 'Native bridging SIP/403-090e0088 and SIP/401-090e1790' over more then 200 times is nearly a side effect of what is really going wrong.

What is really happening is that Thomson, but also Polycom, phones put the active call leg on hold first and then transfer the call by sending the REFER request.
Snom phones on the other hand send the REFER immediately and by doing that they skip a problem that exists in Asterisk.

It seems Asterisk send 2 re-invites in order to put the call back on hold, where there should actually be send only one.
(I spoke to Olle Johannson about this and he somehow noticed this, thanks Olle!)

There are another issues in the bugtracker that actually are the same as this issue.. see issue 10868 for a more detailed explaination.
By: Digium Subversion (svnbot) 2007-10-08 09:43:08

Repository: asterisk
Revision: 84990

U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r84990 | file | 2007-10-08 09:43:07 -0500 (Mon, 08 Oct 2007) | 4 lines

Don't keep trying to native bridge if either of the channels are involved in a masquerade operation to be done.
(closes issue ASTERISK-10278)
Reported by: tbelder

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-10-08 09:44:38

Repository: asterisk
Revision: 84991

_U  trunk/
U   trunk/main/channel.c

------------------------------------------------------------------------
r84991 | file | 2007-10-08 09:44:37 -0500 (Mon, 08 Oct 2007) | 12 lines

Merged revisions 84990 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r84990 | file | 2007-10-08 12:03:07 -0300 (Mon, 08 Oct 2007) | 4 lines

Don't keep trying to native bridge if either of the channels are involved in a masquerade operation to be done.
(closes issue ASTERISK-10278)
Reported by: tbelder

........

------------------------------------------------------------------------