[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'
jcolp at digium.com
Sat Jun 17 11:07:11 CDT 2017
On Sat, Jun 17, 2017, at 09:18 AM, Michael Maier wrote:
> 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 18.104.22.168
> 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.
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
More information about the asterisk-users