Sending fax suddenly "Call failed to go through"

Asterisk Asterisk Fax
1

Hi, I’m using Asterisk PBX 16.13.0. Receiving fax is still ok but sending fax stopped working a few days ago. Despite regular Debian 10 updates, I’m not aware that anything else changed.

I’m sending fax from PC via call file. The tiff to send as fax and the call file are copied to asterisk server. Ownership is then changed to user asterisk. After that, the call file is moved to outgoing. Asterisk picks it up and calls the number set via call file. Unfortunately, after the T.38 Negotiation Timeout the call fails, see log. Looks like negotiation fails. Tested with a known AVM Fritzbox 7530 after attempts to other destinations failed to get sent.

I’d be grateful for any hint. I’ve searched the wiki, the forum, and internet without results. I even created a new virtual machine with Debian 11 and Asterisk 18 but the problem is the same. I’m pretty sure, it is a config error but I cannot figure it out.
If I missed vital information please let me know and I’ll get it.
Thanks a lot.

My send fax extension:

[fax-send]
exten = sendfax,1,NoOp(send Fax)
same  = n,Set(CALLERID(name-charset)=utf8)
same  = n,Set(FAXOPT(headerinfo)=Robert <03033445566>)
same  = n,Set(FAXOPT(localstationid)=00493033445566)
same  = n,Set(FAXOPT(ecm)=yes)
same  = n,SendFAX(/tmp/${FN},df)
same  = n,Verbose(1,STATUS: ${FAXSTATUS})
same  = n,ExecIf($["${FAXERROR}" != ""]?Verbose(ERROR: ${FAXERROR}):Verbose(Fax ok))
same  = n,NoOp(remove temporary file /tmp/${FN})
same  = n,System(rm /tmp/${FN})
same  = n,Hangup

My call file:

Channel: PJSIP/03088776655@telekom1
CallerID: "Robert" <03033445566>
WaitTime: 20
Context: fax-send
Extension: sendfax
Priority: 1
Setvar: RECnr=03088776655
Setvar: FN=fax-file.tiff
Archive: No

FAX For Asterisk Settings:
	ECM: Enabled
	Status Events: On
	Minimum Bit Rate: 4800
	Maximum Bit Rate: 14400
	Modem Modulations Allowed: V17,V27,V29
	T.38 Negotiation Timeout: 10000

Log data:

