[asterisk-bugs] [JIRA] (ASTERISK-27061) sigseg during t.38 reinvite / negotiation

Fri Jun 23 04:22:59 CDT 2017

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=237534#comment-237534 ] 

Michael Maier commented on ASTERISK-27061:
------------------------------------------

The config: nothing special. As the machine is a multihomed machine (local and global IP), NAT isn't relevant at all.

[telekomPJSIP-111]
type=endpoint
transport=0.0.0.0-udp
context=from-trunk
disallow=all
allow=alaw
aors=telekomPJSIP-111
language=de
outbound_auth=telekomPJSIP-111
from_domain=tel.t-online.de
t38_udptl=yes
t38_udptl_ec=redundancy
fax_detect=no
t38_udptl_nat=no or yes
dtmf_mode=rfc4733
tos_audio=0xb8
direct_media=no

[91]
type=endpoint
aors=91
auth=91-auth
disallow=all
allow=alaw,ulaw
context=from-fax-extension
callerid=device <91>
dtmf_mode=rfc4733
aggregate_mwi=yes
use_avpf=no
ice_support=no
media_use_received_transport=no
trust_id_inbound=yes
media_encryption=no
timers=yes
media_encryption_optimistic=no
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=de
t38_udptl=yes
t38_udptl_ec=redundancy
direct_media=no
t38_udptl_maxdatagram=400
t38_udptl_nat=no or yes

[easybellPJSIP]
type=endpoint
transport=0.0.0.0-udp
context=from-trunk
disallow=all
allow=g722,alaw
aors=easybellPJSIP
language=de
outbound_auth=easybellPJSIP
from_domain=sip.easybell.de
t38_udptl=yes
t38_udptl_ec=redundancy
fax_detect=no
t38_udptl_nat=no or yes
send_rpid=yes
send_pai=yes
dtmf_mode=auto

If you want to rebuild my binaries, I could provide you with the src.rpm-file for CentOS 6.9. But it exceeds 10 MB (31 MB). Therefore, if you want to have it, please drop me a note where to send it to.

The relevant part of the spec-File:

menuselect/menuselect --disable-category MENUSELECT_CORE_SOUNDS --disable-category MENUSELECT_EXTRA_SOUNDS --disable-category MENUSELECT_MOH --enable-category MENUSELECT_ADDONS --enable res_pktccops --enable chan_mgcp --enable chan_motif --enable app_meetme --enable app_page --enable res_snmp --enable res_srtp --enable DONT_OPTIMIZE --enable BETTER_BACKTRACES --disable BUILD_NATIVE --enable res_statsd --enable res_chan_stats --enable res_endpoint_stats menuselect.makeopts

ps -C asterisk u
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
asterisk 28280  2.6  4.5 2022472 91640 ?       Sl   Jun20 104:25 /usr/sbin/asterisk -f -U asterisk -G asterisk -g -v -v -vvvg -c

-> I don't know how to provide better stack traces.

The pcap trace file wouldn't contain anything more as already described in this bug report. For me, it contains sensible data I'm not willing to provide - sorry. But if you have a piece of code, which *completely* anonymizes the trace ... .

> sigseg during t.38 reinvite / negotiation
> -----------------------------------------
>
>                 Key: ASTERISK-27061
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27061
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.16.0
>         Environment: Centos 6, 64 bit
>            Reporter: Michael Maier
>            Assignee: Michael Maier
>         Attachments: asterisk-sigseg.coredump, core.myfw-2017-06-20T18-35-52+0200-brief.txt, core.myfw-2017-06-20T18-35-52+0200-full.txt, core.myfw-2017-06-20T18-35-52+0200-locks.txt, core.myfw-2017-06-20T18-35-52+0200-thread1.txt, core.tar.gz, sigseg-on-reinvite
>
>
> sigseg happens during sending of a fax / t.38 the following way:
> fax client -> asterisk -> telekom -> easybell -> asterisk -> fax server
> Fax server sends t.38 reinvite via asterisk to easybell.
>    Session Description Protocol Version (v): 0
>    Owner/Creator, Session Id (o): - 2447581897 4 IN IP4 46.17.15.23
>    Session Name (s): Asterisk
>    Connection Information (c): IN IP4 46.17.15.23
>    Time Description, active time (t): 0 0
>    Media Description, name and address (m): image 4573 udptl t38
>    Media Attribute (a): T38FaxVersion:0
>    Media Attribute (a): T38MaxBitRate:14400
>    Media Attribute (a): T38FaxRateManagement:transferredTCF
>    Media Attribute (a): T38FaxMaxDatagram:397
>    Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy
> This reinvite is received by asterisk via telekom:
>    Session Description Protocol Version (v): 0
>    Owner/Creator, Session Id (o): - 1811299599 2925027276 IN IP4 0.0.0.0
>    Session Name (s): -
>    Time Description, active time (t): 0 0
>    Media Description, name and address (m): image 0 udptl t38
>    Media Attribute (a): sendrecv
>    Media Attribute (a): T38FaxVersion:0
>    Media Attribute (a): T38MaxBitRate:14400
>    Media Attribute (a): T38FaxRateManagement:transferredTCF
>    Media Attribute (a): T38FaxMaxDatagram:397
>    Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy
> And asterisk gives it to the fax client:
>    Session Description Protocol Version (v): 0
>    Owner/Creator, Session Id (o): - 1497774025 5 IN IP4 192.168.12.13
>    Session Name (s): Asterisk
>    Connection Information (c): IN IP4 192.168.12.13
>    Time Description, active time (t): 0 0
>    Media Description, name and address (m): image 4284 udptl t38
>    Media Attribute (a): T38FaxVersion:0
>    Media Attribute (a): T38MaxBitRate:14400
>    Media Attribute (a): T38FaxRateManagement:transferredTCF
>    Media Attribute (a): T38FaxMaxDatagram:393
>    Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy
> Completely ignoring, that telekom doesn't support it (port and ip
> addresses are set to 0).
> On completing the negotiation after 200 ok SDP and ACK from fax client,
> asterisk crashes. Stack trace and asterisk log is attached!

--
This message was sent by Atlassian JIRA
(v6.2#6252)