Joshua Colp
2017-Jun-05 16:10 UTC
[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'
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
Michael Maier
2017-Jun-05 16:22 UTC
[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'
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
Joshua Colp
2017-Jun-05 16:29 UTC
[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'
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