[Feb 27 19:09:19]     -- Attempting call on PJSIP/03088776655@telekom1 for sendfax@fax-send:1 (Retry 1)
[Feb 27 19:09:19]     -- Called 03088776655@telekom1
[Feb 27 19:09:19] <--- Transmitting SIP request (921 bytes) to UDP:217.0.26.23:5060 --->
[Feb 27 19:09:19] INVITE sip:03088776655@tel.t-online.de SIP/2.0
[Feb 27 19:09:19] Via: SIP/2.0/UDP 192.168.2.10:5064;rport;branch=z9hG4bKPj3e24f9bc-74fc-4bcb-91b8-32f3bf9ad1f8
[Feb 27 19:09:19] From: <sip:03033445566@tel.t-online.de>;tag=a9c0d495-7407-4d12-b0a7-419c4d530ea1
[Feb 27 19:09:19] To: <sip:03088776655@tel.t-online.de>
[Feb 27 19:09:19] Contact: <sip:03033445566@192.168.2.10:5064>
[Feb 27 19:09:19] Call-ID: f906416d-c355-4f9a-abde-a84227f39372
[Feb 27 19:09:19] CSeq: 1542 INVITE
[Feb 27 19:09:19] Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
[Feb 27 19:09:19] Supported: 100rel, timer, replaces, norefersub
[Feb 27 19:09:19] Session-Expires: 1800
[Feb 27 19:09:19] Min-SE: 90
[Feb 27 19:09:19] Max-Forwards: 70
[Feb 27 19:09:19] User-Agent: Asterisk PBX 16.13.0
[Feb 27 19:09:19] Content-Type: application/sdp
[Feb 27 19:09:19] Content-Length:   239
[Feb 27 19:09:19] 
[Feb 27 19:09:19] v=0
[Feb 27 19:09:19] o=- 124459973 124459973 IN IP4 192.168.2.10
[Feb 27 19:09:19] s=Asterisk
[Feb 27 19:09:19] c=IN IP4 192.168.2.10
[Feb 27 19:09:19] t=0 0
[Feb 27 19:09:19] m=audio 18070 RTP/AVP 8 101
[Feb 27 19:09:19] a=rtpmap:8 PCMA/8000
[Feb 27 19:09:19] a=rtpmap:101 telephone-event/8000
[Feb 27 19:09:19] a=fmtp:101 0-16
[Feb 27 19:09:19] a=ptime:20
[Feb 27 19:09:19] a=maxptime:150
[Feb 27 19:09:19] a=sendrecv
[Feb 27 19:09:19] 
[Feb 27 19:09:19] <--- Received SIP response (561 bytes) from UDP:217.0.26.23:5060 --->
[Feb 27 19:09:19] SIP/2.0 407 Proxy Authentication Required 02035034C
[Feb 27 19:09:19] Via: SIP/2.0/UDP 192.168.2.10:5064;received=46.95.216.75;rport=45064;branch=z9hG4bKPj3e24f9bc-74fc-4bcb-91b8-32f3bf9ad1f8
[Feb 27 19:09:19] To: <sip:03088776655@tel.t-online.de>;tag=h7g4Esbg_9905644109871cced0ec48c85b24c510
[Feb 27 19:09:19] From: <sip:03033445566@tel.t-online.de>;tag=a9c0d495-7407-4d12-b0a7-419c4d530ea1
[Feb 27 19:09:19] Call-ID: f906416d-c355-4f9a-abde-a84227f39372
[Feb 27 19:09:19] CSeq: 1542 INVITE
[Feb 27 19:09:19] Content-Length: 0
[Feb 27 19:09:19] Proxy-Authenticate: Digest nonce="1265C7975BBE1B61000000003503C46E",realm="tel.t-online.de",algorithm=MD5,qop="auth",stale=true
[Feb 27 19:09:19] 
[Feb 27 19:09:19] 
[Feb 27 19:09:19] <--- Transmitting SIP request (445 bytes) to UDP:217.0.26.23:5060 --->
[Feb 27 19:09:19] ACK sip:03088776655@tel.t-online.de SIP/2.0
[Feb 27 19:09:19] Via: SIP/2.0/UDP 192.168.2.10:5064;rport;branch=z9hG4bKPj3e24f9bc-74fc-4bcb-91b8-32f3bf9ad1f8
[Feb 27 19:09:19] From: <sip:03033445566@tel.t-online.de>;tag=a9c0d495-7407-4d12-b0a7-419c4d530ea1
[Feb 27 19:09:19] To: <sip:03088776655@tel.t-online.de>;tag=h7g4Esbg_9905644109871cced0ec48c85b24c510
[Feb 27 19:09:19] Call-ID: f906416d-c355-4f9a-abde-a84227f39372
[Feb 27 19:09:19] CSeq: 1542 ACK
[Feb 27 19:09:19] Max-Forwards: 70
[Feb 27 19:09:19] User-Agent: Asterisk PBX 16.13.0
[Feb 27 19:09:19] Content-Length:  0
[Feb 27 19:09:19] 
[Feb 27 19:09:19] 
[Feb 27 19:09:19] <--- Transmitting SIP request (1205 bytes) to UDP:217.0.26.23:5060 --->
[Feb 27 19:09:19] INVITE sip:03088776655@tel.t-online.de SIP/2.0
[Feb 27 19:09:19] Via: SIP/2.0/UDP 192.168.2.10:5064;rport;branch=z9hG4bKPj8a069d08-79ee-4398-b7c5-21fda7f9efd7
[Feb 27 19:09:19] From: <sip:03033445566@tel.t-online.de>;tag=a9c0d495-7407-4d12-b0a7-419c4d530ea1
[Feb 27 19:09:19] To: <sip:03088776655@tel.t-online.de>
[Feb 27 19:09:19] Contact: <sip:03033445566@192.168.2.10:5064>
[Feb 27 19:09:19] Call-ID: f906416d-c355-4f9a-abde-a84227f39372
[Feb 27 19:09:19] CSeq: 1543 INVITE
[Feb 27 19:09:19] Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
[Feb 27 19:09:19] Supported: 100rel, timer, replaces, norefersub
[Feb 27 19:09:19] Session-Expires: 1800
[Feb 27 19:09:19] Min-SE: 90
[Feb 27 19:09:19] Max-Forwards: 70
[Feb 27 19:09:19] User-Agent: Asterisk PBX 16.13.0
[Feb 27 19:09:19] Proxy-Authorization: Digest username="03033445566", realm="tel.t-online.de", nonce="1265C7975BBE1B61000000003503C46E", uri="sip:03088776655@tel.t-online.de", response="377497ce3972b76192295dd49dc0639d", algorithm=MD5, cnonce="c1289b9734c346e8a56c5a1c605acce7", qop=auth, nc=00000001
[Feb 27 19:09:19] Content-Type: application/sdp
[Feb 27 19:09:19] Content-Length:   239
[Feb 27 19:09:19] 
[Feb 27 19:09:19] v=0
[Feb 27 19:09:19] o=- 124459973 124459973 IN IP4 192.168.2.10
[Feb 27 19:09:19] s=Asterisk
[Feb 27 19:09:19] c=IN IP4 192.168.2.10
[Feb 27 19:09:19] t=0 0
[Feb 27 19:09:19] m=audio 18070 RTP/AVP 8 101
[Feb 27 19:09:19] a=rtpmap:8 PCMA/8000
[Feb 27 19:09:19] a=rtpmap:101 telephone-event/8000
[Feb 27 19:09:19] a=fmtp:101 0-16
[Feb 27 19:09:19] a=ptime:20
[Feb 27 19:09:19] a=maxptime:150
[Feb 27 19:09:19] a=sendrecv
[Feb 27 19:09:19] 
[Feb 27 19:09:20] <--- Received SIP response (353 bytes) from UDP:217.0.26.23:5060 --->
[Feb 27 19:09:20] SIP/2.0 100 Trying
[Feb 27 19:09:20] Via: SIP/2.0/UDP 192.168.2.10:5064;received=46.95.216.75;rport=45064;branch=z9hG4bKPj8a069d08-79ee-4398-b7c5-21fda7f9efd7
[Feb 27 19:09:20] To: <sip:03088776655@tel.t-online.de>
[Feb 27 19:09:20] From: <sip:03033445566@tel.t-online.de>;tag=a9c0d495-7407-4d12-b0a7-419c4d530ea1
[Feb 27 19:09:20] Call-ID: f906416d-c355-4f9a-abde-a84227f39372
[Feb 27 19:09:20] CSeq: 1543 INVITE
[Feb 27 19:09:20] Content-Length: 0
[Feb 27 19:09:20] 
[Feb 27 19:09:20] 
[Feb 27 19:09:20] <--- Received SIP response (637 bytes) from UDP:217.0.26.23:5060 --->
[Feb 27 19:09:20] SIP/2.0 183 Session Progress
[Feb 27 19:09:20] Via: SIP/2.0/UDP 192.168.2.10:5064;received=46.95.216.75;rport=45064;branch=z9hG4bKPj8a069d08-79ee-4398-b7c5-21fda7f9efd7
[Feb 27 19:09:20] To: <sip:03088776655@tel.t-online.de>;tag=h7g4Esbg_p65546t1645985360m107372c122730s1_3568435303-1683367824
[Feb 27 19:09:20] From: <sip:03033445566@tel.t-online.de>;tag=a9c0d495-7407-4d12-b0a7-419c4d530ea1
[Feb 27 19:09:20] Call-ID: f906416d-c355-4f9a-abde-a84227f39372
[Feb 27 19:09:20] CSeq: 1543 INVITE
[Feb 27 19:09:20] Contact: <sip:sgc_c@217.0.26.23;transport=udp>
[Feb 27 19:09:20] Record-Route: <sip:217.0.26.23;transport=udp;lr>
[Feb 27 19:09:20] P-Early-Media: inactive, gated
[Feb 27 19:09:20] Content-Length: 0
[Feb 27 19:09:20] Allow: UPDATE, NOTIFY, PRACK, OPTIONS, BYE, ACK, CANCEL, INVITE, REGISTER
[Feb 27 19:09:20] 
[Feb 27 19:09:20] 
[Feb 27 19:09:20]     -- PJSIP/telekom1-00000001 is making progress
[Feb 27 19:09:20]     -- PJSIP/telekom1-00000001 is making progress
[2022-02-27 19:09:39.837] NOTICE[28637]: pbx_spool.c:450 attempt_thread: Call failed to go through, reason (3) Remote end Ringing
[2022-02-27 19:09:39.837] NOTICE[28637]: pbx_spool.c:453 attempt_thread: Queued call to PJSIP/03088776655@telekom1 expired without completion after 0 attempts
[Feb 27 19:09:39] <--- Transmitting SIP request (428 bytes) to UDP:217.0.26.23:5060 --->
[Feb 27 19:09:39] CANCEL sip:03088776655@tel.t-online.de SIP/2.0
[Feb 27 19:09:39] Via: SIP/2.0/UDP 192.168.2.10:5064;rport;branch=z9hG4bKPj8a069d08-79ee-4398-b7c5-21fda7f9efd7
[Feb 27 19:09:39] From: <sip:03033445566@tel.t-online.de>;tag=a9c0d495-7407-4d12-b0a7-419c4d530ea1
[Feb 27 19:09:39] To: <sip:03088776655@tel.t-online.de>
[Feb 27 19:09:39] Call-ID: f906416d-c355-4f9a-abde-a84227f39372
[Feb 27 19:09:39] CSeq: 1543 CANCEL
[Feb 27 19:09:39] Reason: Q.850;cause=0
[Feb 27 19:09:39] Max-Forwards: 70
[Feb 27 19:09:39] User-Agent: Asterisk PBX 16.13.0
[Feb 27 19:09:39] Content-Length:  0
[Feb 27 19:09:39] 
[Feb 27 19:09:39] 
[Feb 27 19:09:39] <--- Received SIP response (447 bytes) from UDP:217.0.26.23:5060 --->
[Feb 27 19:09:39] SIP/2.0 481 Call/Transaction Does Not Exist
[Feb 27 19:09:39] Via: SIP/2.0/UDP 192.168.2.10:5064;received=46.95.216.75;rport=45064;branch=z9hG4bKPj8a069d08-79ee-4398-b7c5-21fda7f9efd7
[Feb 27 19:09:39] To: <sip:03088776655@tel.t-online.de>;tag=h7g4Esbg_p65546t1645985360m107372c122730s1_3568435303-1683367824
[Feb 27 19:09:39] From: <sip:03033445566@tel.t-online.de>;tag=a9c0d495-7407-4d12-b0a7-419c4d530ea1
[Feb 27 19:09:39] Call-ID: f906416d-c355-4f9a-abde-a84227f39372
[Feb 27 19:09:39] CSeq: 1543 CANCEL
[Feb 27 19:09:39] Content-Length: 0
2

