No subject

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.
                
> Occasional audio failure after placing call on hold
> ---------------------------------------------------
>
>                 Key: ASTERISK-20642
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20642
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 11.0.0
>            Reporter: Jeremy Pepper
>            Assignee: Matt Jordan
>         Attachments: holdissue.0
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira