VoiceInterpreter fails after Dial fork receives BUSY from all call branches

[ghjansen]

Related to issue #2271 and PR #2420.

Scenario:

• Restcomm creates multiple outbound calls through a Dial forking RCML like:

<Response>
    <Say>Welcome to Telestax Restcom Visual Designer Demo</Say>
        <Dial>
            <Client>bob</Client>
            <Client>alice</Client>
            <Client>steve</Client>
        </Dial>
    <Say>Hangup by timeout test concluded with success.</Say>
</Response>

• each one of the call branches answers back with SIP 486 (BUSY)

Failure:

• caller remains hearing the ringing tone forever apparently skipping all remaining verbs in the RCML

[ghjansen]

Solution:
VoiceInterpreter was moving to the next verb correctly, but there were 3 flaws during that process:
1 - VoiceInterpreter was not explicitly requesting MS to stop the current media being played;
2 - VoiceInterpreter was moving to the next verb of the RCML right away;
3 - missing FSM transitions from forking state.

That said, VoiceInterpreter was patched to explicitly request the call controller (either MGCP or JSR309) to stop the media currently playing, before moving to the next verb of the RCML. After the Stop request is sent, VoiceInterpreter waits for a MediaGroupResponse to confirms that the MS stopped playing the media (VoiceInterpreter does not move to the next verb of the RCML until MediaGroupResponse is received). By receiving the MediaGroupResponse, VoiceInterpreter resumes its flow and proceed to next verb.

Closed via PR #2420 .