Read DTMF D

[Jagat_UV]

I am using Connect 8.1.2 with an FMG on its own virtualized server. When I open a meeting and connect to a PGi conference bridge using Universal Voice, I sometimes see bursts of dropped packets in the FMG core.log such as the following:

2012-02-08::08:56:10.922              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=1 Video=0

2012-02-08::08:56:10.941              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=2 Video=0

2012-02-08::08:56:10.962              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=2 Video=0

2012-02-08::08:56:10.981              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=2 Video=0

2012-02-08::08:56:11.002              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=1 Video=0

2012-02-08::08:56:11.002              DEBUG CALLLEG               2920       [LEG ID:713] - Read DTMF D

2012-02-08::08:56:11.103              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=2 Video=0

2012-02-08::08:56:11.124              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=2 Video=0

2012-02-08::08:56:11.144              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=2 Video=0

2012-02-08::08:56:11.163              DEBUG SIP          2920       [LEG ID:713] - Number of media packets dropped: Audio=2 Video=0

2012-02-08::08:56:11.404              DEBUG CALLLEG               2920       [LEG ID:713] - Read DTMF D

I am connecting to the phone conference with an office phone to use as audio input to evaluate audio quality. I experience moments in meetings where the audio "cuts-out" for more than 500ms, but have not determined fully whether the dropped audio media packets are the culprit.

Does anyone know:

-why the FMG would be receiving a DTMF D from the conference call, especially after multiple dropped packets in a row? Is this just provider specific? 

-why the FMG would be dropping packets (it is under very low call volume and it is co-located in the same data center as the FMS cluster and in the same region as the SIP trunk provider)?

-is there any test data validating the claim that the FMG can handle 100 concurrent calls for every 2 CPU cores? It seems with the transcoding that must be done (G711u <--> speex/NM22k) that this is an optimistic number.

-what is the usual bottleneck/main hurdle when using the FMG for Universal Voice (CPU performance, network latency, audio input source, codecs used, ...)?

Thanks so much for any help or insights that can be provided.

Best regards,

Jagat

[Guest]

Jagat,

     you have raised 2 issues:

1) 'D' is a valid DTMF digit. The reason why PGi would send it is specific to PGi itself. If PGi doesn't expect any action in return (which, I believe, it shouldn't), I recommend not to worry about it. 

2) FMG running on virtual machine doesn't get CPU at granular interval and it causes frequent packet drops. As you pointed out, it will also cause audio loss for upto 500 ms.You have two options to get rid of packet drops:

a) [Highly recommended] Upgrade your Virtual Machine to have dedicated CPU access (no shared CPU) OR more to a physical server  OR try increasing CPU priority of VM on which FMG is running.

b) [Fallback] Upcoming version of FMG will have fix to not drop packets. This is a graceful degradation which would still cause delay for interactive conversation, so not really a desirable remedy. However, if required, you would may want to contact your Connect support to know whether there are scheduled FMG upgrades.

Hope it helps.

-Pankaj