On Sat, Jun 17, 2017, at 09:18 AM, Michael Maier wrote: <snip>
> > 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. > > Sending t38 faxes internally works fine. Externally via provider gets > stuck: the provider doesn't send back any t38-package to the client > (t38-packages are leaving asterisk towards the provider, but the > provider doesn't send back any package to the client :-(). > > Any idea what to change to get the provider to communicate? > > (From the 200 Ok from the provider - nothing critical from my point of > view - these are the values I sent in the reinvite to the provider) > > Connection Information (c): IN IP4 195.185.37.60 > Time Description, active time (t): 0 0 > Media Description, name and address (m): image 31410 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 Nope, I don't really have anything to add to try to make it communicate. T.38 support over all can be very problematic depending on the endpoint. -- 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