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 Mon, Jun 5, 2017, at 12:00 PM, Joshua Colp wrote:
> On Mon, Jun 5, 2017, at 11:49 AM, Michael Maier wrote:
> > 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
> 
> And the pjsip.conf endpoint entry for easybellPJSIP_FAX?
I plugged the provided configuration into an existing testsuite test
quickly and things still worked as expected, so it's something outside
of that but nothing stands out in the debug log. I'd suggest filing an
issue[1] with all the logs and such, it'll allow whomever works on the
issue to write a specific testsuite test and hopefully recreate it in a
controlled environment.

[1] https://issues.asterisk.org/jira

-- 
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 06:10 PM, Joshua Colp wrote:
> On Mon, Jun 5, 2017, at 12:00 PM, Joshua Colp wrote:
>> On Mon, Jun 5, 2017, at 11:49 AM, Michael Maier wrote:
>>> 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
>>
>> And the pjsip.conf endpoint entry for easybellPJSIP_FAX?
> 
> I plugged the provided configuration into an existing testsuite test
> quickly and things still worked as expected, so it's something outside
> of that but nothing stands out in the debug log.
Do you have any idea where to start to look at? Adding additional output
in the source code? Which functions could be interesting? I may add own
debug code to see why things are happening as they happen here.


Thanks,
Michael

On Mon, Jun 5, 2017, at 01:22 PM, Michael Maier wrote:
> 
> Do you have any idea where to start to look at? Adding additional output
> in the source code? Which functions could be interesting? I may add own
> debug code to see why things are happening as they happen here.
The logic for T.38 negotiation lives all in the res_pjsip_t38 module and
the request to negotiate works using a control frame which is handled by
the t38_interpret_parameters function. It's up to that to initialize
things and then request that a session refresh occurs (which sends the
re-invite). That'd be the place to look.

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