Summary:	ASTERISK-09372: Starting Musiconhold causes CANCEL
Reporter:	Christian Benke (christianbee)	Labels:
Date Opened:	2007-05-03 05:09:51	Date Closed:	2011-06-07 14:03:13
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_musiconhold
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) extensions.conf ( 1) moh_error_asterisk_verbose_debug.txt ( 2) tcpdump_polycom_error_expanded.txt ( 3) tcpdump_polycom_error_simple.txt ( 4) tcpdump_polycom_working_expanded.txt ( 5) tcpdump_polycom_working_simple.txt ( 6) tcpdump_siemens_error_expanded.txt ( 7) tcpdump_siemens_error_simple.txt ( 8) verbose
Description:	After upgrading from 1.2.9.1 to 1.4.2 and later 1.4.4 i experienced a very bothersome problem with musiconhold. Some of my calls to extensions where MOH is used are beeing cancelled immediately by asterisk. I can always reproduce this issue with a SIEMENS C450 IP, sometimes(1 in 5 calls) with Polycoms(430/601/650). So far it didn't happen with a Linksys SPA942. I've prepared a very simple dialplan, see the attached extensions.conf, as soon as the MOH is started, i receive a error message about "Maximum retries exceeded" and  "no reply to critical packet" and asterisk sends a CANCEL(The B-Client gets one interrupted ring). When no musiconhold is used, the call works as expected. I've attached tcpdumps of 3 different calls, one with the SIEMENS where the error occurs: tcpdump_siemens_error_simple.txt, tcpdump_siemens_error_expanded.txt one of a call with a polycom 601 where the error didn't happen: tcpdump_polycom_working_simple.txt, tcpdump_polycom_working_expanded.txt one call of the same polycom where the error occurs: tcpdump_polycom_error_simple.txt, tcpdump_polycom_error_example.txt i've exported two views of each call for ease of debugging, hope thats fine I've also attached the verbose-debug of a failing siemens call, basically the error-message is the same for the polycoms. The B-UA in the examples was always a Polycom, but it also happens with other UAs(Users reported that it also happens for calls to the pstn, but i couldn't confirm it)
Comments:	By: Christian Benke (christianbee) 2007-05-03 05:20:04 about the IP-adresses: 2xx.xxx.xxx.2 - the asterisk 2xx.xxx.xxx.1 - openser(for registration and rtpproxy) 8xx.xxx.xxx.100 - John/John2-UA-IP(The Sender-Client) By: Joshua C. Colp (jcolp) 2007-05-03 10:43:16 We need to see a sip debug so we can see what chan_sip is doing and thinking. By: Christian Benke (christianbee) 2007-05-04 05:14:05 thx to the request for a sip-debug i found out that the problem is the qualify-parameter in sip.conf. i had to use a second server to get a clean debug, where the qualify was not set in the openser-context. My openser is not natted of course, guess the qualify-setting was very old and untouched since then. After removing it, it works fine. However, i'm not sure if this bug can be closed as the  behaviour still seems awkward to me. I've attached the verbose-debug(with qualify=yes) you asked for... 2xx.xxx.xxx.x11 is the test-openser(openser2.mydomain.org) 2xx.xxx.xxx.x12 is the test-asterisk(asterisk2.mydomain.org) john3 calls nancy in this case, dialplan is the same By: Christian Benke (christianbee) 2007-05-04 05:22:05 another conclusion i just found(seems i missed this due to much debugging in the last days, i always had the impression that MOH causes it): it doesn't matter if musiconhold is used or not, the call can be setup if qualify is off and gets a CANCEL if qualify=yes. So the bug report doesn't seem to be related to musiconhold fyi: there is no nat between the openser/asterisk-hosts By: Joshua C. Colp (jcolp) 2007-06-07 13:58:15 The attached sip debug clearly shows that chan_sip sent a 200 OK to the device to indicate that the call was answered (so it could play music on hold) however it never received an ACK back from the device. This could be caused due to a misconfigured OpenSER or the remote device's SIP stack. I'm not convinced that this is the fault of chan_sip at all and if you can provide more debug information showing that it is, please feel free to reopen.