Color fax with AVM CAPIs
Harald Häger
I hope someone can help me out with this problem. Any ideas on this are
welcome. This seems to be a tricky problem and I have done a lot of testing
and tracing, so please forgive me if this message is so long; i just want
to explain my train of thoughts...
I have a question concerning color faxes (i.e. JBIG coded fax data as
specified for CAPI B3 protocol 5, T.30 extended Group3 fax; see bit 11 of
Options in the NCPI and B3config-struct for B3prot=5 in CAPI spec.). I'm
especially interested in BLOCKING these with my application since it should
only accept standard SFF data.
Newer versions of the AVM CAPI implementation (I'm using driver version
3.09.10 for Fritz!PCI, C2 & B1) offer this feature as does FRITZ!fax (at
least v3.02 does). The problem is, that when sending a fax with FRITZ!fax
to my app, FRITZ!fax thinks that my app accepts color faxes and sends one.
My first thought was that my app was broken, but as I traced with the debug
dlls from AVM I saw that my app (and FRITZ!fax) seem to behave correct.
On receiving the call with CONNECT_IND my app responds with CONNECT_RESP
and BProtocol set to: B1=4, B2=4, B3=4; the B3config is set to 0 except
StationID & Header, of course. This response should disable all extended
group3 mumbo-jumbo in the following handshaking procedure done by CAPI:
Here is what FRITZ!fax sends:
CONNECT_REQ ID=002 #0x0030 LEN=0072 00:48:44:51
Controller/PLCI/NCCI = 0x1
CIPValue = 0x4
[...snip...]
BProtocol
B1protocol = 0x4
B2protocol = 0x4
B3protocol = 0x5
B1configuration = default
B2configuration = default
B3configuration = <00 04 00 00 10>[snip]
[...snip...]
So FRITZ!fax says it wants to send a color fax (bit 11 is set), ok.
Now my app gets this:
CONNECT_IND ID=001 #0x002d LEN=0033 00:48:44:67
Controller/PLCI/NCCI = 0x201
CIPValue = 0x4
[snip]
And responds with:
CONNECT_RESP ID=001 #0x002d LEN=0062 00:48:44:68
Controller/PLCI/NCCI = 0x201
Reject = 0x0
BProtocol
B1protocol = 0x4
B2protocol = 0x4
B3protocol = 0x4
B1configuration = default
B2configuration = default
B3configuration = <00 00 00 00 10>[snip]
[snip]
My app says it only accepts a standard Group3 fax, no extensions, etc. (not
even high resolution - just for simplicity here)
after some handshaking, FRITZ!fax gets this:
CONNECT_B3_ACTIVE_IND ID=002 #0x0034 LEN=0038 00:48:51:66
Controller/PLCI/NCCI = 0x10101
NCPI = <40>8<00 64 00 00 00 00 10>[snip]
So this is strange! Although my app told CAPI that it wants to use the
standard Group3 fax protocol, FRITZ!fax gets signaled that the receiving
end can receive color faxes (again, bit 11 in Options is set). What puzzles
me furthermore, is that the Format word is still set to 0, indicating SFF
data. As I understand it from the CAPI spec. (4th ed.) the Options bits
only define the data format if the Format word is set to 8 (native). Is
that right? Does FRITZ!fax misinterprete this?
some more handshaking and my app gets this:
CONNECT_B3_ACTIVE_IND ID=001 #0x0036 LEN=0038 00:48:54:48
Controller/PLCI/NCCI = 0x20201
NCPI = <40>8<00 00 00 00 00 00 10 2b>49 2225
9149 91
and this:
DATA_B3_IND ID=001 #0x0037 LEN=0022 00:49:00:42
Controller/PLCI/NCCI = 0x20201
Data = <ff d8 ff e1 00 0c>G3FA
DataLength = 0x800
DataHandle = 0x0
Flags = 0x0
strange enough, altough FRITZ!fax sends a color fax (as you can see from
the first couple of bytes of the sent data), the Options bits are all set
to 0. When I change my app to set B3prot to 5 in CONNECT_RESP, the color
fax bit (bit 11) is also set in the CONNECT_B3-ACTIVE_IND for my app. But
again with the Format word set to 0 indicating a SFF.
Question is: who gets it wrong? FRITZ!fax? My app? Both? And how can I
signal in CONNECT_RESP that I don't want any color fax to be sent? I have a
strong feeling that the CAPI implementation (it's all the same on C2, B2
and FRITZ!PCI controllers, i tested them) from AVM thinks, because it is
capable of sending/receiving color faxes, it should set the color bit 11. I
otherwise don't have an explanation for this strange behaviour.
Has anyone experience with this, or has anyone suggestions? Maybe some
guys/girls from AVM around here? ;-)
Thanks in advance,
Harald Häger.
Victor Tabere
Why not to merely reject this connect request?
Reject = 1 (or another suitable value from the range 1..8)
Regards -
Victor Tabere
--
__________________________________________________________
News suchen, lesen, schreiben mit http://newsgroups.web.de
Harald Häger
Victor Tabere wrote:
> "Harald Häger" <h.ha...@gmx.de> wrote:
>
>
>
>>
>> [snip]
>>
>
>
> Why not to merely reject this connect request?
> Reject = 1 (or another suitable value from the range 1..8)
>
would be the easiest solution, yes. but, sadly, that's not the way this
thing should work. when you use FRITZ!fax to send a color fax to a
'real' analog fax, FRITZ!fax correctly falls back and instead sends a
standard b/w SFF. so it does with applications running on an older CAPI
not capable of color faxes. this is because FRITZ!fax - with the NCPI
parameter of the CONNECT_B3_ACTIVE_IND message - gets signaled that the
receiver on the other end is not capable of color faxes.
this is the way it should work and this is what handshaking is for: the
sender says what it can send. the receiver says what it can handle and
they both fall back to a common level. as is the case with the bitrate
used for the transfer. the slower machine dictates the bitrate.
once again: i'm suspecting, that the AVM capi implementation does the
handshake wrong, telling the sending end that it cand send a color fax.
only because the capi can handle it.
someone has other ideas? or - even better - can prove me wrong?
thank you for your quick reply, Victor.
cheers, Harald Häger.
Hans-Jürgen Ortmann
> > Why not to merely reject this connect request?
> > Reject = 1 (or another suitable value from the range 1..8)
>
> would be the easiest solution, yes. but, sadly, that's not the way this
> thing should work. when you use FRITZ!fax to send a color fax to a
> 'real' analog fax, FRITZ!fax correctly falls back and instead sends a
> standard b/w SFF. so it does with applications running on an older CAPI
> not capable of color faxes. this is because FRITZ!fax - with the NCPI
> parameter of the CONNECT_B3_ACTIVE_IND message - gets signaled that the
> receiver on the other end is not capable of color faxes.
>
> this is the way it should work and this is what handshaking is for: the
> sender says what it can send. the receiver says what it can handle and
> they both fall back to a common level. as is the case with the bitrate
> used for the transfer. the slower machine dictates the bitrate.
>
> once again: i'm suspecting, that the AVM capi implementation does the
> handshake wrong, telling the sending end that it cand send a color fax.
> only because the capi can handle it.
>
> someone has other ideas? or - even better - can prove me wrong?
Harald,
I can't prove you wrong, for you're right in your interpretation of this
situation.
All I can say: it's a bug in AVM's CAPI implementation :-(
The only thing you can do at moment is really to reject the fax at all.
HansJuergen
Harald Häger
Hans-Jürgen Ortmann wrote:
Hm. Too bad. I really hoped that I'd missed something. So I contacted
AVM's technical support. Let's see what comes out. I hoper their support
team is as good as i thought their drivers were, before I encountered
this problem ;-)
Thanks very much,
Harald Häger.