Closed hrosa closed 7 years ago
@gvagenas
~Looking at MgcpMediaGroup
im inclined to fix this by adding extra Active
substates corresponding to Play
, Record
, Collect
, End
. Im unsure yet as to what extent or how.
What do you think? Do you have a different idea of how to address this?~
My previous assessment was completely off mark, MgcpMediaGroup
already uses a flag isIvrInUse
to dictate Idle or Active states.
This seems to be an issue in VoiceInterpreter
, mainly for JoinComplete
and Leave
handling. Specifically playBeepOnEnter
and playWaitUrl
.
Additionally seems to be a lot of hardcoded paths in there
@hrosa Do you have corresponding RC and RMS server logs for the issues #1621 #1622 #1623 ?
Hi @abdulazizali77
I attached pcaps to each ticket as proof. I have no logs. But this issue can be easily reproducible with the RestComm demo apps +1310 and +1311.
thanks @hrosa, ive looked at the caps, i realize theyre conference bridge issues, would be good if there were logs, but its ok!
@hrosa can you please check if it is still happening? as i remember some refactoring went through for rms5 upgrade. or can you provide steps to reproduce so we close or implement this issue?
after patching #2024 it is irrelevant now
Noticed that RC workflow is sending a lot of unnecessary EndSignals to the conference endpoints. It seems that an EndSignal is always sent right before sending a play to the IVR of the conference. Even when conference IVR is not playing anything!
And both RQNT are sent simultaneously! This can cause unpredictable behaviour on Media Server side. Instead, RC should send EndSignal and wait for response from RMS before sending the play.
Attaching pcap with example. Problematic frames: 977, 3345, 4839 too-many-endsignals.pcapng.zip