[Home]

Summary:ASTERISK-20642: Occasional audio failure after placing call on hold
Reporter:Jeremy Pepper (jpepper)Labels:
Date Opened:2012-11-01 15:07:53Date Closed:2012-11-19 10:24:26.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:11.0.0 Frequency of
Occurrence
Occasional
Related
Issues:
is related toASTERISK-20633 Asterisk SIP channel handling of MOH media re-INVITES not RFC 3264 compliant
Environment:Attachments:( 0) holdissue.0
Description:I've run into an intermittent issue placing calls on hold: when they're taken back off hold, the call's audio does not resume.

I have encountered this issue without explicitly trying; however, reproducing it reliably is a bit of a pain. I've been placing a SIP call through the system to another server on our network that acts as a test target. I'll rapidly hold and unhold the call until the audio goes dead. Right as the problem occurs, Asterisk logs this:

{noformat}    -- Started music on hold, class 'default', on SIP/TheAnswer-00000003{noformat}

That message doesn't appear before then. Repeating the same procedure (cycling hold and unhold) eventually brings the call audio back.
Comments:By: Matt Jordan (mjordan) 2012-11-01 15:30:45.968-0500

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: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please make sure 'sip set debug on' is also enabled in the DEBUG log.

By: Jeremy Pepper (jpepper) 2012-11-01 15:52:40.106-0500

I've attached the debug log. The failure happens around line 32184 (timestamp Nov  1 15:44:20).

By: Michael L. Young (elguero) 2012-11-01 22:36:07.097-0500

I think I see what the problem is.

Can you set "ignoresdpversion=yes" for the Cisco phone?  Let us know if that solves this.

From your debug log, I am seeing the following issue.  The SDP Session Version is not being set properly by the Cisco.  The session version is supposed to increment as a way to notify that there is a change to be processed.  The session version number from the Cisco is bouncing all over the place every time you place the call on hold and then off of hold.

The SDP session version starts with "21354" (initial call)
o=Cisco-SIPUA 26547 21354 IN IP4 192.168.2.121
c=IN IP4 192.168.2.121

Next it is "18471" (placed on hold)
o=Cisco-SIPUA 20264 18471 IN IP4 192.168.2.12
c=IN IP4 0.0.0.0

Next, "28044" (off hold)
o=Cisco-SIPUA 6434 28044 IN IP4 192.168.2.121
c=IN IP4 192.168.2.121

Next, "24481" (on hold)
o=Cisco-SIPUA 10982 24481 IN IP4 192.168.2.121
c=IN IP4 0.0.0.0

And it continues doing this every time you put a call on hold and off of hold.  Then you hit what is causing your problem.  Here is what causes a problem.

We start out at "21354".  Everything is good.
The next one is "18471".  We ignore the SDP because the version number didn't increment by one.  Instead it is less than the first version number.  So, we ignore the SDP and continue.

As you keep placing the call on hold, off hold, the different version numbers keep being sent and we continue to ignore the "on-hold" SDP information from the Cisco because the number happens to be less than the highest SDP session version number that we have received so far.

But, we do eventually hit a bigger number, "28044".  We then process the SDP.  This happens to be when you take the call off of hold and we have the RTP address of 192.168.2.121 still.  Everything continues as normal.

Then you eventually hit a version number that is high enough to trigger the processing of the SDP when the call goes on hold. The number is "28112".  We change the RTP address to "0.0.0.0".  This stops media from being sent to the remote side since the remote address is now considered NULL.  When the call is taken off of hold, the SDP session version is less than "28112" and we therefore ignore the SDP because we think nothing has changed.  Therefore, we continue to not send media to the remote address because we think there is nothing to be sent.  Hence, the reason why there is an occasional audio failure.

Setting ignoresdpversion for the Cisco device should force Asterisk to process the SDP no matter what, since it will ignore the SDP session version.

By: Michael L. Young (elguero) 2012-11-19 08:59:27.777-0600

Did you get a chance to try this out yet?  Please report back on what you found out.

Thanks

By: Jeremy Pepper (jpepper) 2012-11-19 09:44:56.410-0600

Sorry about the delay! I've tested this change and it does seem to be working.

By: Michael L. Young (elguero) 2012-11-19 10:23:57.004-0600

Thanks for responding and confirming that the workaround option solved this.