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

[Michael Maier (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Maier updated ASTERISK-27061:
-------------------------------------

    Attachment: callflow-2.png
                callflow-1.png

Graphical overview of connections as seen by wireshark until the crash happens.

192.168.13.27 is fax client and fax server.
192.168.17.45 and 47.23.24.13 represents the multihomed asterisk server
217.0.18.36 is the sip telekom server
195.185.37.60 is the sip and rtp easybell server
217.0.4.230 is the telekom rtp server

Hope this helps a little bit to more easily understand what's going on until the crash happens.

> 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, 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.
>    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)