[hylafax-devel] Re: Getting Fax over the GSM network

[Dr. Harald Pollack <Harald.Pollack@Datanews.at>]

On 09 Apr 2000 19:57:56 +0400, Dmitry Bely wrote:


Hello Dmitry!

>What do you think of this?

Very interesting.

>Is it true that T4 should stop on receiving first flag

Your question is not quite correct :-)

T4 is the timeout counter for the 'Response Received?' subroutine while hunting for the first 
hdlc flag.

This means, that after sending AT+FRH=3 the internal T4 timer should be started. If NO 'CONNECT' 
response is received from modem when T4 times out, AT+FRH=3 state must be canceled (depending on 
modem, either by a single character or by 'AT' command).

But keep in mind, T4 timer is ONLY USED for 'Response Received?' and NOT for 'Command Received?' 
subroutine!!!!!!!!!

So class 1 fax program must well distinguish between these two subroutines!!!!

>(not the address field, as it's currently done by Hylafax)?

If fax program CAN read address field, than the whole frame WAS already received complete and 
without error. In this case, T4 is really senseless :-)

>T.30 is not quite clear on this subject.

:-) T.30 is no receipt, it is a standard :-) This normally means, that somebody understands it, 
as soon as he has successfully implemented it :-) T.30 is far away from being a 'guideline' or 
sample code!

>Also does Class 1 differ significantly from Class 1.0? (unfortunately I have only the second 
standard).

The differences are marginal (or even none). Class 1.0 defines some new AT commands, which could 
make live easier, but there are some modems on the market, which claim to be Class 1.0 compliant, 
but have not implemented the class 1.0 special commands and responses!!!

>BTW, I have rewrited your NSF parsing code -- it searches station ID
>position itself, not knowing the exact place.

Oh! How do you realize this, if it is empty ? :-)

>Also a couple of vendor entries has been added. Are you interested in?

I am VERY interesed in! :-)

Here is a shore overview about my potential thinking about this:

############################
>Hello,

>I am involved in a Fax Class 1 implementation developpment over the GSM
>network.

>The configuration is as follows :

>- a linux PC with hylax4.1beta2 connected to a mobile phone with a
>serial line,
>- the hylafax software is in charge of the Fax Class 2 protocol (T.30
>recommendation),
>- the DCE is a mobile phone in charge of the Fax Class 1 protocol over
>the GSM network (3.45 recommendation),
>- the communication between these two entities is performed by the way
>of AT commands (T.31 recommendation).

This means in fact, that Hylafax USES the class 1/1.0 command/response set ?

>So, hylafax sends the CSI hdlc frame (23 bytes) and then the DIS hdlc
>frame (10 bytes) to the mobile phone for network emission.

The length of DIS frame is variable in length, depending on the capabilities of recieving 
station!

>The mobile phone returns back CONNECT after the CSI emission and OK
>after the DIS emission (as required by the T.31 recommendation).

Correct. response CONNECT means, that a 'non-final' frame was delivered (and modem continues to 
send hdlc flags). Response OK means, that modem has recognized a 'final' frame (from DTE) and has 
STOPPED delivering hdlc flags and has also stopped V.21 transmission. Modem is now in command 
state again! 

>The hylafax application then sends an AT+FRH command so as to get the
>TSI frame and DCS frame response (25 bytes length and 9 bytes length
>respectively).

Not quite correct :-) depending on modem manufacturer, TSI frame can include FCS (25 bytes) or 
not (23 bytes) and DCS frame length depends from capabilities of sender also (can include a lot 
of 'empty' bits).

>The time delay between the reception of the AT+FRH command and the
>CONNECT response is 1.5 second

This is also a very incorrect statement :-)

In the case of waiting for commands (from sender), there is NO special timing for receiving of 
first hdlc flag (in T.30 subroutine 'Command received?'). It is a very good approach, to wait not 
longer than 2 seconds, but in reality, this time can be longer. As a consequence, time between 
the AT+FRH=3 command (from DTE) and the response CONNECT (from DCE) can also be less than a 
second or (much) more.

>(the T.31 recommendation specifies that
>this response is returned by the DCE when receiving flags from the
>network).

Correct, and according to T.30, there is no time specified, how long to wait. There is only an 
overall timeout IF a hdlc flag was received (T2). There is also a further clause, that 
transmitting station repeats (twice) a command, if no valid response was received within 3 +/- 
15% seconds.

>The whole TSI frame reception, including the preamble flags, takes 1.71
second.

Duration of hdlc frames can easily be counted by the transmission speed (300 bps) and the 
potential content of the frames. Keep in mind, that optional frames (NSF) can also be 
transmitted!

>So , the whole delay between the AT+FRH command reception and the
>sending back of the TSI frame received is 3.21 seconds

Like live, fax is also not so simple :-) DO NOT ASSUME ANY TIME BEHAVIOUR !!! Read carefully T.30 
5.4.2 (Line control procedures and error recovery) and try in practice how different manufacterer 
have implemented this! So I can only repeat: ASSUME NOTHING :-)

>while the hylafax
>application is only waiting for 3.1 seconds.

Maybe you mean the time of repeating commands ?

>The question I am wondering is about this hylafax timer of 3.1 seconds.

Your 'wondering' is quite correct :-)

>It starts when emitting the AT+FRH command and stops when receiving the
>first byte of the TSI HDLC frame (0xFF), while the T.30 recommendation
>specifies a T4 timer starting at the command emission and stopping when
>receiving flags (another timer of 3 seconds has then to be started for
>thewhole frame reception).

T4 is started AFTER 'command emission' (therefore at the beginning of subroutine 'Response 
received?') and is - in my opinion - only a 'flag hunting timeout').

Class 1/1.0 response reception and T.30 subroutine 'Response received?' are not fully 
compareable! While the T.30 descibbes a SINGLE subroutine/process, to receive ALL (incl. 
optional) frames, class 1/1.0 does this step by step for each single frame, till 'final-bit' is 
recognized (which is signaled by DCE with the OK response). The mentioned 'timer of 3 seconds' is 
an inprocess timer for a SINGLE frame and applicable to the reception of one frame in class 1/1.0

>Due to the kind of communication we have on the serial line (by the way
>of the T.31 recommendation), the mobile phone does not return the
>received flags but the CONNECT response instead.

YOu can assume :-) that the CONNECT response MARKS the first flag (which is not quite correct, 
because it SHOULD be the recognition of the V.21 carrier, but in case of GSM it is in fact the 
first flag :-)

>So, is the 3.1 second timer really conformant to the T.30 recommendation
>or would it be better conformant if it stopped when receiving the
>CONNECT response instead of stopping when receiving the first effective
>byte of the HDLC frame (0xFF byte) ?

It is correct, to stop this timer after reception of CONNECT, but you must immediatly start the 
'timer of 3 seconds' as a timeout for the reception (from modem) of the real frame data. It is 
possible, to get CONNECT from modem, but no more single byte in case of FCS error. So this 'timer 
of 3 seconds' is vital.


>I would be grateful for your answer.

Here it is :-)

Mit herzlichen Gruessen / Yours sincerely

Dr. Harald Pollack

Harald.Pollack@DATAnews.at



____________________ HylaFAX(tm) Developers Mailing List ____________________
 To unsub: mail -s unsubscribe hylafax-devel-request@hylafax.org < /dev/null