Summary:	ASTERISK-19159: Asterisk fails to start MOH when SDP specifies connection IP of 0.0.0.0 only
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2012-01-03 11:47:47.000-0600	Date Closed:	2012-01-03 12:21:30.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General Resources/res_rtp_asterisk
Versions:	1.8.8.1 10.0.0	Frequency of Occurrence	Constant
Related Issues:	is related to ASTERISK-19095 REGRESSION after r336294: Music on hold when sip call is put on hold doesnt work anymore after 1.8.8.0-rc1
Environment:		Attachments:
Description:	When resolving ASTERISK-19095, a test was written to check SIP Hold.  Initially, only two scenarios were considered: 1) The media stream being restricted by setting the audio send direction to receive only 2) The media stream being restricted by setting the audio send direction to receive only, along with a connection IP address of 0.0.0.0 The test scenarios were originally written as such to test the SIP traffic identified in ASTERISK-19095, and it did reproduce the problem.  Unfortunately, after the changes were made to resolve the problem identified in that version, a new test was created that only sent a connection IP address of 0.0.0.0. While Asterisk behaves correctly from the perspective of the SIP messaging, it fails to fully put the call on hold and start MOH. What does happen: [Jan  3 11:07:28] DEBUG[8846] chan_sip.c: Bridge still active.  Delaying destroy of SIP dialog '1-8883@127.0.0.2' Method: ACK [Jan  3 11:07:28] DEBUG[8846] chan_sip.c: Bridge still active.  Delaying destroy of SIP dialog '543ca48003d2ebfc3b74c540604e99ca@127.0.0.1:5060' Method: INVITE [Jan  3 11:07:28] DEBUG[8884] res_rtp_asterisk.c: Setting the marker bit due to a source update [Jan  3 11:07:28] VERBOSE[8846] chan_sip.c: What should happen: [Jan  3 11:07:21] DEBUG[8881] channel.c: Scheduling timer at (50 requested / 50 actual) timer ticks per second [Jan  3 11:07:21] DEBUG[8881] res_rtp_asterisk.c: Setting the marker bit due to a source update [Jan  3 11:07:21] DEBUG[8869] manager.c: Examining event: Event: MusicOnHold Privilege: call,all State: Start Channel: SIP/phone_A-00000006 UniqueID: 1325610438.6 Class: default Note that this is NOT a regression from 1.8.6, 1.8.7.2, or 1.8.8.0.  This behavior didn't work in any of those versions either.  The problem originally seen in ASTERISK-19095 was still resolved in 1.8.8.1, as the Cisco phone in question restricted the IP address and the media stream (and the problem really was in that case the local bridge exiting early)
Comments:	By: Matt Jordan (mjordan) 2012-01-03 12:21:30.601-0600 I knew this looked familiar.  Duh.  I fixed this in ASTERISK-18086, which is destined for 1.8.9. There is a huge gap between 1.8.8 and 1.8.9.  Yuck.