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:46 | Date Closed: | 2011-06-07 14:05:10 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
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. ****** ADDITIONAL INFORMATION ****** 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. |