Your SIP headers have two special specials feature with regard to the Telekom connection: via headers with a LAN address and a national number in the INVITE.

The telecomedians do “connected media” wherever possible, but that also depends on your router and its settings. It is usually better to have proper forwarding and NAT outbound rules in addition to telling PJSIP your WAN address. There’s not enough information to see what is going on.

I am pretty sure that you need a valid and complete number according to E.164, i.e. something that starts with +49 or 0049 in your case.

In order to get any help here at all, you need to specify your entire PJSIP configuration and tell us what works and what not. For example, do incoming calls work?

The general rule is: unless you have read 1TR114, hic sunt dracones.

3

Thank you very much for the quick response and for taking the time to read this long answer. I’ll start with answering your questions.
What is working: Outgoing and incoming telephony (Telekom* plus three other VoIP provider) is working. Receiving fax (Telekom) is working. Internal calls are working.
*Incoming mobile calls from some mobile provider are not working with Telekom, but no SIP message whatsoever is reaching Asterisk. Incoming calls from landlines are fine. All other provider receive calls from landlines and mobiles.
Just to clarify: telekom1 is a line dedicated to fax only, although I can make outgoing calls through it. Incoming calls on telekom1 are redirected to receive-fax context. There is a telekom2 definition with different number and credentials sharing the same transport etc. And, as described above, calls in and out are working.
Router (Draytek Vigor 130): SIP ALG is disabled, Port Redirections 10000-60000 → 192.168.2.10

