Reversecharge

I get the reversecharge warning every time, and at the same time that sipgate.co.uk sends out its
Ext. 1xxxxxxe0: Friendly Scanner from 217.10.79.23;branch=
Sipgate uses the Friendly Scanner in place of NAT / ICE /TURN or something - its as some sort of keepalive so that IPv6 will work past your router.
Sipgate mentioned this in a lecture video which had a link on TW and perhaps FB.
regards ozz

Hi!

Does Asterisk do lazy evaluation?

I modified, just for the sake of testing, extensions_additional.conf.

I didn’t know how to echo what I wanted so I just assigned it to a variable that was already there:

I put this:

exten => 1235551212,n,Set(CHANNEL(musicclass)=default)
exten => 1235551212,n,Set(__MOHCLASS=${__REVERSAL_REJECT})
exten => 1235551212,n,Set(__MOHCLASS=$["${__REVERSAL_REJECT}"=“TRUE”])
exten => 1235551212,n,Set(__MOHCLASS=$["${__REVERSAL_REJECT}"=“TRUE” & “${CHANNEL(reversecharge)}”=“1” ])
exten => 1235551212,n,GotoIf($["${__REVERSAL_REJECT}"=“TRUE” & “${CHANNEL(reversecharge)}”=“1” ]?macro-hangupcall)

I got this:

– Executing [1235551212@from-trunk:7] Set(“SIP/Voipms-00000000”, “CHANNEL(musicclass)=default”) in new stack
– Executing [1235551212@from-trunk:8] Set(“SIP/Voipms-00000000”, “__MOHCLASS=”) in new stack
– Executing [1235551212@from-trunk:9] Set(“SIP/Voipms-00000000”, “__MOHCLASS=0”) in new stack
[2015-09-07 19:54:28] WARNING[9380][C-00000000]: func_channel.c:596 func_channel_read: Unknown or unavailable item requested: ‘reversecharge’
– Executing [1235551212@from-trunk:10] Set(“SIP/Voipms-00000000”, “__MOHCLASS=0”) in new stack
[2015-09-07 19:54:28] WARNING[9380][C-00000000]: func_channel.c:596 func_channel_read: Unknown or unavailable item requested: ‘reversecharge’
– Executing [1235551212@from-trunk:11] GotoIf(“SIP/Voipms00000000”, “0?macro-hangupcall”) in new stack

(I got the reversecharge warning twice because I tried to assign it before using it in a goto hence the two warnings, once for the assignation, once for the goto…)

So it looks like for me:

__REVERSAL_REJECT gives me “” (an empty string)
"${__REVERSAL_REJECT}"=“TRUE” gives me 0 (makes sense)

Ok so if Asterisk does lazy evaluation then why is “${CHANNEL(reversecharge)}”=“1” evaluated?

This seems to suggest that Asterisk doesn’t do lazy evaluation and evaluates everything

and that this test

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

probably needs to be written with Goto’s or maybe inline if’s or something similar to avoid evaluating the missing reversecharge parameter (by jumping over the code that evaluate reversecharge…

I tried dicko’s suggestion (there were some brackets missing in it though I believe) and it did not make a difference…

To me it looks like Asterisk doesn’t do lazy evaluation and always evaluate everything even if the left side of the operator is false…

Thoughts?

Have a nice day!

Nick

Hi!

I see that @jfinstrom committed something which seems to be related to this for the FreePBX 13 Beta but it unfortunately didn’t work for me (if the intent was to fix this problem).

re: FreePBX / core / a9852e703c4 - FreePBX GIT

and

Executing [1235551212@from-trunk:9] Set(“SIP/Voipms-00000002”, “__REVERSAL_REJECT=FALSE”) in new stack
[2015-09-08 19:34:42] WARNING[8049][C-00000536]: func_channel.c:596 func_channel_read: Unknown or unavailable item requested: ‘reversecharge’

It realllllllly looks like Asterisk doesn’t do lazy evaluation so “${CHANNEL(reversecharge)}”=“1” should not be on the right side of the “&” if it is not available for that channel type…

Have a nice day!

Nick

None of that is appropriate, only ISDN trunks will recognize the reversecharge thingy, given that, few will honor it.

Those log entries are basically red-herrings and will have no effect on your other trunking or dialplan progression, look deeper as to your problem.

Hi!

I would suggest splitting the test like this:

exten => 1235551212,n,GotoIf($[“${REVERSAL_REJECT}”!=“TRUE”]?post-reverse-charge)
exten => 1235551212,n,GotoIf($[“${CHANNEL(reversecharge)}”=“1”]?macro-hangupcall)
exten => 1235551212,n(post-reverse-charge),Noop(Post reverse charge check)

edit: This works (now) thanks to the input I received further down this thread… I have removed the double underscores in front of the REVERSAL_REJECT variable, those must not be there when the variable is retrieved, it must only be there when the variable is set.

Have a nice day!

Nick

Again it is a red-herring, SIP trunks don’t have that concept, only ISDN, also notice while you waste you time

__REVERSAL_REJECT

has two underscores at the beginning (there is a difference) , but for SIP trunks, it is just NOT a concern.

dicko, instead of saying other waste their time, try it…

There’s a problem with the test…

If you can’t bother reading the whole thing then please don’t comment…

I know it only works for ISDN/PRI but the test kicks in even with other type of channels…

If you had bothered to read the entire thread, you would know…

And I know the name of the variable is NOT ok, look at my post scriptum, it’s the forum software which messes with the variables because it understands the underscores as being some sort of formatting (looks to me like italics…) edit: I removed the post scriptum when I got my conditions to work…)

