Michael Maier
2017-Jun-05 14:49 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 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>
Joshua Colp
2017-Jun-05 15:00 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 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: 11111222222And 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
Michael Maier
2017-Jun-05 15:40 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 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
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