Allworx Technical Support Forum

Hey All,

I am not sure if this is due to the incoming phone call having an issue on the network side, but every now and again I am getting the following error... tUdpSrc: PROV_udp: *** WARNING 10 seconds with no received audio packets. PROV-ID (18585)***... Anyone have any idea what this is and why I am getting it.

Thanks in advance!

Anyone any clue on this one?

just found out the other day. someone was muting phone on a conference call, and the allworx saw it as silence. have provider send comfort nosie.

Hey! Thanks for the reply... but unfortunately I am not sure what you are referring too. How do I enable the comfort noise? I don't seem to be getting it when muted... but mostly when a call is being transferred or put on hold, it can no longer be retrieved.

mw@its.ky wrote:
> Hey! Thanks for the reply... but unfortunately I am not sure what you are
> referring too. How do I enable the comfort noise? I don't seem to be
> getting it when muted... but mostly when a call is being transferred or put
> on hold, it can no longer be retrieved.

turned out issue was with sip trunks. I disabled early media and that fixed our issue with allworx thinking the call had ended. The symptom we had was "tUdpSrc: PROV_udp: *** WARNING 10 seconds with no received audio".

So our systems have the same symptom, but may have different issues.

If you have no issues, ignore it.

Hey! Thanks again for your help with this...

The issue we have is that when calls are received or put on hold and then returned too... it is like the call is dead (no audio), yet the call is still connected. When this happens we then see the error in the event viewer.

Where do I find the early media setting and what is this used for?

If it's a generic sip handset then change it's silence options. We had that issue with Aastra 2630s. We disabled silence suppression.

Hey, Sorry for the long delay. They are not generics... they are Allworx 9112's. The issue seems completely random... but seems to happen when the main office answers a call and then once they have them on hold and attempt to transfer it cuts off and the system logs the no audio event.

Change them to using parks if possible.

Or enable auto on hold so they can't lose the call.

The same issue can occur with parks--we experienced it.

It's gone down considerably since we put in a music on hold source.