I recently defined a SIP trunk from CUCM 10.5 to a CME running 15.1(4)M3. I enabled Options Ping. I set up the SIP trunk in CUCM a few weeks prior to the CME being configured to use it. The CME did not have the IP addresses of the CUCM cluster in it's trusted list. So the Options Ping set the SIP trunk to a failed state. When the CUCM IP address were finally added to the CME's trusted list, to my suprise, the SIP trunk did not become active. It stayed in the failed state. Only after I reset the trunk in CUCM did it come active.
At this point, I realized Options Ping does not work the way I expected it to. I thought it would continue to try and when the other end could be reached, it would show active again. Looking further into Options Ping, I see the default in CUCM is to try every 120 seconds when the trunk is Out-of-service. And there is a second setting that defaults to retrying 6 times (maximum 10). So it appears after 12 minutes CUCM will stop trying and never look back.
So here is my question... Is the only way to recover a SIP trunk, that is in a failed state because of Options Ping, to reset the trunk? If that is true, it seems Options Ping may do more harm than good if there is no alternate route anyway.
My concern is if there is an extended network outage in between the two, that both ends will give up trying. Then the only way to recover is manual intervention.
