[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