[asterisk-r2] Bug in openr2?
Moises Silva
moises.silva at gmail.com
Wed May 6 10:02:46 CDT 2009
Hello!
Finally someone took some time to look at that. I had been wanting to
do it but just did not find the time. Thanks!, so, anyone interested
please read the explanation of this bug below.
> The problem I believe we have is libopenr2 is not consistent with the
> names of the categories. If you convert category id
> OR2_CALLING_PARTY_CATEGORY_NATIONAL_SUBSCRIBER to string using
> openr2_proto_get_category_string() and back again to id using
> open_r2_proto_get_category() you get OR2_CALLING_PARTY_CATEGORY_UNKNOWN
> instead of the expected OR2_CALLING_PARTY_CATEGORY_NATIONAL_SUBSCRIBER.
It's not a bug, but a feature, a broken feature :-)
The thing is that openr2_proto_get_category_string is meant to display
a nice USER VIEWABLE description of the category, which DOES NOT mean
that the string can be converted back to category id. It worked well
until I decided to set the R2 category in dahdi_new, so, the real bug
is in chan_dahdi.c. I SHOULD NOT set the MFCR2_CATEGORY variable when
is an outgoing call, just for incoming calls.
> At this point I imagined including
> Set(MFCR2_CATEGORY=NATIONAL_SUBSCRIBER) in my dialplan would bypass the
> problem, but it didn't. I don't know why yet, but I have a lot of
> traffic and cannot test any further. Anyhow, I believe it is just
> bypassing the problem, that should be solved in openr2. I can change it
> in r2proto.c and send a patch, but would like to listen from your
> comments before.
Users are responsible for setting MFCR2_CATEGORY for outgoing calls.
However this thing is tricky. When you make an outgoing call you will
typically have 2 channels involved. The originating channel (let's say
a SIP channel) and the outgoing channel (DAHDI R2 channel). In the
dialplan when you execute Dial(), the Dial application is executed in
the SIP channel which originates an outgoing channel of the described
type, for Dial(DAHDI/) will generate an outgoing channel of type
DAHDI. If you set(MFCR2_CATEGORY=national_subscriber) that will set
the variable in the SIP channel NOT in the DAHDI channel and therefore
it did not work for you. The right way to do it is to use Asterisk
variable inheritance to set the variable in the channel originated as
well.
Set(_MFCR2_CATEGORY=national_subscriber)
Dial(DAHDI/....)
Note the underscore. That way the MFCR2_CATEGORY variable will be set
in any channel originated by the channel executing extensions in the
dial plan (in this case a SIP channel). That's how users can choose
the outgoing category to be set for openr2.
I think this bug only affects the mfcr2-1.4 and 1.6.2 branches and not
any released patches. I should probably consider using the same string
for display than the one used for the API. Given that it has been
working like that for some time I am hesitating to change it and I
think we should only fix the bug in chan_dahdi.c, otherwise I would
need to update documentation here and there.
--
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
More information about the asterisk-r2
mailing list