[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'

[Joshua Colp]

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