Summary:ASTERISK-01655: Call hangs up after a while when "#" transfer to SIPtone IP phone
Reporter:tan (tan)Labels:
Date Opened:2004-05-19 13:23:46Date Closed:2011-06-07 14:05:10
Versions:Frequency of
Environment:Attachments:( 0) ethereal.zip
Description:We have a situation where the SIPtone (from ipDialog) phones hang up when a "#" transfer is made from one IP phone (e.g. cisco 7960) to the SIPtone. The call is transferred, and then it will hangup after what seems to be a random time interval (varying from a few seconds to just over a minute). I am not sure where the problem is. We have also escalated this with the manufacturer, but the problem doesn't seem to occur when a transfer is done using the transfer capability of the phone.


Enclose ethereal traces of 3 incidents where the call has hungup after a transfer.
Comments:By: Mark Spencer (markster) 2004-05-19 15:47:12

Am I missing something?  It looks like .252 is the Asterisk box and .121 is the other device.  Looking at each of these traces, the IP-Dialog disconnects the call and there are no messages from either side between the Asterisk sending ACK and the IP-Dialog sending BYE...

By: tan (tan) 2004-05-19 16:40:23

Yes, .121 and .252 are SIPtone and * respectively. If the SIPtone is initiating a BYE, then it thinks the call is over. But doesn't the rtp data between the ack and the bye reflect that the conversation was taking place? I am looking at siptone_19May2004-5-transfer file.

By: Mark Spencer (markster) 2004-05-19 17:02:54

the BYE is the first indication that the call is terminating.  I don't mean to sound like a blame-the-other-guy-first, but in the absense of any other meaningful theory, I can see no reason why the device should be determining the end of the call has taken place.  I imagine it's more likely some sort of internal timer issue on the endpoint.

By: tan (tan) 2004-05-20 07:42:07

The issue is being pursued with ipDialog. I will update once we have a resolution.

By: Mark Spencer (markster) 2004-05-20 10:07:51

I'm going to close this one out as "not a bug".  If you get any information that you believe indicates that it *is* in fact an Asterisk bug, feel free to re-open it.