[asterisk-dev] [Code Review] IAX2 "Ghost" channels
Russell Bryant
russell at digium.com
Fri May 15 15:20:40 CDT 2009
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/246/#review783
-----------------------------------------------------------
Ship it!
After these last tweaks, this looks good.
Thanks, David!
/trunk/channels/iax2-parser.c
<http://reviewboard.digium.com/r/246/#comment1962>
Actually, I'm not sure this is needed at all.
If the destination buffer isn't big enough, it will just get part of "Unknown" since you're using a length limited copy. Also, if the subclass is invalid, you'll get "Unknown".
/trunk/channels/iax2-parser.c
<http://reviewboard.digium.com/r/246/#comment1961>
I have one last set of comments:
Instead of the big else block, just put a return inside the if block to reduce indentation.
Also, our coding guidelines for formatting say that you align case with switch, which will reduce the indentation one more level.
- Russell
On 2009-05-15 13:54:46, David Vossel wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/246/
> -----------------------------------------------------------
>
> (Updated 2009-05-15 13:54:46)
>
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> There is a bug tracker issue where people are reporting "Ghost" channels in their 'iax2 show channels' output. The confusion is caused by channels being listed as "(NONE)" with format "unknown". These are not channels of coarse. They are usually just pending registration or poke requests, but it is confusing output. To help make sense of this I have added two columns to 'iax2 show channels'. One shows the first message which started the transaction, and the second shows the last message sent by either side of the call. This helps diagnose why the entry exists and why it may not go away.
>
> For example: in the 'iax2 show channels' output below the registration happening in the second entry is to a device that has been removed from the network. This entry will exist in the show channels output for quite sometime as Asterisk attempts to register with the device. Being able to view that this "Channel" is in fact a registration, and that the last message is a REGREQ which has not received an ACK, makes this entry much more obvious.
>
> This is technically a new feature, but due to the amount of confusion this has caused I purpose placing it in the 1.4 and 1.6.x branches as well. This may or may not resolve the issue it is associated with, but it will help weed out those having an actual issue with excess "Ghost" channels from those seeing something normal like a pending registration. It will also help diagnose the cause of the excessive "Ghost" channels some users are reporting.
>
> --------------EXAMPLE OUTPUT-------------
>
> *CLI> iax2 show channels
> Channel Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format Start Message Last Message
> IAX2/iaxy-15318 10.24.20.218 iaxy 12718/10329 00002/00002 00000ms 0000ms 0040ms unknow NEW ACK
> (None) 10.24.16.238 (None) 15109/00000 00001/00000 00000ms 0000ms 0040ms unknow REGREQ REGREQ
>
>
> *CLI> iax2 show netstats
> -------- LOCAL --------------------- -------- REMOTE --------------------
> Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost % Drop OOO Kpkts Start Message
> IAX2/iaxy-15318 1000 0 40 0 0 0 0 0 0 0 0 0 0 0 0 NEW
> (None) 1000 0 40 0 0 0 0 0 0 0 0 0 0 0 0 REGREQ
> 2 active IAX channels
>
>
> This addresses bug 0014207.
> https://issues.asterisk.org/view.php?id=0014207
>
>
> Diffs
> -----
>
> /trunk/channels/iax2-parser.h 194685
> /trunk/channels/iax2-parser.c 194685
> /trunk/channels/chan_iax2.c 194685
> /trunk/channels/iax2.h 194685
>
> Diff: http://reviewboard.digium.com/r/246/diff
>
>
> Testing
> -------
>
> tested iax2 show netstats and iax2 show channels, output is shown above.
>
>
> Thanks,
>
> David
>
>
More information about the asterisk-dev
mailing list