First call works just fine. Second and others do not work.....

[NeuralMonk]

I have Asterisk 1.4 Trunk 180682 running on a AMD64 8-core server and
trying to use the following modules (same effect on both):
codec_g729-ast14-gcc4-glibc-x86_64-opteron-sse3.so
or
codec_g729-ast14-gcc4-glibc-x86_64-pentium4.so

The two phones are Granstream GXP2000 running G729 on both of them.
Using an older version of the trunk, older codec_g729-ast14-gcc4-glibc-
core2.so module on a core2 system, this setup works fine.

I use the exact same asterisk configs on the new test server and the
first call I make works perfectly. Clean sound, fast, etc.

Any additional calls, I get no audio and after a minute:

[Mar 9 12:55:37] NOTICE[19126]: chan_sip.c:16436 do_monitor:
Disconnecting call 'SIP/5001-008aa9f0' for lack of RTP activity in 61
seconds
[Mar 9 12:55:37] NOTICE[19126]: chan_sip.c:16436 do_monitor:
Disconnecting call 'SIP/5000-9803c740' for lack of RTP activity in 61
seconds

Like I said, the first call works.

I am trying to figure out how to get more info about the call. Here
is what I have:

192.168.1.6 5001 4b12378336a 00102/00000 0x100
(g729) No Tx: ACK
192.168.168.75 5000 eb7b1d7a27c 00101/51176 0x100
(g729) No Rx: ACK

* SIP Call
Curr. trans. direction: Outgoing
Call-ID: 4b12378336a6a983...@domain.com
Owner channel ID: SIP/5001-008aa9f0
Our Codec Capability: 1294
Non-Codec Capability (DTMF): 1
Their Codec Capability: 256
Joint Codec Capability: 256
Format: 0x100 (g729)
MaxCallBR: 384 kbps
Theoretical Address: 192.168.1.6:5066
Received Address: X.X.X.X:5066
SIP Transfer mode: open
NAT Support: Always
Audio IP: 173.45.232.143 (local)
Our Tag: as55c6a3ff
Their Tag: 1437d1d32bffffa1
SIP User agent: Grandstream GXP2000 1.1.1.14
Username: 5001
Peername: 5001
Original uri: sip:50...@192.168.1.6:5066
Need Destroy: 0
Last Message: Tx: ACK
Promiscuous Redir: No
Route: sip:50...@192.168.1.6:5066
DTMF Mode: rfc2833
SIP Options: (none)

* SIP Call
Curr. trans. direction: Incoming
Call-ID: eb7b1d7a...@domain.com
Owner channel ID: SIP/5000-9804c910
Our Codec Capability: 1294
Non-Codec Capability (DTMF): 1
Their Codec Capability: 287
Joint Codec Capability: 270
Format: 0x100 (g729)
MaxCallBR: 384 kbps
Theoretical Address: 192.168.168.75:5060
Received Address: A.B.C.D:5060
SIP Transfer mode: open
NAT Support: Always
Audio IP: 173.45.232.143 (local)
Our Tag: as66a00724
Their Tag: b9be3b2342cb88aa
SIP User agent: Grandstream GXP2000 1.1.1.14
Username: 5000
Peername: 5000
Original uri: sip:50...@192.168.168.75:5060
Caller-ID: 5000
Need Destroy: 0
Last Message: Rx: ACK
Promiscuous Redir: No
Route: sip:50...@192.168.168.75:5060
DTMF Mode: rfc2833
SIP Options: replaces replace timer


With the module unloaded, I cannot hear ulaw prompts on the server.
With the module loaded, I hear the prompts from the server. This
happens even after the first call. So the trans coding does work.
However, it is the pass-through that does not work.

If I unload the module, the NO call works.
If I loaded it again, the next call will work, but the one after that
will not work.

Not sure about bringing this to the dev group until I have something
else they can blame other than this module.

It does seem to be Asterisk and not the module because the module does
work once and then not again.

Any pointers.

[Arkadi Shishlov]

Try to replicate the problem with iLBC.

[NeuralMonk]

Good call, but now it is pointing to the codec_g729-ast14-gcc4-glibc-
x86_64-opteron-sse3.so even more.

If I made a call using g729, the first call works, other don't. No
issues there. However GSM and ilbc both would not work between two
different phones until I unloaded codec_g729-ast14-gcc4-glibc-x86_64-
opteron-sse3.so from the system.

I noticed they did a new bridge system in the past couple of days,
wondering if the code needs to be recompiled against the trunk to make
it work. Wonder if that would break the "old" systems.

Thanks for the advise, but now it looks like things are more into the
codec_g729-ast14-gcc4-glibc-x86_64-opteron-sse3.so.

[NeuralMonk]

On further note. GSM and ILBC both work fine without the g729 codec
and have none of the same issues.

On Mar 9, 2:37 pm, Arkadi Shishlov <arkadi.shish...@gmail.com> wrote:

[NeuralMonk]

Just to note,

Module 'codec_g729-trunk-gcc4-glibc-x86_64-opteron-sse3.so' does not
provide a description.

So I cannot try the trunk version.

[kl]

# cat /proc/cpuinfo
...
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz
stepping : 2
cpu MHz : 1596.225
cache size : 512 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3192.50
clflush size : 64

This is a 4 core ATOM cpu. I wonder what version of asterisk-g729 codec I should use. It is ok if I use :-

codec_g729-ast14-gcc4-uclibc-pentium3.so

Regards.

[kl522]

Sorry for posting two times. The previous post was appended to a wrong
thread. So I am starting a new post :-

I am using uclibc. This is what I get :-

[Arkadi Shishlov]

On Tue, 10 Mar 2009 00:13:10 -0700 (PDT) kl522 <kl...@yahoo.com> wrote:
> I am using uclibc. This is what I get :-
>
> # cat /proc/cpuinfo
> ...
> processor : 3
> vendor_id : GenuineIntel
> cpu family : 6
> model : 28
> model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz
>

> This is a 4 core ATOM cpu. I wonder what version of asterisk-g729
> codec I should use. It is ok if I use :-
>
>
> codec_g729-ast14-gcc4-uclibc-pentium3.so

Use what is faster for you.
pentium4 or core2 might be even better choice.

[Arkadi Shishlov]

On Mon, 9 Mar 2009 15:54:35 -0700 (PDT)
NeuralMonk <apl...@gmail.com> wrote:
> Just to note,
>
> Module 'codec_g729-trunk-gcc4-glibc-x86_64-opteron-sse3.so' does not
> provide a description.
>
> So I cannot try the trunk version.

trunk is for Asterisk TRUNK. Or the API is changed again, in case you're running the TRUNK.
Check with tcpdump - maybe RTP is not flowing correctly for some reason.
There is also "g729 debug" command.

[NeuralMonk]

Yes, I am running branch/1.4 and not trunk, but I thought that maybe
they had moved the API over to what was in that old trunk version.

When I enable debug, all I get is:

-- g729 frames
-- length: count
-- g729 frames
-- length: count

Moved back to beginning of Feburary code in branch/1.4, just not have
success.

Still not working.

[NeuralMonk]

Found It. Didn't notice the RTP port setting on the old server was
starting at 2000 and the firewall rules on this one were 10000-20000.
My mistake. Thanks to all on the list and sorry for the traffic.

In the future, check the RTP.CONF settings.