Hello,
Well I was having transfer issues in 1.2.9.1 so I downgraded to 1.2.7.1.
For testing I installed 1.2.10 on a test server and setup two Polycom
SIP phones. Tried the transfer on this configuration and had the same
issues. Here is a log from the console:
This is how the flow goes:
Outside call from the PSTN to ext 1678.
1678 hits transfer button and dials 2175.
2175 answers call, speaks, then 1678 hits transfer again.
After that call just goes blank and we get nothing. Is there a fix for
this in the latest build?
Thank you!
-Dan
## INCOMING CALL FROM PSTN
== Spawn extension (ANC, 1678, 2) exited non-zero on
'SIP/10.25.118.2-09807428'
-- Executing Goto("SIP/10.25.118.2-09807428",
"ANC|1678|1") in new
stack
-- Goto (ANC,1678,1)
-- Executing Answer("SIP/10.25.118.2-09807428", "") in
new stack
-- Executing Dial("SIP/10.25.118.2-09807428",
"SIP/1678|20|r") in
new stack
-- Called 1678
-- SIP/1678-0980cee0 is ringing
-- SIP/1678-0980cee0 answered SIP/10.25.118.2-09807428
## ANSWERED OUTSIDE CALL
-- Attempting native bridge of SIP/10.25.118.2-09807428 and
SIP/1678-0980cee0
## TRANSFER BUTTON PUSHED
-- Started music on hold, class 'default', on channel
'SIP/10.25.118.2-09807428'
-- Stopped music on hold on SIP/10.25.118.2-09807428
-- Executing Answer("SIP/1678-098127f8", "") in new
stack
-- Executing Dial("SIP/1678-098127f8", "SIP/2175|20") in
new stack
-- Called 2175
-- SIP/2175-0981d390 is ringing
-- SIP/2175-0981d390 answered SIP/1678-098127f8
## OTHER END ANSWERED TRANSFER REQUEST, WARM TRANSFER INITIATED
-- Attempting native bridge of SIP/1678-098127f8 and
SIP/2175-0981d390
-- Attempting native bridge of SIP/10.25.118.2-09807428 and
SIP/1678-0980cee0
-- Attempting native bridge of SIP/10.25.118.2-09807428 and
SIP/1678-0980cee0
^^^^ REPEATED MANY TIMES ^^^^
== Spawn extension (ANC, 1678, 2) exited non-zero on
'SIP/1678-098127f8<ZOMBIE>'
-- Got SIP response 500 "Internal Server Error" back from
10.25.118.2
== Spawn extension (ANC, 2175, 2) exited non-zero on
'SIP/10.25.118.2-09807428'
-- Incoming call: Got SIP response 500 "Internal Server Error"
back
from 10.20.6.78
## AND NOW THE CALL IS DEAD
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20060719/df00233b/attachment.htm
On 7/19/06, Dan Brummer <dan.brummer@vegas.com> wrote:> Hello, > Well I was having transfer issues in 1.2.9.1 so I downgraded to 1.2.7.1. > For testing I installed 1.2.10 on a test server and setup two Polycom SIP > phones. Tried the transfer on this configuration and had the same issues. > Here is a log from the console: > > This is how the flow goes: > > Outside call from the PSTN to ext 1678. > 1678 hits transfer button and dials 2175. > 2175 answers call, speaks, then 1678 hits transfer again. > > After that call just goes blank and we get nothing. Is there a fix for this > in the latest build?Suggestions: Firstly, check that there is no newer firmware for the Polycom SIP phones - If this were a common issue in Asterisk, I expect we'd be hearing about it a lot more... Secondly, capture a SIP trace of what is happening - It may be related to an attempt to negotiate codecs between the SIP phones, or numerous other things. Also, does it work if you set 'canreinvite=no' to keep asterisk in the call path? Worth checking, even if it is not a setting you plan on keeping. Regards, Steve
Setting canreinvite=no on all the sip peers and gateway made the warm transfer work. I'm still noticing <ZOMBIE> SIP entries, is this an issue? == Spawn extension (ANC, 1691, 2) exited non-zero on 'SIP/1691-09766938<ZOMBIE>' Thank you, Dan -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Steve Davies Sent: Thursday, July 20, 2006 1:45 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Warm transfer issues in 1.2.10 On 7/19/06, Dan Brummer <dan.brummer@vegas.com> wrote:> Hello, > Well I was having transfer issues in 1.2.9.1 so I downgraded to1.2.7.1.> For testing I installed 1.2.10 on a test server and setup two Polycom > SIP phones. Tried the transfer on this configuration and had the sameissues.> Here is a log from the console: > > This is how the flow goes: > > Outside call from the PSTN to ext 1678. > 1678 hits transfer button and dials 2175. > 2175 answers call, speaks, then 1678 hits transfer again. > > After that call just goes blank and we get nothing. Is there a fix > for this in the latest build?Suggestions: Firstly, check that there is no newer firmware for the Polycom SIP phones - If this were a common issue in Asterisk, I expect we'd be hearing about it a lot more... Secondly, capture a SIP trace of what is happening - It may be related to an attempt to negotiate codecs between the SIP phones, or numerous other things. Also, does it work if you set 'canreinvite=no' to keep asterisk in the call path? Worth checking, even if it is not a setting you plan on keeping. Regards, Steve _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Thank you Steve, I greatly appreciate the assistance. -Dan -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Steve Davies Sent: Thursday, July 20, 2006 9:16 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Warm transfer issues in 1.2.10 On 7/20/06, Dan Brummer <dan.brummer@vegas.com> wrote:> Setting canreinvite=no on all the sip peers and gateway made the warm > transfer work. I'm still noticing <ZOMBIE> SIP entries, is this an > issue? > > == Spawn extension (ANC, 1691, 2) exited non-zero on > 'SIP/1691-09766938<ZOMBIE>' >I think the ZOMBIE entries are fairly normal. I believe they happen when certain events happen in a certain order, and then tidy up afterwards. I can only suggest that a SIP trace of an attended transfer while canreinvite=yes might indicate the source of your problem more accurately. Cheers, Steve _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users