[Asterisk-Users] MFC/R2

Steve Underwood steveu at coppice.org
Fri Oct 1 12:25:54 MST 2004


Daniel Bichara wrote:

> Hi Steve,
>
> I tested the new MFC/R2 library variation .br
>
> There are few signalling errors and a problem with buffer size in 
> set_mf_tx( ). I changed mfcr2.c and I will continue tests to be sure 
> it is stable.

This was correct. You have actually broken it. If you were getting 
trouble with the original code there must be some timing issue I haven't 
seen before. What you have done now can produce buffer overflows, and 
lots of problems, if the far end responds slowly.

> At this point, everything works fine if I have only one call. But, if 
> I have one Unicall channel dialing to another Unicall channel, I get 
> in trouble. Basically, Unicall assigns an ID to every new call 
> (starting at 32769). When my answered channel executes 
> Dial(UniCall/g1/tel_number), Unicall starts a new thread (32770) and 
> tries to send the tones. I guess the problem is in set_mf_tx (). This 
> function always set channel number to 0 (int ch=0) and the it send 
> tones to first channel (thread 32669 in this case) not to the right 
> channel. Then, it waits for RX tone that will never ocurr and exits 
> with protocol error (time_expired).

In MFC/R2, one signalling channel controls one voice channel. Voice 
channel 0 is, therefore, the only channel which ever exists for any 
signalling channel. Only when using something like ISDN with unicall 
will you see channels other than zero in use. If your calls do not work 
you clearly have a problem. However this analysis is not right.

> Is my logic right? Do you have a new Unicall implementation? If not, I 
> can work on it to solve this problem.

I will continue to work with you off the mailing list to resolve these 
issues. If you are able to get some calls through it seems like there 
cannot be too much wrong.

Regards,
Steve




More information about the asterisk-users mailing list