[asterisk-bugs] [JIRA] (ASTERISK-27061) sigseg during t.38 reinvite / negotiation
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Wed Jun 28 08:48:59 CDT 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-27061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=237532#comment-237532 ]
Rusty Newton edited comment on ASTERISK-27061 at 6/28/17 8:48 AM:
------------------------------------------------------------------
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 ... .
Anyway, I provided them separately now.
Following, I'm trying again to describe the problem.
Fax-client sends a fax to a fax server. The fax-server sends a t.38 reinvite to the fax-client via asterisk, t.38 enabled provider (easybell), t.38 disabled provider (Telekom), asterisk, fax client. The interesting path starts up here:
Asterisk gets the initial reinivate from fax server:
{noformat}
<--- Received SIP request (961 bytes) from UDP:192.168.13.27:5060 --->
INVITE sip:asterisk at 192.168.17.45:5061 SIP/2.0
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.13.27:5060;branch=z9hG4bK8e713751-a052-e711-86c0-20aa4beaa0d8;rport
User-Agent: T38Modem/3.15.2
From: <sip:91 at 192.168.13.27>;tag=784a9850-a052-e711-86c0-20aa4beaa0d8
Call-ID: 00956b20-8c05-4291-a7bf-6de53ecb151b
Supported: 100rel,replaces
Organization: Frolov,Holtschneider,Davidson
To: "11111111111" <sip:11111111111 at 192.168.17.45>;tag=8203967c-17d0-4702-a505-cd87d60e1e1f
Contact: "root" <sip:91 at 192.168.13.27:5060>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK
Content-Length: 292
Content-Type: application/sdp
Max-Forwards: 70
v=0
o=- 1497796215 2 IN IP4 192.168.13.27
s=T38Modem/3.15.2
c=IN IP4 192.168.13.27
t=0 0
m=image 10020 udptl t38
a=sendrecv
a=T38FaxVersion:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:2000
a=T38FaxMaxDatagram:1400
a=T38FaxUdpEC:t38UDPRedundancy
a=T38MaxBitRate:14400
{noformat}
Asterisk sends this reinvite to easybell, supporting t.38
{noformat}
<--- Transmitting SIP request (1026 bytes) to UDP:195.185.37.60:5060 --->
INVITE sip:2441B741-59468E4C0005AFB2-57B1D700 at 195.185.37.60;transport=udp SIP/2.0
Via: SIP/2.0/UDP 47.23.24.13:5061;rport;branch=z9hG4bKPj90b9bd66-aac4-42d2-a573-fc899bddd4df
From: "Anonymous" <sip:+4933333333333 at sip.easybell.de>;tag=8a945beb-6a79-4b48-ab32-dea8993cd1dd
To: <sip:11111111111 at sip.easybell.de>;tag=621ADAB6-59468E4C0005A1B0-00F57700
Contact: <sip:47.23.24.13:5061>
Call-ID: fba5dd2a8960e150-Acc1802-B2b15 at 10.233.181.52_b2b-1
CSeq: 2634 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-13.0.191.11(13.16.0)
Content-Type: application/sdp
Content-Length: 249
v=0
o=- 3615070031 4 IN IP4 47.23.24.13
s=Asterisk
c=IN IP4 47.23.24.13
t=0 0
m=image 4403 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy
{noformat}
Now, easybell puts this reinivite to Telekom, which does not support t.38.
Telekom sends it to asterisk, "zeroing" IP and port in the SDP (I call it "zeroed" reinvite).
Probably it would have been better (correct?) by telekom to send back a t.38 not acceptable at this point to easybell instead of passing a "zeroed" reinvite to the client side.
Asterisk now gets the "zeroed" reinivite from Telekom:
{noformat}
<--- Received SIP request (1025 bytes) from UDP:217.0.18.36:5060 --->
INVITE sip:+4911111111111 at 47.23.24.13:5061 SIP/2.0
Max-Forwards: 59
Via: SIP/2.0/UDP 217.0.18.36:5060;branch=z9hG4bKg3Zqkv7iqilhwxg8ldenht4q1dnp7osfh
To: <sip:+4911111111111 at tel.t-online.de>;tag=9d0638f9-36ac-4029-9d2e-7cbedaf60acb
From: <sip:222222222222 at tel.t-online.de>;tag=h7g4Esbg_p65547t1497796172m158005c212284176s1_3637090326-573937032
Call-ID: 8c76f245-0d1f-41e7-884d-951fb2e511dd
CSeq: 17718 INVITE
Contact: <sip:sgc_c at 217.0.18.36;transport=udp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-Se: 900
Session-Expires: 1800;refresher=uac
Supported: timer
Supported: norefersub
Content-Type: application/sdp
Content-Length: 230
X-Hmr: iis12!ois12!
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, PUBLISH, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
v=0
o=- 1958103834 3638078137 IN IP4 0.0.0.0
s=-
t=0 0
m=image 0 udptl t38
a=sendrecv
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy
{noformat}
At this point, the problem is going on:
Asterisk is sending a completely wrong reinivte to the fax client, because it is ignoring, that telekom doesn't support t.38 at all:
{noformat}
o=- 1958103834 3638078137 IN IP4 0.0.0.0
m=image 0 udptl t38
{noformat}
At this point, it isn't a good idea to negotiate with the extension t.38. What should be done after wards? Asterisk will get t.38 packages from fax extension. But where should they sent to? It just won't work!
Anyway - asterisk didn't recognize the problem and starts t.38 negotiation with the fax extension.
{noformat}
<--- Transmitting SIP request (976 bytes) to UDP:192.168.13.27:5060 --->
INVITE sip:91 at 192.168.13.27:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.17.45:5061;rport;branch=z9hG4bKPj24004eb2-8488-4af0-bf5b-c53c1cfaf9c5
From: "CID:+4911111111111" <sip:222222222222 at 192.168.17.45>;tag=6129c79c-5ff4-4170-9474-e22c3e70a93d
To: "root" <sip:91 at 192.168.17.45>;tag=6cd7314f-a052-e711-86c0-20aa4beaa0d8
Contact: <sip:192.168.17.45:5061>
Call-ID: dcda314f-a052-e711-86c0-20aa4beaa0d8 at notebook2
CSeq: 5710 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-13.0.191.11(13.16.0)
Content-Type: application/sdp
Content-Length: 247
v=0
o=- 1497796213 5 IN IP4 192.168.17.45
s=Asterisk
c=IN IP4 192.168.17.45
t=0 0
m=image 4206 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:393
a=T38FaxUdpEC:t38UDPRedundancy
{noformat}
Asterisk now successfully performs a complete t.38 negotiation with the fax client. After the negotiation with the fax client has been successfully completed, asterisk resumes the processing of the negotiation towards Telekom. At this point, the crash happens, mostly because asterisk didn't realise at all at the very beginning receiving the zeroed package from Telekom, that it was completely wrong what it did towards the fax client. Reached this point now, asterisk can't match those two negotiations:
Firstly, asterisk told the fax client to use t.38, but this successfull negotiation can't be sent to Telekom, because Telekom already disagreed to use t.38. At this moment, asterisk crashes. It can't build an answer to Telekom.
To summarize it, or: How to reproduce it
Given is an asterisk server, providing a t.38 enabled trunk and extension. The t.38 enabled trunk gets a "zeroed" t.38 reinvite for the t.38 enabled extension. The fax extension connected to the t.38 extension of asterisk is t.38 enabled, too. From my point of view, the key question boils down to: how does asterisk handle the initial incoming *zeroed* reinivite. I don't think that it is handled correctly at this time. Create a test scenario like this and you most probably will see the crash, too.
was (Author: micha):
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 ... .
Anyway, I provided them separately now.
Following, I'm trying again to describe the problem.
Fax-client sends a fax to a fax server. The fax-server sends a t.38 reinvite to the fax-client via asterisk, t.38 enabled provider (easybell), t.38 disabled provider (Telekom), asterisk, fax client. The interesting path starts up here:
Asterisk gets the initial reinivate from fax server:
<--- Received SIP request (961 bytes) from UDP:192.168.13.27:5060 --->
INVITE sip:asterisk at 192.168.17.45:5061 SIP/2.0
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.13.27:5060;branch=z9hG4bK8e713751-a052-e711-86c0-20aa4beaa0d8;rport
User-Agent: T38Modem/3.15.2
From: <sip:91 at 192.168.13.27>;tag=784a9850-a052-e711-86c0-20aa4beaa0d8
Call-ID: 00956b20-8c05-4291-a7bf-6de53ecb151b
Supported: 100rel,replaces
Organization: Frolov,Holtschneider,Davidson
To: "11111111111" <sip:11111111111 at 192.168.17.45>;tag=8203967c-17d0-4702-a505-cd87d60e1e1f
Contact: "root" <sip:91 at 192.168.13.27:5060>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK
Content-Length: 292
Content-Type: application/sdp
Max-Forwards: 70
v=0
o=- 1497796215 2 IN IP4 192.168.13.27
s=T38Modem/3.15.2
c=IN IP4 192.168.13.27
t=0 0
m=image 10020 udptl t38
a=sendrecv
a=T38FaxVersion:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:2000
a=T38FaxMaxDatagram:1400
a=T38FaxUdpEC:t38UDPRedundancy
a=T38MaxBitRate:14400
Asterisk sends this reinvite to easybell, supporting t.38
<--- Transmitting SIP request (1026 bytes) to UDP:195.185.37.60:5060 --->
INVITE sip:2441B741-59468E4C0005AFB2-57B1D700 at 195.185.37.60;transport=udp SIP/2.0
Via: SIP/2.0/UDP 47.23.24.13:5061;rport;branch=z9hG4bKPj90b9bd66-aac4-42d2-a573-fc899bddd4df
From: "Anonymous" <sip:+4933333333333 at sip.easybell.de>;tag=8a945beb-6a79-4b48-ab32-dea8993cd1dd
To: <sip:11111111111 at sip.easybell.de>;tag=621ADAB6-59468E4C0005A1B0-00F57700
Contact: <sip:47.23.24.13:5061>
Call-ID: fba5dd2a8960e150-Acc1802-B2b15 at 10.233.181.52_b2b-1
CSeq: 2634 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-13.0.191.11(13.16.0)
Content-Type: application/sdp
Content-Length: 249
v=0
o=- 3615070031 4 IN IP4 47.23.24.13
s=Asterisk
c=IN IP4 47.23.24.13
t=0 0
m=image 4403 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy
Now, easybell puts this reinivite to Telekom, which does not support t.38.
Telekom sends it to asterisk, "zeroing" IP and port in the SDP (I call it "zeroed" reinvite).
Probably it would have been better (correct?) by telekom to send back a t.38 not acceptable at this point to easybell instead of passing a "zeroed" reinvite to the client side.
Asterisk now gets the "zeroed" reinivite from Telekom:
<--- Received SIP request (1025 bytes) from UDP:217.0.18.36:5060 --->
INVITE sip:+4911111111111 at 47.23.24.13:5061 SIP/2.0
Max-Forwards: 59
Via: SIP/2.0/UDP 217.0.18.36:5060;branch=z9hG4bKg3Zqkv7iqilhwxg8ldenht4q1dnp7osfh
To: <sip:+4911111111111 at tel.t-online.de>;tag=9d0638f9-36ac-4029-9d2e-7cbedaf60acb
From: <sip:222222222222 at tel.t-online.de>;tag=h7g4Esbg_p65547t1497796172m158005c212284176s1_3637090326-573937032
Call-ID: 8c76f245-0d1f-41e7-884d-951fb2e511dd
CSeq: 17718 INVITE
Contact: <sip:sgc_c at 217.0.18.36;transport=udp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-Se: 900
Session-Expires: 1800;refresher=uac
Supported: timer
Supported: norefersub
Content-Type: application/sdp
Content-Length: 230
X-Hmr: iis12!ois12!
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, PUBLISH, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
v=0
o=- 1958103834 3638078137 IN IP4 0.0.0.0
s=-
t=0 0
m=image 0 udptl t38
a=sendrecv
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy
At this point, the problem is going on:
Asterisk is sending a completely wrong reinivte to the fax client, because it is ignoring, that telekom doesn't support t.38 at all:
o=- 1958103834 3638078137 IN IP4 0.0.0.0
m=image 0 udptl t38
At this point, it isn't a good idea to negotiate with the extension t.38. What should be done after wards? Asterisk will get t.38 packages from fax extension. But where should they sent to? It just won't work!
Anyway - asterisk didn't recognize the problem and starts t.38 negotiation with the fax extension.
<--- Transmitting SIP request (976 bytes) to UDP:192.168.13.27:5060 --->
INVITE sip:91 at 192.168.13.27:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.17.45:5061;rport;branch=z9hG4bKPj24004eb2-8488-4af0-bf5b-c53c1cfaf9c5
From: "CID:+4911111111111" <sip:222222222222 at 192.168.17.45>;tag=6129c79c-5ff4-4170-9474-e22c3e70a93d
To: "root" <sip:91 at 192.168.17.45>;tag=6cd7314f-a052-e711-86c0-20aa4beaa0d8
Contact: <sip:192.168.17.45:5061>
Call-ID: dcda314f-a052-e711-86c0-20aa4beaa0d8 at notebook2
CSeq: 5710 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-13.0.191.11(13.16.0)
Content-Type: application/sdp
Content-Length: 247
v=0
o=- 1497796213 5 IN IP4 192.168.17.45
s=Asterisk
c=IN IP4 192.168.17.45
t=0 0
m=image 4206 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:393
a=T38FaxUdpEC:t38UDPRedundancy
Asterisk now successfully performs a complete t.38 negotiation with the fax client. After the negotiation with the fax client has been successfully completed, asterisk resumes the processing of the negotiation towards Telekom. At this point, the crash happens, mostly because asterisk didn't realise at all at the very beginning receiving the zeroed package from Telekom, that it was completely wrong what it did towards the fax client. Reached this point now, asterisk can't match those two negotiations:
Firstly, asterisk told the fax client to use t.38, but this successfull negotiation can't be sent to Telekom, because Telekom already disagreed to use t.38. At this moment, asterisk crashes. It can't build an answer to Telekom.
To summarize it, or: How to reproduce it
Given is an asterisk server, providing a t.38 enabled trunk and extension. The t.38 enabled trunk gets a "zeroed" t.38 reinvite for the t.38 enabled extension. The fax extension connected to the t.38 extension of asterisk is t.38 enabled, too. From my point of view, the key question boils down to: how does asterisk handle the initial incoming *zeroed* reinivite. I don't think that it is handled correctly at this time. Create a test scenario like this and you most probably will see the crash, too.
> 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.
> {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