| Summary: | ASTERISK-04273: Zombies, MOH, and Bad Transfers | ||
| Reporter: | drmac (drmac) | Labels: | |
| Date Opened: | 2005-05-25 12:08:11 | Date Closed: | 2011-06-07 14:04:40 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | I've posted this to the -dev list twice now and no response recieved whatsoever. (All of this is HEAD and all phones are Cisco 7960s). This only seems to happen on Zap -> SIP - xfer -> SIP calls. (Phone A calls Phone B.) -- Executing Dial("Zap/2-1", "SIP/3030|15") in new stack -- Called 3030 -- SIP/3030-bf07 is ringing -- SIP/3030-bf07 answered Zap/2-1 (Phone B hits "Transfer". This places caller A on hold (hears music)). -- Started music on hold, class 'default', on Zap/2-1 (Phone B dials Phone C.) -- Executing Dial(SIP/3030-9627", "SIP/3087|15") -- Called 3087 -- SIP/3087-cfce is ringing -- SIP/3087-cfce answered SIP/3030-9627 Phone B and Phone C talk. Phone B presses "Transfer" again to do the transfer. Here is the interesting part: Phone C "hears" MOH. But when phone C speaks, Phone A can hear his speech. When Phone A speaks, Phone C cannot hear it (C is hearing MOH). -- Attempting native bridge of SIP/3030-9627 and SIP/3087-cfce -- Started music on hold, class 'default', on SIP/3087-cfce -- Stopped music on hold on Zap/2-1 Why would music be started on 3087? Seems it wasn't released. I know you guys really need a SIP debug, but I tried this same thing again (to get the debug) and it worked fine except this time I got this: -- Executing Dial("Zap/2-1", "SIP/3030|15") in new stack -- Called 3030 -- SIP/3030-f674 is ringing -- SIP/3030-f674 answered Zap/2-1 -- Called 3087 -- SIP/3087-51e0 is ringing -- SIP/3087-51e0 answered SIP/3030-1ba9 -- Attempting native bridge of SIP/3030-1ba9 and SIP/3087-51e0 -- Started music on hold, class 'default', on SIP/3087-51e0 -- Stopped music on hold on Zap/2-1 -- Stopped music on hold on SIP/3087-51e0 -- Attempting native bridge of SIP/3030-1ba9<ZOMBIE> and SIP/3030-f674 WARNING: Can't fine native functions for channel 'SIP/3030-1ba9<ZOMBIE>' WARNING: Private bridge between SIP/3030-1ba9<ZOMBIE> and SIP/3030-f674 failed. Any ideas? I thought this was a problem with the phone, but after several phones did it, I figured it can't be. In fact, I just got a report of this happening on a phone that it never happened on before. ****** ADDITIONAL INFORMATION ****** Since the bug guidelines page is 404 Not Found as of 11:54AM CDT on 5/25/05, I can't be punished for not reading them when choosing severity. Also, we haven't tried using the built-in ASTERISK-4 transfer ability. Why? Because when you present a nice cisco phone to a multi-million dollar company, you can't say "well, you can't use that transfer button. you have to do this instead." | ||
| Comments: | By: Olle Johansson (oej) 2005-05-26 02:22:57 What can I say? The SIP transfer support in Asterisk is, to be nice, an "early proof-of-concept alpha-stage" implementation. I am working on this. There are other open bug reports on transfer, so I would like to close this one. Not because you are wrong, but because this can be seen as a duplicate. By: Michael Jerris (mikej) 2005-05-26 06:54:18 oej. Can we tie this issue to a specific bug so we can close it? By: drmac (drmac) 2005-05-31 09:36:45 Any news on this? I just recieved two more reports from office workers about this problem. Seems to happening more and more often. By: David Gomillion (dgomil) 2005-05-31 19:56:37 I too am experiencing something like this. It appears to happen when a REFER is sent without the other SIP phone being connected. I cannot always duplicate it, but I do have full debug logs of this happening (not with me, at work). If desired, I can post this. By: Mark Spencer (markster) 2005-06-02 13:53:23 Debug would be useful. By: Clod Patry (junky) 2005-06-13 12:04:34 drmac: could you attach any debug please so we can close that bug. By: David Gomillion (dgomil) 2005-06-13 12:17:03 I have resolved this issue with our Polycom phones by upgrading the firmware. The way that Polycom seems to have resolved the issue is to not allow the transfer to be completed until the remote party (transfer recipient) has answered the phone. By: Clod Patry (junky) 2005-06-13 12:41:37 great to hear, drmac: could you confirm your problem is now resolved for you too? By: drmac (drmac) 2005-06-13 13:18:00 We are using all Cisco 7960's in our office. I just talked with the person who has reported this in the past and she says she it hasn't had it happen for a few days. I guess close it for now and I'll reopen once I have a trace. By: Michael Jerris (mikej) 2005-06-13 13:23:58 Closed at reporters request pending further information. By: drmac (drmac) 2005-07-06 15:16:08 trace and call flow attached to ASTERISK-4308 By: Olle Johansson (oej) 2005-07-20 13:10:51 Closing this in favour of ASTERISK-4308 | ||