[asterisk-bugs] [JIRA] (ASTERISK-27061) Crash/segfault during T.38 reinvite / negotiation

Rusty Newton (JIRA) noreply at issues.asterisk.org
Sat Jul 1 13:13:59 CDT 2017


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

Rusty Newton commented on ASTERISK-27061:
-----------------------------------------

[~micha] , thanks for the detailed description and analysis as well as debug information.

bq. If you don't want to have tar.gz files, please don't write at https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace that you would like to have them ... .

Sorry about the confusion there. I forgot momentarily that we changed that requirement a while back. I'm used to doing it a particular way for years - hard to change the habit. :)

I'm opening the issue up as you've provided plenty of information for the issue to be investigated.

> Crash/segfault 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
>         Attachments: asterisk-sigseg.coredump, callflow-1.png, callflow-2.png, 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.
> {noformat}
>    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
> {noformat}
> This reinvite is received by asterisk via telekom:
> {noformat}
>    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
> {noformat}
> And asterisk gives it to the fax client:
> {noformat}
>    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
> {noformat}
> 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)



More information about the asterisk-bugs mailing list