Conversation
…top ringing insstead send stopwaiting so it moves to inprogress
… accurate DiallCallSattus and remove branch has removed all diallCall info
… when call get to inprogress
…s enabled. This refer to #RESTCOMM-1259
gvagenas
left a comment
gvagenas
left a comment
There was a problem hiding this comment.
@maria-farooq see my comment for when to answer the call and when not
| // if enable200OkDelay is true, call was not playing ringing tone, so no need to send stop ringing | ||
| if(enable200OkDelay){ | ||
| outboundCallResponse = SipServletResponse.SC_REQUEST_TIMEOUT; | ||
| call.tell(new StopWaiting(), self()); |
There was a problem hiding this comment.
@maria-farooq I think we shouldn't ask the initial call actor to stop waiting and answer the call at this point because there is a chance there will be no next verb (either subsequent verb or verb from Dial action).
To my point of view, we should first check if there is next verb (either by parser getNext or by executing the Dial Action) and if the next verb is Say, Play, Gather or other verb that involve Media Server, only then ask the call to answer.
Otherwise, we can terminate the original call. Which also means that verbs that don't need Media Server will be executed just fine, such as Sms, Email etc.
There was a problem hiding this comment.
i see the point, will update the patch so we only answer the call if we have relevant upcoming tag
|
@gvagenas All delay related test clases are green so if you have reviewed the patch we are ok to merge |
…into restcomm-1259
…s enabled. This refer to #RESTCOMM-1259
2 participants
No description provided.