Again, if you can’t bother to read the thread, actually test the problem with a SIP trunk please don’t make any more comments, you are not being constructive…

The problem is very easy to replicate…

If you want to start being constructive then please tell me what you use to quote the text so that it doesn’t interpret the content as formatting codes… I try the preformatted text in the past and it messed up the text I was quoting in other ways…

Nick

Why would I want to try a spurious test ? I will leave it to you to construct the unnecessary stuff if you want to.

Please just ignore those spurious log lines.

Because you would see there is an actual problem…

We don’t have ISDN/PRI trunks…

We haven’t enabled the reverse charge check…

@jfinstrom has actually tried to fix this, look at the commit he did today…

We are not imagining things…

And while I had kinda made my peace with those warnings obviously others have not and they will keep on posting about it unless the problem is fixed… I am sure you have been around forums like these long enough that you know this is what is going to happen… There have already been more than one thread about this and it will continue…

Nick

PS: I have asked around and while I did not get an official answer someone else with more knowledge of Asterisk than I have tended to agree with my hunch that Asterisk most likely doesn’t do lazy evaluation and tries to evaluate all operands which is what would cause this…

It does if you get your bracketing right.

Start here

http://www.voip-info.org/wiki/view/Asterisk+Expressions

Thank you, will do immediately…

I had never played with this before…

Nick

OK, it works now thanks to the URL you sent me to which pointed to another page which dealt with variables…

The problem was not one of bracketing but of underscores…

You set a variable with underscores (1 or 2) in front of it to control inheritance but you must not put those in front of the variable name when you retrieve them (“Note that for retrieval purposes these variable names do not include the underscores.” from http://www.voip-info.org/wiki/view/Asterisk+variables)…

Thing is, those underscores were there (ie the dial plan is generated that way by FreePBX) before I started playing with this so it was never able to retrieve that variable…

I will check to see if correctly using the variable makes any difference with an almost unmodified dial plan now…

Thank you,

Nick

Nope, doesn’t work so it seems my modification is really necessary…

I will modify what I posted above to remove those underscores, it works as designed now…

If I set it to FALSE I don’t get the error message, if I set it to TRUE with my SIP trunk I get the error message since my trunk is not ISDN/PRI…

So it definitely seems to work A-OK now…

Thank you and have a nice day!

Nick

Sorry for a stupid question, so where does this need to be put in to silence the d… reverse charge warning for SIP trunks inbound routes (just checked it only appears there now in full.log) ? by ‘this’ I mean the split check you wrote about.

Hi!

It’s definitely not a stupid question especially considering you should not put it where I did it when I did my test…

I put it in extensions_additional.conf but this file gets rewritten each time your modify your FreePBX box configuration so you should not put it there except for small tests like the one I did…

I submitted a pull request (that’s one of the way to submit code fixes, modifications, etc…) to have the actual fix integrated in FreePBX… There was another small formality I had to take care of and it was done earlier today…

I modified the source code that actually write the entries in extension_additional.conf so they will get rewritten as I described once the fix is published and your FreePBX box updated.

I submitted the fix against FreePBX 13 since this is what I am running but I have compared the source code in FreePBX 13 to FreePBX 12 and the source code is nearly identical so the fix can be easily backported/cherry-picked (copied from one version to the other) so as long as you are running a recent enough version (ie still supported) the fix to this should probably be published and available shortly.

Which version are you running?

Have a nice day!

Nick

For now I’m only putting this into 13. 13 is now RC. I’m sure I will get it into 12 soon though. Maybe this week. But I try to not do dialplan changes like this in stable released.

3 Likes

Thank you Andrew for committing it and committing it so fast!

Have a nice day!

Nick

1 Like

I was going to say 12.0.76 (just last night done 6.12.65-30 upgrade) :wink:
This reversecharge warning was at some point quite sticking out (for quantity of it) it looked like it appeared for every run of the time checking condition - full.log was,well, f u l l of it, even though I don’t have that many calls logged - but this seems to be gone with some earlier upgrade - so now I hope this finds way to my distro/modules, some time :wink:

Thanks @tm1000 Andrew :slight_smile:

1 Like