| Summary: | ASTERISK-16296: MOH stops working after a few seconds and P2P bridging restarts despite still on hold! | ||
| Reporter: | alexr1 (alexr1) | Labels: | |
| Date Opened: | 2010-06-28 11:11:08 | Date Closed: | 2010-06-28 12:27:52 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/RTP |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Asterisk 1.4.33.1 Linksys SPA962 (02102) dials mobile phone 0411111111. Mobile phone answers, SPA962 puts mobile on hold. Music may or may not be heard. If music is NOT heard, Asterisk says Started music on hold, class 'default', on SIP/XXXXtel-0000003b Packet2Packet bridging SIP/02101-0000003a and SIP/XXXXtel-0000003b If music IS heard, then it will show: Started music on hold, class 'default', on SIP/XXXXtel-0000003b <music is heard for about 5 seconds> Packet2Packet bridging SIP/02101-0000003a and SIP/XXXXtel-0000003b As soon as Packet2Packet bridging is seen (and mind you, the call is STILL on hold), I start seeing errors like this: RTP Transmission error of packet to 0.0.0.0:0: Invalid argument It seems like there is something wrong with rtp.c?. In call queues, the music on hold plays perfectly fine. In Additional Information I have provided a CLI output (minus the RTP transmission errors, as they don't show up in the CLI, only in the log file which was since cleared). I have another Asterisk box running 1.4.33.1 (not identical configuration though), and I just can't seem to reproduce the problem on that box, only on the first one. Also in the additional information is where I have forced the phone's codec to something different from the VSP XXXtel so that no packet2packet bridging can take place. This results in normal, flawless operation of hold music. From this, I'm sure this has something to do with packet2packet bridging + moh. ****** ADDITIONAL INFORMATION ****** <removed inline debugs> - pabelanger | ||
| Comments: | By: Paul Belanger (pabelanger) 2010-06-28 11:34:39 Attach a debug log (see below) to tracker, do not post it as a comment. --- We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt By: alexr1 (alexr1) 2010-06-28 11:48:44 Unfortunately it is a production server that has over 1000 SIP endpoints registering and being used continuously. The amount of extra surplus information in the debug log would drown out the actual problem, making it difficult to isolate which lines relate to the call in question, and impede on the privacy of users of the system (without a lot of editing). Hopefully someone else will notice this problem on a less-used system that can provide the appropriate "isolated" debugging logs. This problem did not exist in 1.4.25 which was used with identical configuration before being upgraded to 1.4.33.1 By: Paul Belanger (pabelanger) 2010-06-28 12:27:52 Unfortunately, without any debug information there is not much we can do with this issue. I would suggest using http://www.asterisk.org/support to help troubleshoot your problems. Once the appropriate debug information has been gathered feel free to re-open this issue. | ||