It is usually better to have proper forwarding and NAT outbound rules in addition to telling PJSIP your WAN address.

To reflect this, I changed the transport definition.

[transport-udp-telekom]
type=transport
protocol=udp
bind=0.0.0.0:5064
local_net=192.168.0.0/16
external_media_address=m53245.dyndns.org    
external_signaling_address=m53245.dyndns.org

Now my external ip is included in the header Via: SIP/2.0/UDP 46.95.98.25:5064;rport;branch=z9hG4bKPjff348061-69fe-42ed-ad1c-5d045935cb75
Unfortunately, fax fails and the message exchange stays the same INVITE -> 407 Proxy -> ACK -> INVITE -> 100 Trying -> 183 Session Progress -> 100 Trying -> 183 Session Progress -> CANCEL -> 481 Call/Transaction Does Not Exist

I am pretty sure that you need a valid and complete number according to E.164, i.e. something that starts with +49 or 0049 in your case.

contact_user, client_uri use the +49 prefix, contact_user, from_user, username do not. As outlined above, telephony works and even receiving fax works. In addition, when sending a fax an outbound connection is established. Maybe I overlook something but if it’s a problem with the credentials I should not be able to establish an outgoing call.

you need to specify your entire PJSIP configuration

Here is all related (skipped other providers and endpoints):

