Checkov, Andrew ha scritto:
> #0 0x004d2ae1 in opbx_udptl_read (udptl=0x0) at udptl.c:360
> 360 if (seq_no > s->rx_seq_no)
> (gdb) bt full
> #0 0x004d2ae1 in opbx_udptl_read (udptl=0x0) at udptl.c:360
> res = 232
> actions = 0
> sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0},
> sin_zero = "\000\000\000\000\000\000\000"}
> len = 16
> iabuf = '\0' <repeats 15 times>
> null_frame = {frametype = 5, subclass = 0, datalen = 0, samples = 0,
> mallocd = 0, offset = 0, src = 0x0, data = 0x0,
> delivery = {tv_sec = 0, tv_usec = 0}, prev = 0x0, next = 0x0,
> has_timing_info = 0, ts = 0, len = 0, seq_no = 0, tx_copies = 0,
> local_data = 0x5056c4 ""}
> __PRETTY_FUNCTION__ = "opbx_udptl_read"
> #1 0x00000000 in ?? ()
> No symbol table info available.
>
> I will try to findout which exact model was the killer and which
> packets it sends, but currently I have to disable UDPTL on this server
> at all till the end of investigation.
> BTW, is their any way to get this data from core dump?
if you could grab a tcpdump of both RTP,UDPTL and SIP, we want to solve
this out.
> With T38_ENABLE it will be possible to enable T.38 only to _selected_
> gateways which a) really need it b) has really working T.38
> implementation.
Most of the things, out there, are functional.
So IMHO the best way is having it enabled and disable when needed.
If something doesn't support T38, then it won't accept the invite.
I believe that instead of changing the behaviour (because what we do is
the best practice) we should solve tour problem.
MAx
_______________________________________________
Callweaver-users mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-users
