If retransmit_capable is not enabled then spandsp's behavior following receipt of RTN is to just move on to the next page. While this is not uncommon behavior for various fax senders (and admittedly even HylaFAX has this type of behavior as a non-default configurable option), I believe that it is incorrect behavior. If the system cannot retransmit the page following RTN (or also PIN) then the sender should send DCN and consider the transmission attempt as unsuccessful. As the current spandsp behavior without retransmit_capable being enabled essentially treats RTN identical to MCF this becomes confusing to users who get an indication of a successful transmission but where the pages transferred do not equal the total number of pages. This is especially confusing when the total number fo pages is only one... because the receiver very well may not have received/printed any page at all and be no wiser at all to the failed fax receipt - and yet spandsp on the sender's end is identifying the fax as successful (and so the sender may not know that there was an issue unless they are careful to compare the pages transferred to the total number of pages). This change here causes spandsp to identify the fax as unsuccessful if retransmit_capable is not enabled and RTN was received on the only page of a fax.

Author: redder86

src/t30.c

@@ -4718,6 +4718,7 @@ static void process_state_ii_q(t30_state_t *s, const uint8_t *msg, int len)
             }
             else
             {
+                t30_set_status(s, T30_ERR_RETRYDCN);
                 send_dcn(s);
             }
             /*endif*/