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

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?

-- 
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 05: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?
> 
[easybellPJSIP_FAX]
type=endpoint
transport=0.0.0.0-udp
context=from-trunk
disallow=all
allow=alaw,ulaw
aors=easybellPJSIP_FAX
language=de
outbound_auth=easybellPJSIP_FAX
from_domain=sip.easybell.de
from_user=+4911112222222
t38_udptl=yes
t38_udptl_ec=redundancy
fax_detect=no
t38_udptl_nat=no
send_rpid=yes
send_pai=yes
dtmf_mode=rfc4733
tos_audio=0xb8
direct_media=yes
rewrite_contact=no
force_rport=yes



 ParameterName                      : ParameterValue
 ======================================================== 100rel                
: yes
 accountcode                        :
 acl                                :
 aggregate_mwi                      : true
 allow                              : (alaw|ulaw)
 allow_overlap                      : true
 allow_subscribe                    : true
 allow_transfer                     : true
 aors                               : easybellPJSIP_FAX
 asymmetric_rtp_codec               : false
 auth                               :
 bind_rtp_to_media_address          : false
 call_group                         :
 callerid                           : <unknown>
 callerid_privacy                   : allowed_not_screened
 callerid_tag                       :
 connected_line_method              : invite
 contact_acl                        :
 context                            : from-trunk
 cos_audio                          : 0
 cos_video                          : 0
 device_state_busy_at               : 0
 direct_media                       : true
 direct_media_glare_mitigation      : none
 direct_media_method                : invite
 disable_direct_media_on_nat        : false
 dtls_ca_file                       :
 dtls_ca_path                       :
 dtls_cert_file                     :
 dtls_cipher                        :
 dtls_fingerprint                   : SHA-256
 dtls_private_key                   :
 dtls_rekey                         : 0
 dtls_setup                         : active
 dtls_verify                        : No
 dtmf_mode                          : rfc4733
 fax_detect                         : false
 fax_detect_timeout                 : 0
 force_avp                          : false
 force_rport                        : true
 from_domain                        : sip.easybell.de
 from_user                          : +4911112222222
 g726_non_standard                  : false
 ice_support                        : false
 identify_by                        : username
 inband_progress                    : false
 language                           : de
 mailboxes                          :
 media_address                      :
 media_encryption                   : no
 media_encryption_optimistic        : false
 media_use_received_transport       : false
 message_context                    :
 moh_suggest                        : default
 mwi_from_user                      :
 mwi_subscribe_replaces_unsolicited : false
 named_call_group                   :
 named_pickup_group                 :
 one_touch_recording                : false
 outbound_auth                      : easybellPJSIP_FAX
 outbound_proxy                     :
 pickup_group                       :
 record_off_feature                 : automixmon
 record_on_feature                  : automixmon
 rewrite_contact                    : false
 rpid_immediate                     : false
 rtcp_mux                           : false
 rtp_engine                         : asterisk
 rtp_ipv6                           : false
 rtp_keepalive                      : 0
 rtp_symmetric                      : false
 rtp_timeout                        : 0
 rtp_timeout_hold                   : 0
 sdp_owner                          : -
 sdp_session                        : Asterisk
 send_diversion                     : true
 send_pai                           : true
 send_rpid                          : true
 set_var                            :
 srtp_tag_32                        : false
 sub_min_expiry                     : 0
 subscribe_context                  :
 t38_udptl                          : true
 t38_udptl_ec                       : redundancy
 t38_udptl_ipv6                     : false
 t38_udptl_maxdatagram              : 0
 t38_udptl_nat                      : false
 timers                             : yes
 timers_min_se                      : 90
 timers_sess_expires                : 1800
 tone_zone                          :
 tos_audio                          : 184
 tos_video                          : 0
 transport                          : 0.0.0.0-udp
 trust_id_inbound                   : false
 trust_id_outbound                  : false
 use_avpf                           : false
 use_ptime                          : false
 user_eq_phone                      : false
 voicemail_extension                :


Thanks,
Michael

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