Re: [asterisk-users] asterisk 13.16. - sigseg during negotiation
On 06/18/2017 at 12:11 PM, Joshua Colp wrote: > On Sun, Jun 18, 2017, at 06:00 AM, Michael Maier wrote: >> Hello! >> >> unchanged asterisk crashes during udptl / t.38 negotiation with telekom >> - they do not support t.38 / udptl. > > All Asterisk issues need to go through the issue tracker[1]. In this > case we'd also need to see the full SIP debug so we can understand the > complete interaction. > > [1] https://issues.asterisk.org/jira > See https://issues.asterisk.org/jira/browse/ASTERISK-27061 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 13.16. - sigseg during negotiation
On Sun, Jun 18, 2017, at 06:00 AM, Michael Maier wrote: > Hello! > > unchanged asterisk crashes during udptl / t.38 negotiation with telekom > - they do not support t.38 / udptl. All Asterisk issues need to go through the issue tracker[1]. In this case we'd also need to see the full SIP debug so we can understand the complete interaction. [1] https://issues.asterisk.org/jira -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] asterisk 13.16. - sigseg during negotiation
Hello! unchanged asterisk crashes during udptl / t.38 negotiation with telekom - they do not support t.38 / udptl. In detail: 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 is attached! Regards, Michael Program terminated with signal 11, Segmentation fault. #0 ast_copy_pj_str (dest=0x7fb9f5901100 "x\277\001
Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
On 06/17/2017 at 02:18 PM, Michael Maier wrote: > On 06/16/2017 at 04:00 PM, Joshua Colp wrote: >> On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote: >> >> >> >>> >>> t38modem and asterisk are using >>> >>> m=image 35622 udptl t38 >>>^ >>> >>> Provider uses >>> >>> m=image 35622 UDPTL t38 >>>^ >>> >>> Could this be a problem? If I'm sending internal only, it's always >>> lowercase. >> >> Looking at the tests we have we only use 'udptl' as the transport. >> Without diving deep into the SDP negotiator it is possible that it gets >> upset at that, as we would only produce 'udptl'. If the SDP negotiator >> in PJSIP is case sensitive then you'd get a declined stream like you >> see. Looking at the T.38 examples from the ITU doc also shows it in >> lowercase, so uppercase is probably not commonly used. > > I can proof, that UDPTL vs. udptl is the problem. After "fixing" > asterisk and opal both using UDPTL, the negotiation works flawlessly. > See attached patches. For opal, the sip patch (src/t38/sipt38.cxx) is enough - the other two patches aren't necessary. It's only a SIP-problem. Regards, Michael -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
