On 2014-01-28 12:21, Pavel Troller wrote:
snip
Later on, an ast_frdup most likely pulled the frame off of the rtp
engine and re-malloc'd it; however, this is code that happens all the
time and wouldn't have perturbed the datalen. Your problem is most
likely coming from whatever RTP packet was sent to Asterisk. You may
want to look at a pcap of the message traffic that caused the problem
to determine what about the packet is causing the issue.
It may be necessary for something either in res_rtp_asterisk or
res_fax_spandsp to verify that the number of samples in the RTP packet
(or what the voice frame has in it before it gets handed off) matches
what is expected.
Hi Matthew,
thanks for another part of the mosaic, it seems to be more and more
complete and starts forming a picture :-).
Would it be possible, that the peer causing the segfault uses 10ms
packetization time instead of 20ms, which is required for correct operation
by libspandsp ? What does Asterisk in cases, when the peer allows 10ms
packetization only, while we are using 20ms ? Will it do a conversion,
catching two packets and presenting them as one bigger, or will it just
forward the short packets to the application ? If the second answer is
correct (which I belive is true), I think we have a candidate case for the
crash - it's caused by someone who sends 10ms packets instead of 20ms ones.
But I don't know the details of the RTP engine, whether it will even allow
the connection in such a case, or whether it will be handled similarly as
failure to find a common codec. In such a case, I can imagine a scenario,
that the peer is offering 20ms packetization, but actually sends packets
in 10ms one, thus fooling the RTP engine and causing exactly this problem.
So, yes, the pcap of such a failure would be really great! As I wrote,
I can't generate one, because in my environment, the crash is really VERY
rare and the pcap files would probably fill the whole disk and didn't catch
anything :-). Maybe Michal will have more luck with this ?
With regards,
Pavel
Hello,
I do have a pcap. Shall I attach it to:
https://issues.asterisk.org/jira/browse/ASTERISK-20149
although the title is a little bit misleading.
I thought the issue was gone after applying the latest fixes for
res_fax_spandsp and res_fax,
but the impire stroke back ....
regards
Hans
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
