[Home]

Summary:ASTERISK-19095: REGRESSION after r336294: Music on hold when sip call is put on hold doesnt work anymore after 1.8.8.0-rc1
Reporter:Stefan Schmidt (schmidts)Labels:
Date Opened:2011-12-22 02:33:05.000-0600Date Closed:2011-12-30 14:24:05.000-0600
Priority:BlockerRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.8.0 Frequency of
Occurrence
Constant
Related
Issues:
must be completed before resolvingASTERISK-19040 Asterisk 1.8.9.0 Blockers
must be completed before resolvingASTERISK-19041 Asterisk 10.1.0 Blockers
must be completed before resolvingASTERISK-19128 Asterisk 1.8.10 Blockers
is caused byASTERISK-17725 directmedia or reinvite not working when calling extension that's located an a different asterisk node
is caused byASTERISK-18340 CLONE - directmedia or reinvite not working when calling extension that's located an a different asterisk node
is related toASTERISK-19159 Asterisk fails to start MOH when SDP specifies connection IP of 0.0.0.0 only
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 1.8.8.1 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[1620]: 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 1.8.8.1 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.