I have a system setup with a Junghanns 4-BRI card and asterisk.
I have problems with the sound quality,
there is echo on the line on my SIP phones with an analogical phone communication.
If I change the rxgain and txgain setting in my zapata.conf according to the ztmonitor,
I can get better volume, and so a better echo cancellation.
But there is something that I don’t understand:
on one way, rxgain adjusts receive gain for an incoming call,
on the other way, rxgain adjusts transmit gain for an outgoing call …???
Rx gain always is for incoming audio, TXgain is always for outgoing (from your * server) audio.
You might want to tweak the echo canceller, there are a few different cancellation subroutines, but you have to define which one to use in zaptel source.
I think you want to speak about zconfig.h and the Mark2 echo cancellation.
I never tried to use agresive echo cancellation or Mark3. Do you use it?
But I’m sure on what I say:
on one way, rxgain adjusts receive gain for an incoming call,
on the other way, rxgain adjusts transmit gain for an outgoing call.
And I really want to set this gain for all cases.
[quote=“bastien”]on one way, rxgain adjusts receive gain for an incoming call,
on the other way, rxgain adjusts transmit gain for an outgoing call.
[/quote]
stop it ! outgoing, incoming, it makes no difference. to zap, it’s just a call. TX is what you’re sending, RX is what you’re receiving.
So what don’t I understand?
Ex.:
Analog communication with SIP phone
Case 1: incoming call to SIP => context is ‘isdn-incoming’ and rxgain is low
Case 2: outgoing call to analog phone => id do a ZAP/g1/phone_number and rxgain is high
Why?
I want to say:
Case 1: incoming call to SIP => context is ‘isdn-incoming’ and rx level is low
Case 2: outgoing call to analog phone => id do a ZAP/g1/phone_number and rx level is high
For the moment I use ECHO_CAN_MARK2.
I have tried to use ECHO_CAN_MARK3, but the result is not very good.
You told me about the ECHO_CAN_MG2, but I don’t find it in my zconfig.h …
I have:
/* #define ECHO_CAN_STEVE /
/#define ECHO_CAN_STEVE2 /
/#define ECHO_CAN_MARK / #define ECHO_CAN_MARK2
/#define ECHO_CAN_MARK3 */
I’m very happy to meet someone who use a QuadeBri card.
The SIP phones I use are some SwissVoice IP10s.
I think that you use a more recent version of the zaptel driver.
I will go immediately make an install of zaptel 1.2.0 and will let you know about the ECHO_CAN_MG2.
[quote=“bastien”]I tried to install zaptel 1.2, but I have a problem with it…
I do a ‘make load’ for qozap and It’s give me the following:
[/quote]
Never seen this error. Did you download the bristuff experimental from the website? (junghanns.net/)
At the moment it’s 0.3.0pre1c. Works perfect here.
Can you try doing a ./install of this one? If installing works, how does the compilation of zaptel goes? (should do without errors)
Yes, I have downloaded this ‘experimental’ bristuff.
I don’t have any error with the zaptel, libpri and asterisk compilations.
But when I load the qozap, I see this error and this switching on my NT mode (TE mode works perfect and I can use my SIP phones to take calls)
I have some news from Junghanns who tells me:
the output message ‘qozap: no version for “zt_receive” found: kernel
tainted’ is to be ignored (there are no problems known when receiving this
message).
But for the moment they don’t tells me why I have this problem on my NT mode:
I can’t make calls using the NT mode,
the lights of my quadBRI ignite and die out periodically in green and in red
and I have the following message:
qozap: re-activating layer 1 span 1
qozap: not re-activating layer 1 span 0
qozap: not re-activating layer 1 span 1
qozap: not re-activating layer 1 span 0
qozap: not re-activating layer 1 span 1
…
On the other hand, the lights on TE mode are stable and stay in green
so I can make calls with my SIP phones (the echo seems to be better).
(It is like I have a timer who controls the quadBRI in NT mode)
[quote=“bastien”]I have some news from Junghanns who tells me:
the output message ‘qozap: no version for “zt_receive” found: kernel
tainted’ is to be ignored (there are no problems known when receiving this
message).[/quote]
That’s good news, since the last version I’m also seeing this
I was re-looking at your zapata.conf, for your NT mode, can you try using:
signalling=bri_net_ptmp
That’s what I use to connect a quadBRI on the internal side to a HFC pci card also on asterisk. I’m not sure if it will make a difference, but it’s worth a try… You did set the jumpers correct, did you?
junghanns don’t reply me again since I send my
’cat /proc/zaptel/*’ and the output of my Asterisk
when trying to make a call using the NT-Ports and TE-Ports.
I will try to put ‘bri_net_ptmp’ for my NT mode.
I’m sure my jumpers are correct, the card works fine with zaptel.0.9 (but with echo…).