[endpoint_telekom](!)
type=endpoint
transport=transport-udp-telekom
context=from-pstn-toheader
disallow=all
allow=alaw,g722
language=de
from_domain=tel.t-online.de

[reg_telekom](!)
type=registration
transport=transport-udp-telekom
retry_interval=60
fatal_retry_interval=30
forbidden_retry_interval=30
max_retries=100
expiration=480
auth_rejection_permanent=no
line=yes

[telekom1_out]
type=auth
auth_type=userpass
password=secret
username=03033445566
realm=tel.t-online.de

[telekom1](endpoint_telekom)
outbound_auth=telekom1_out
from_user=03033445566
contact_user=03033445566
aors=telekom1
allow=!all,alaw
; following lines added after changing transport to externip. 
; Not sure it is needed. Either way the problem stays the same and 
; no additional problem occured.
rtp_symmetric = yes
force_rport = yes
ice_support = yes
rewrite_contact = yes
direct_media = no

[telekom1]
type=identify
endpoint=telekom1
match=tel.t-online.de

[telekom1](reg_telekom)
outbound_auth=telekom1
endpoint=telekom1
contact_user=+493033445566
server_uri=sip:tel.t-online.de
client_uri=sip:+493033445566@tel.t-online.de

[telekom1]
type=auth
auth_type=userpass
password=secret
username=03033445566

I looked at 1TR114 from Telekom but, honestly, I’ve no idea what to look for.
Thanks & best

4

Try to capture all Telekom traffic on the WAN side (don’t know whether this is possible with a small Draytek device). I suspect that you are inviting against a server, where you are not registered. This implies that you have either a different configuration for the other lines, or that you will see the same problems with the other lines sooner or later.

Telekom ALL-IP is a bit special.

5

Thank you again for your feedback.
To the best of my knowledge, the Vigor 130 is not capable of capturing traffic. It can, however, log connections and I already analyzed these. Nothing about mismatching/wrong Telekom server IPs or anything related.
Since the other ISP accounts worked for many years now, I’m quite optimistic this will not change. Maybe I can get myself a provider that allows me to set external phone numbers. Then I could use their server and fax from my Telekom number. Not sure if this is allowed by regulations.

Although we are getting little off-topic here, let me comment on “Telekom ALL-IP is a bit special”.
I’m using Asterisk and Telekom as ISP since 2016. Until 2020 everything was fine, even calls from mobile got through without any problems. But the moment I got my (V)DSL100 upgrade, problems started. It took me months to get a Telekom technician to look into my case but he was not able to find the reason why some mobile ISP get through and others did not. Although other VoIP provider worked with my setup they claimed a misconfiguration at my end. Case closed. IMHO quite funny because even if I would try I have no idea how the Router could distinguish landline calls from mobile calls to block some of the latter. Draytek support was quite helpful but they were sure that the router is not the problem.
Best

6

I think there’s a German saying that basically says that you usually do not get cooties and fleas at the same time. If your descriptions are right, then you have even more than that. Your descriptions do not match typical problems.

DT can quickly check the physical parameters of your connection, provided your house connection is properly terminated. Then you need to look at the modem. As far a telephony is concerned the easiest would be to check whether a so-called Digi-Box (or Fritzbox) works. The rest would be a configuration problem on your side, but you do neither seem to have the tools nor the experience with Asterisk to bring light into your problems. It implies that you cannot expect a quick answer from here.

That said, DT has changed a couple of things since 2016 and some DNS related stuff changed I think in 2020.

7

Thank you again. You might be right that the underlying problems might go beyond Asterisk configuration. Unfortunately, I don’t have another modem to test but I hope to change to FTTH in a few months. Maybe my problems will be gone for good.

DT can quickly check the physical parameters of your connection

They probably did but were not happy to find out that I use a non-standard modem (Draytek). :wink: Actually, there was a hardware problem with the two copper cable. After VDSL100 was activated in 2020, DSL was very slow. A technician came here and found out that only one copper cable was attached. After that I got full speed.
And you are right that Deutsche Telekom changed from DNS to SRV/NAPTR. IIRC that change came after my VDSL upgrade. Nonetheless I followed some instruction to account for that change.

Funny I never came across the saying “man kann Flöhe und Läuse haben” in my life. I even asked some friends if they know it, but no. I could not find out if it’s more of a local saying or related to a profession, e.g. medical personnel.

Thanks again & best

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.