<div>Hello Afonso,</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Having said that, for the record, I have uploaded the patches to my site:</div>
<div> </div>
<div><a href="http://www.moythreads.com/patches/openr2/asterisk-1.4-calling-category.patch">http://www.moythreads.com/patches/openr2/<u><font color="#0066cc">asterisk-1.4-calling-category.patch</font></u></a></div>
<div> </div>
<div><a href="http://www.moythreads.com/patches/openr2/openr2-calling-category.patch">http://www.moythreads.com/patches/openr2/<u><font color="#0066cc">openr2-calling-category.patch</font></u></a></div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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".</div>
<div> </div>
<div>Once I commit the patch, the solution to your problem would be to do this on the receiving side of the call:</div>
<div> </div>
<div>[openr2-incoming-from-pbx-a] </div>
<div>exten => _X.,1,Answer() ; of course, you dont need to answer if you dont want to<br>exten => _X.,n,Set(_MFCR2_CATEGORY=${MFCR2_CATEGORY})</div>
<div>exten => _X.,n,Dial(DAHDI/g2/${EXTEN}) ; assuming g2 goes to pbx b</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div><br>-- <br>Moises Silva<br>Software Developer<br>Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada<br>t. 1 905 474 1990 x 128 | e. <a href="mailto:moy@sangoma.com">moy@sangoma.com</a><br>
<br></div>
<div class="gmail_quote">On Mon, Aug 31, 2009 at 10:30 AM, Afonso Zimmermann <span dir="ltr"><<a href="mailto:afonso.zimmermann@gmail.com">afonso.zimmermann@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hi Moises,<br><br>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.<br>
<br>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.<br>
<br>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.<br>
</blockquote></div><br>