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'

Hello!

I'm still trying to get a working t.38 configuration w/ pjsip.

I'm now able to send t.38 faxes to my own extension:


hylafax -> t38modem -> extension -> extension -> t38modem ->
hylafax.


The fax is sent by t38modem. The receiving part of t38modem accepts the
call, sends ReInvite for t.38 and things are working as expected.



Now, let's do the nearly same thing, but use an ISP:

hylafax -> t38modem -> extension -> trunk -> ISP ->
trunk -> extension -> t39modem(2) -> hylafax


Same procedure: the receiving t38modem(2) sends ReInvite for t.38 - but
this time, the extension / asterisk just ignores it. After the 5. retry
to switch to T.38, asterisk tells:

res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38
request on channel 'PJSIP/91-00000007'

=> Why does asterisk reject the switch / ReInvite to T.38 this time? It
never even tried to send it to the ISP!


Thanks for any hint!

Regards,
Michael

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

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Michael Maier
Sent: Sunday, June 4, 2017 3:39 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
<asterisk-users at lists.digium.com>
Subject: [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'

Hello!

I'm still trying to get a working t.38 configuration w/ pjsip.

I'm now able to send t.38 faxes to my own extension:


hylafax -> t38modem -> extension -> extension -> t38modem ->
hylafax.


The fax is sent by t38modem. The receiving part of t38modem accepts the
call, sends ReInvite for t.38 and things are working as expected.



Now, let's do the nearly same thing, but use an ISP:

hylafax -> t38modem -> extension -> trunk -> ISP -> trunk ->
extension ->
t39modem(2) -> hylafax


Same procedure: the receiving t38modem(2) sends ReInvite for t.38 - but this
time, the extension / asterisk just ignores it. After the 5. retry to switch
to T.38, asterisk tells:

res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38
request on channel 'PJSIP/91-00000007'

=> Why does asterisk reject the switch / ReInvite to T.38 this time? It
never even tried to send it to the ISP!


Thanks for any hint!

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

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