[asterisk-r2] OpenR2 Calling Category Patch

Moises Silva moises.silva at gmail.com
Mon Aug 31 18:07:07 CDT 2009


Hello Afonso,

Thank you for bringing this to my attention. I hope you don't mind I am
moving this thread to the asterisk-r2 mailing list in order to keep a record
of our discussion. Please reply also to the asterisk-r2 mailing list to keep
it there.

First thing first, thanks for the patches. Not much people take the time to
contribute real code to openr2. Your help is very much appreciated.

Having said that, for the record, I have uploaded the patches to my site:

http://www.moythreads.com/patches/openr2/*
asterisk-1.4-calling-category.patch<http://www.moythreads.com/patches/openr2/asterisk-1.4-calling-category.patch>
*

http://www.moythreads.com/patches/openr2/*openr2-calling-category.patch<http://www.moythreads.com/patches/openr2/openr2-calling-category.patch>
*

This should help those interested in seeing the patches, but, I think, the
Asterisk patch as it is now will not work quite well, unless I don't
understand how global variables work in Asterisk. The problem is that
setting a global variable will affect other channels as well, doesn't it?
this means that if 2 incoming channels from PBX A at the same time report a
different category, the call that gets processed in second place may
override the category reported by the first call and therefore the 2
outgoing calls to PBX B will report the same category, which is incorrect,
this is a race condition, and as more incoming calls arrive the probability
of hitting the race condition is increased. Let me know if this makes sense.

In the other hand, I see you are using sort of an old patch, try using the
latest 1.4 patch, or better yet, if you want latest 1.4 code try using the
mfcr2-1.4 branch (it's under team/moy in Digium's SVN), you can create any
patch you want for 1.4 by using svn diff on that branch. You will see that
the MFCR2_CATEGORY variable is set now in dahdi_new.

Another question for you, is, do you need for something in particular the
"mfcr2_call_accepted = 1" lines you added in dahdi_answer? seems a bit
redundant since openr2_chan_accept_call() API should trigger
on_call_accepted callback in Asterisk when the call is finally accepted
(either for fwd or backward call) and then in that callback I am already
setting mfcr2_call_accepted member to 1, which is better since only when
on_call_accepted is triggered we can be sure both parties are ready to
proceed.

As of the patch for openr2 itself. I will include it with minor changes. The
only thing I want to change is that you are changing the behavior of
openr2_proto_get_category() in a non-backwards compatible way. This will
break r2test application and any other application making use of category
strings with underscores like "national_subscriber". I think that in order
to keep backwards compatibility we must accept both "national_subscriber"
and "national subscriber".

Once I commit the patch, the solution to your problem would be to do this on
the receiving side of the call:

[openr2-incoming-from-pbx-a]
exten => _X.,1,Answer() ; of course, you dont need to answer if you dont
want to
exten => _X.,n,Set(_MFCR2_CATEGORY=${MFCR2_CATEGORY})
exten => _X.,n,Dial(DAHDI/g2/${EXTEN}) ; assuming g2 goes to pbx b

The key point to remember here is that you are Set()'ing _MFCR2_CATEGORY
variable to whatever MFCR2_CATEGORY variable is. The MFCR2_CATEGORY variable
has the value of the incoming category, then you want to inherit that
variable to the outgoing channel so Asterisk can see it in the outgoing
channel, that is done in Asterisk through variable inheritance and you do
that by prefixing the variable with an underscore, so, when you do
Set(_MFCR2_CATEGORY=${MFCR2_CATEGORY}), you are inheriting the value of the
incoming channel to the outgoing channel and therefore the correct category
will be used.

I will commit the changes some day this week and let you know so you can
please test it before I create a new release (openr2-1.2.1) with this patch.

-- 
Moises Silva
Software Developer
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3
Canada
t. 1 905 474 1990 x 128 | e. moy at sangoma.com

On Mon, Aug 31, 2009 at 10:30 AM, Afonso Zimmermann <
afonso.zimmermann at gmail.com> wrote:

> Hi Moises,
>
> I'm Afonso Zimmermann, and i work on Cleiber's work now. While a work in a
> bridge scenario, I noticed openr2 doesn't passthrough the calling category
> passed for other PBX. Scenario is attached.
>
> When user A calls user B in normal situations, PBX A forward a calling
> category "National Subscriber" (II-1 in Brazil), and Asterisk forwad
> "National Subscriber" too. But, if PBX A use ani other category (for example
> "International Subscriber"), the Asterisk forward "National Subscriber" too.
> It doesn't cause any pratical problem to the call, but is a incorrect
> indication to PBX B.
>
> The problem in this case is in pbx_builtin_setvar function, used to set a
> Asterisk variable. This function set the variable, but the buffer is cleared
> before the openr2 can retrieve this value, retrieveing always "Null" value.
> The asterisk patch changes this in asterisk-1.4.24.1, creating a global
> variable in asterisk, and the openr2 patch changes the
> openr2_proto_get_category function in version 1.1.0, to Asterisk can
> understand the calling category value. This also added the "Test Equipment"
> category (II-3 in ITU and Brazil too), but this is very, very, very rarely
> used. This affect bridge calls, both in accept_on_offer mode or not.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-r2/attachments/20090831/b849c130/attachment.htm 


More information about the asterisk-r2 mailing list