asterisk users - Jun 2017 - 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/04/2017 at 01:41 PM Telium Technical Support
wrote:
> Just a guess (without knowing about your network), but are the two ends
> points on public networks and visible to one another?  If not the reinvite
> may be passing an internal (nat'ed) address to the other and the
connection
> will fail...just a though
t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen
udp\$127.0.0.1:6060 --ptty +/dev/ttyT380,+/dev/ttyT381 --route
'modem:.*=sip:<dn>@127.0.0.1:5061' --route
'sip:.*=modem:<dn>'
--sip-register 91 at 127.0.0.1:5061,password

I tried it with a global IP (instead of 127.0.0.1) - same behavior.

The point is, that the receiving part, which initiates the t.38 switch,
doesn't sent the switch to the ISP. It is blocked / ignored by asterisk
at all - don't know why it isn't sent to the ISP.

The extension is a normal pjsip extension with these additional options:


 t38_udptl                          : true
 t38_udptl_ec                       : redundancy
 t38_udptl_ipv6                     : false
 t38_udptl_maxdatagram              : 400
 t38_udptl_nat                      : no (or yes - doesn't matter)


The trunk looks exactly the same:

 t38_udptl                          : true
 t38_udptl_ec                       : redundancy
 t38_udptl_ipv6                     : false
 t38_udptl_maxdatagram              : 400
 t38_udptl_nat                      : no (or yes - doesn't matter)



Thanks,
Michael

On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote:
> On 06/04/2017 at 01:41 PM Telium Technical Support wrote:
> > Just a guess (without knowing about your network), but are the two
ends
> > points on public networks and visible to one another?  If not the
reinvite
> > may be passing an internal (nat'ed) address to the other and the
connection
> > will fail...just a though
> 
> t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen
> udp\$127.0.0.1:6060 --ptty +/dev/ttyT380,+/dev/ttyT381 --route
> 'modem:.*=sip:<dn>@127.0.0.1:5061' --route
'sip:.*=modem:<dn>'
> --sip-register 91 at 127.0.0.1:5061,password
> 
> I tried it with a global IP (instead of 127.0.0.1) - same behavior.
> 
> The point is, that the receiving part, which initiates the t.38 switch,
> doesn't sent the switch to the ISP. It is blocked / ignored by asterisk
> at all - don't know why it isn't sent to the ISP.
I'd suggest providing the console output and SIP traffic (pjsip set
logger on) so we can see exactly what is going on.

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

On 06/05/2017 at 11:30 AM, Joshua Colp wrote:
> On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote:
>> On 06/04/2017 at 01:41 PM Telium Technical Support wrote:
>>> Just a guess (without knowing about your network), but are the two
ends
>>> points on public networks and visible to one another?  If not the
reinvite
>>> may be passing an internal (nat'ed) address to the other and
the connection
>>> will fail...just a though
>>
>> t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen
>> udp\$127.0.0.1:6060 --ptty +/dev/ttyT380,+/dev/ttyT381 --route
>> 'modem:.*=sip:<dn>@127.0.0.1:5061' --route
'sip:.*=modem:<dn>'
>> --sip-register 91 at 127.0.0.1:5061,password
>>
>> I tried it with a global IP (instead of 127.0.0.1) - same behavior.
>>
>> The point is, that the receiving part, which initiates the t.38 switch,
>> doesn't sent the switch to the ISP. It is blocked / ignored by
asterisk
>> at all - don't know why it isn't sent to the ISP.
> 
> I'd suggest providing the console output and SIP traffic (pjsip set
> logger on) so we can see exactly what is going on.
> 
I attached the debug output I already created before.

Interesting part starts around line 2740.


91 -> local pjsip fax-extension

127.0.0.1:5061 -> asterisk server local connect for fax-extension (->
not encrypted even if it is port 5061!)

external fax number at easybell (195.185.37.60), which is called and
which is answered here: 11111222222




Thanks,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t38.debug.bz2
Type: application/x-bzip
Size: 23348 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170605/96bc11ae/attachment.bin>