06-29-2010 03:53 PM - edited 03-15-2019 11:28 PM
Hi,
Could someone explain the output I have after I issue the command show call active voice brief.
Actually what I want to know is, what does noise:-52 acom:45 i/0:-51/-16 dBm and pl:146400/0ms lost:0/1/0 delay:55/55/85ms g711ulaw TextRelay: off means?
Does the output tells the call is not answered or consider as a drop call?
Hope someone can explain me further. Thank you and appreciate the help.
816 : 53194 1107709670ms.1 +9960 pid:1 Answer 913103540000 active
dur 00:00:26 tx:7344/1175040 rx:7345/1233960
Tele 0/2/1:23 (53194) [0/2/1.5] tx:146870/146870/0ms g711ulaw noise:-52 acom:45 i/0:-51/-16 dBm
816 : 53195 1107709680ms.1 +9940 pid:3000 Originate 38562 active
dur 00:02:26 tx:7344/1175040 rx:7345/1175200
IP 10.204.21.212:25312 SRTP: off rtt:0ms pl:146400/0ms lost:0/1/0 delay:55/55/85ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
Solved! Go to Solution.
06-29-2010 06:58 PM
Hi Jhun,
To answer your question briefly the following two sections of the 'show call active voice brief' provide information regarding echo and QOS:
noise:-52 acom:45 i/0:-51/-16 dBm
-NoiseLevel=-59
The active noise level for this call.
This value is calculated in the comfort
noise generation module and is used
to generate comfort noise when voice
activity detection (VAD) is enabled.
-ACOMLevel=45
The current ACOM level for this call.
ACOM is the combined loss achieved
by the echo canceler. This value is the
sum of the Echo Return Loss (ERL),
Echo Return Loss Enhancement
(ERLE), and Non-Linear Processing
(NLP) loss for the call.
pl:146400/0ms lost:0/1/0 delay:55/55/85ms
-HiWaterPlayoutDelay=55ms
The First-In, First-Out (FIFO) jitter
buffer high mark that indicates the
maximum depth to which the de-jitter
buffer adapts for this call.
-LoWaterPlayoutDelay=55ms
The FIFO jitter buffer low mark that
indicates the minimum depth to which
the de-jitter buffer adapts for this call.
-ReceiveDelay=85 ms
The current playout FIFO delay plus
the decoder delay for the call.
The following output tells us that there was a codec negotiation using g711ulaw:
g711ulaw TextRelay: off
Codec negotiation occurs after call setup and alerting states, so most likely the terminating device is off hook.
-be advised that the show call active voice brief only displays active calls, so most likely this is not a dropped call.
I hope this answers your question
cheers
Edson
07-01-2010 08:34 PM
Hello,
Well the CCAPI layer is generally good for protocol's such as SIP and h323 since both these signaling types pass-through this layer in the Symphony system. Depending on the type of connection you have to the PSTN would depend on which debug I would use to monitor certain events. For example if I had PRI/BRI circuit the q931 layer would be enough to look for any suspicious dropped calls on the ISDN trunk. However I would use something else such as the ccsip debugging to troubleshoot sip trunk to the terminating device. Also a simple "show call history voice brief" will give you the disconnect cause code's the previously setup and release calls. The disconnect cause code will give you a hint as to why the call released. For example a cause code (16) would mean that the call cleared normally, as appose to the cause code 38 "network out of order".
I hope this helps
Regards
Edson
07-06-2010 08:02 AM
Thanks Edson, I'll keep this in mind.
06-29-2010 06:58 PM
Hi Jhun,
To answer your question briefly the following two sections of the 'show call active voice brief' provide information regarding echo and QOS:
noise:-52 acom:45 i/0:-51/-16 dBm
-NoiseLevel=-59
The active noise level for this call.
This value is calculated in the comfort
noise generation module and is used
to generate comfort noise when voice
activity detection (VAD) is enabled.
-ACOMLevel=45
The current ACOM level for this call.
ACOM is the combined loss achieved
by the echo canceler. This value is the
sum of the Echo Return Loss (ERL),
Echo Return Loss Enhancement
(ERLE), and Non-Linear Processing
(NLP) loss for the call.
pl:146400/0ms lost:0/1/0 delay:55/55/85ms
-HiWaterPlayoutDelay=55ms
The First-In, First-Out (FIFO) jitter
buffer high mark that indicates the
maximum depth to which the de-jitter
buffer adapts for this call.
-LoWaterPlayoutDelay=55ms
The FIFO jitter buffer low mark that
indicates the minimum depth to which
the de-jitter buffer adapts for this call.
-ReceiveDelay=85 ms
The current playout FIFO delay plus
the decoder delay for the call.
The following output tells us that there was a codec negotiation using g711ulaw:
g711ulaw TextRelay: off
Codec negotiation occurs after call setup and alerting states, so most likely the terminating device is off hook.
-be advised that the show call active voice brief only displays active calls, so most likely this is not a dropped call.
I hope this answers your question
cheers
Edson
06-30-2010 09:38 AM
Hi Edson,
Thank you for the quick response, the information is a big help. What could be the best command to use to track down drop calls? debug voip ccapi inout mostly i used, aside from this command what else that could give more detailed information of drop calls?
Regards.
07-01-2010 08:34 PM
Hello,
Well the CCAPI layer is generally good for protocol's such as SIP and h323 since both these signaling types pass-through this layer in the Symphony system. Depending on the type of connection you have to the PSTN would depend on which debug I would use to monitor certain events. For example if I had PRI/BRI circuit the q931 layer would be enough to look for any suspicious dropped calls on the ISDN trunk. However I would use something else such as the ccsip debugging to troubleshoot sip trunk to the terminating device. Also a simple "show call history voice brief" will give you the disconnect cause code's the previously setup and release calls. The disconnect cause code will give you a hint as to why the call released. For example a cause code (16) would mean that the call cleared normally, as appose to the cause code 38 "network out of order".
I hope this helps
Regards
Edson
07-06-2010 08:02 AM
Thanks Edson, I'll keep this in mind.
04-30-2015 03:59 AM
Hi Edson,
Is there anyway to differentiate H.323 calls and SIP calls with the fields in the response "show call active voice brief"?
Thanks in advance.
Pandi
12-28-2017 09:19 AM
Hi guys!
Could someone explain, please, why in some output records the row which starts with Tele 0/2/1:23 (53194) ... is present and in other cases there is no such row (especially when the CallOriginType is Answer ?
12-28-2017 10:31 AM
12-28-2017 12:17 PM
Mohammed, thank you for clarification!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide