|Summary:||ASTERISK-19095: REGRESSION after r336294: Music on hold when sip call is put on hold doesnt work anymore after 22.214.171.124-rc1|
|Reporter:||Stefan Schmidt (schmidts)||Labels:|
|Date Opened:||2011-12-22 02:33:05.000-0600||Date Closed:||2011-12-30 14:24:05.000-0600|
|Environment:||debian 6.0 in an openvz container.||Attachments:||( 0) mohproblem|
( 1) r1640-extensions.conf
( 2) r1640-sip.conf
|Description:||Phone A calls Phone B (both sip channels) with Dial(SIP/Phone-B,60,m(test)). while Phone-B doesnt answer the call i can hear the music from the moh class test.|
Phone B answer the call, moh stops and i can hear audio both ways.
Phone B puts call on hold (Reinvite with sdp description c=IN IP4 0.0.0.0 and a=sendonly.
Asterisk now removes the instance of Phone-B of the local bridge in local_bridge_loop -> rtp_engine.c but didnt start the musiconhold process on the Phone A channel.
as you can see on the attached debug (row 933) the moh is started on the right channel and the local_bridge_loop get the source update and also returns from the native bridge but then restart the local bridging (row 937).
I have traced down the problem to the AST_CONTROL_UPDATE_RTP_PEER in handle_request_invite (this row: http://www.asterisk.org/doxygen/asterisk1.8/chan__sip_8c-source.html#l22827) but this is only a fix to prevent it and not to really make it work
|Comments:||By: Stefan Schmidt (schmidts) 2011-12-22 08:59:09.518-0600|
part of extensions.conf used for testing
By: Stefan Schmidt (schmidts) 2011-12-22 08:59:38.434-0600
general part and user part of sip.conf used for testing
By: Matt Jordan (mjordan) 2011-12-23 13:57:06.283-0600
Stefan - which SIP phones are you using? I've been unable to reproduce this using two Polycom IP 430s. The only difference I can tell between the scenarios is that the Polycom's, when putting the call on hold, don't populate the SDP c= line with an address of 0.0.0.0 - they use the IP of the Asterisk instance. Otherwise, the call flow looks to be the same, including the use of the local_bridge loop in rtp_engine.
By: Stefan Schmidt (schmidts) 2011-12-23 16:09:28.311-0600
Matt i have used several types of Cisco phones like Cisco SPA 941,962,504,525 and the customer who reported this to me also have a cisco Pap2t in use.
i was also able to reproduce this with Ninja Softclient which also sends c=IN IP4 0.0.0.0. So maybe you can try this with this softclient.
By: Matt Jordan (mjordan) 2011-12-28 14:35:20.118-0600
No luck with Ninja either. That being said I've written a few SIPp scenarios that I'll check into the Asterisk testsuite that have reproduced, to an extent, what you're seeing. I don't have any problems with MOH (and, based on your logs, it looks like MOH is trying to start as well) - but I have reproduced some nasty problems in the local bridge. Currently, if it gets one of the RTP update control frames it will actually exit the local bridge loop - which, if you're coming off of hold (which is when it happens in the test scenario), causes all sorts of interesting behavior.
I'm getting closer to a patch for this, but I want to make sure there aren't any other areas that we've missed with this control frame.
By: Matt Jordan (mjordan) 2011-12-29 09:02:41.238-0600
Stefan - As I'd like to get 126.96.36.199 rolling asap, I'm going to go ahead and commit your patch today.
By: german aracil boned (tucall) 2012-01-12 15:38:24.592-0600
rtp timeout bug persist. Its the same problem ? Making softhangup to any call:
[Jan 12 22:35:00] NOTICE: chan_sip.c:25604 check_rtp_timeout: Disconnecting call 'SIP/trunk_wb10-0000106f' for lack of RTP activity in 31810 seconds
in sip.conf: rtptimeout=30 !
By: Stefan Schmidt (schmidts) 2012-01-13 01:41:07.811-0600
imho it could be related but i am not sure.
normally this problem only is about a new added control frame for calls being in a bridge (either local or remote). when this call is localy bridged (so no directmedia is used) before 188.8.131.52 when one call is put on hold the bridge is not cleanly closed so the audio stream from moh doesnt reach the client which is put on hold.
IMHO it is possible that rtptimeout will not work out of this, but only for a call which was involved in a local bridge an put on hold before.