Reversecharge

I getting alot of:
WARNING[1842][C-000014ea]: func_channel.c:538 func_channel_read: Unknown or unavailable item requested: ‘reversecharge’

I checked my inbound routes and I do not have Reject Reverse Charges “Checked” on any of them? is this normal I do I need to check this to remove this warning log entry?

+1 me too, appears in full log a lot:

[2015-07-20 11:37:47] WARNING[29297][C-00002913] func_channel.c: Unknown or unavailable item requested: 'reversecharge'

This is perfectly normal. It’s used to check for reverse charge entries on DAHDI calls. As it’s not a DAHDI call, it’s saying it’s not available.

Actually it’s a little more complex than that, see Reject Reverse Charges

It is handled by chan_dahdi but it also needs that Asterisk be compiled with libpri support and the libpri used must support the feature…

As far as I know what this message means is that we receive an indicator telling us that the call has “reversecharge” set but there is nothing to handle it in the func_channel method/function (which seems to be common for all channel types). The code necessary to deal with this indicator is only present apparently when it’s a DAHDI channel with appropriate libpri support but you can actually receive it over other type of channels.

The code involved complains that it is receiving an indicator it can’t handle and, as far as I know, short of recompiling there is no way to get rid of this warning…

I don’t quite get why it is only handled by chan_dahdi and with the appropriate libpri support, I am actually receiving this over SIP for my toll free numbers so it should have been allowed to receive this over other channels…

Are you gals/guys getting this for toll free numbers and is a card that supports DAHDI involved (I have one with only FXOs and it is used for those calls and there’s no PRI involved…)? I haven’t try putting the DAHDI card out of the equation yet but I am pretty sure I would still get that error message…

Have a nice day!

Nick

Ah I see… and as the time condition is checked every minute, this appears for every such event (I don’t have DAHDI on / no digital or analog card(s), my PBX is just SIP-only). Thanks!

Mine is just SIP as well with 1x 800 number I have

Thank you guys/gals!

Let’s hope Digium will eventually add support to receive this indicator over other channels…

Have a nice day!

Nick

There is no indication for this over other channels, it’s only possible for this to be indicated over Dahdi.

xrobau, we are receiving it over SIP…

Unless I misunderstood the code in func_channel.c it complains because it is receiving that indicator but does not know what to do with it (since it’s only handled by chan_dahdi with proper libpri support).

Support for it is only present in chan_dahdi with the proper libpri support but it is passed over other channels at least as far as my (and other people) VoIP providers are concerned…

I have a card that supports DAHDI (a Sangoma A200) but it only has FXSs and is an analog card so I don’t think it plays any part in this and others which are SIP only also have the same “reversecharge” indicator even if they are SIP only…

I (and I believe we all are) receiving it only for toll-free numbers which I believe is exactly what should happen…

If you want proof of it that could be arranged…

Nick

No, FreePBXs dialplan is checking for the existance of the ‘reversecharge’ flag. It does’t exist on a SIP call, which is why you get the warning.

Why am I only receiving that warning for my toll-free numbers? Somehow we are receiving something from our VoIP providers which something wants to transpose into that indicator…

Because you’re only enabled Reverse Charge rejection on your toll free numbers?

exten => 1234,n,GotoIf($["${__REVERSAL_REJECT}"="TRUE" & "${CHANNEL(reversecharge)}"="1" ]?macro-hangupcall)

As I said, that reverse charge flag is only available over Dahdi. I notice there was some discussion 5 years ago about adding it to SIP, but I’m not sure if it made its way in

The help text seems quite self-explanatory. Can you think of a better way to phrase it?

Hehe, gotta ask you Rob, why is your “Unsigned Module” warning apparent ? :wink:

1 Like

I never bother closing it, so many changes reset it, it’s not worth the extra click :sunglasses:

Also, this is a dev machine, so almost ALL the modules are unsigned.

Edit: And that’s one of the reasons why we never noticed that bug about notifications last year – no-one had actually told us it was broken, as we never use it. 8-(

Interesting…

I didn’t activate on any DID it but I do see that bit of code in extensions_additional.conf for all my DID…

Looks like this bit of code gets added by FreePBX on whether supports of reversecharge is present or not for all DIDs…

Now the question is why did’t I get this for my non toll-free numbers…

By the way, I am using the FreePBX distro and my screen are different from yours, why? Some sort of skin or a different version (I thought I was running the latest).

Thank you and have a nice day

Nick

Yep, The code is ‘If REVERSAL_REJECT is true AND if the channel is signalling reverse charge, reject the call’.

When you turn off Reversal Reject, the second part of the check won’t get run, and you won’t see the warning.

Oh, that screenshot is from FreePBX 13, which is in testing now. I think the top pinned post in the forum has links to download it to play with.

That’s what you need to turn off in 12.

Yeah, I have gotten used to just ignoring all that signing stuff too :slight_smile:

I am running 11 and it is off

There’s something weird going on…

I am a programmer by the way and I guess Asterisk “language” does lazy evaluation so I understand that if the first argument before a “&” is false it won’t evaluate the second but obviously something on my server makes it evaluate the second argument and that’s why it complains…

I have not checked any of those checkboxes, I swear! :wink:

1 Like

maybe your

["${__REVERSAL_REJECT}"=“TRUE” & “${CHANNEL(reversecharge)}”=“1” ]

might be better bracketed, perhaps…

["${__REVERSAL_REJECT}"=“TRUE”]&["${CHANNEL(reversecharge)}"=“1” ]

Also, sorry to cut in again, I see that ‘reverse charge’ warning EVERY MINUTE in the logs, supposedly it’s related to the time groups/time conditions checking.