Re: [hylafax-users] CallID in 5.2.1

[bill.allison@xxxxxxxxx]

Lee

Reversed the patches and the effect is still there and I've tied it down   
to this - setting server tracing to any value that has this bit set   
triggers caller ID insertion in the tiff file to work.

8192 (0x02000) Config File Parsing

Attached are my config files in case the other part of the equation is   
something wrong in there, although they are the same ones I used ok with   
5.1.5

Thanks
Bill

 -----Original Message-----
From: Bill Allison
Sent: 06 February 2008 16:46
To: faxguy@xxxxxxxxxxxxxxxx
Cc: hylafax-users@xxxxxxxxxxx
Subject: RE: [hylafax-users] CallID in 5.2.1


Lee

Progress!

After applying your patch I had to bump up session tracing to get the   
per-page info from your patch to appear in the session log. Without   
thinking, I bumped up both server and session tracing and discovered that   
this resulted in the fault disappearing. Trial and error thereafter shows   
that it's increasing server tracing that triggers correct Caller ID   
insertion.

I'm doing further trial and error to discover which server tracing bit it   
is that is triggering/inhibiting correct operation. Meanwhile, attached   
are two session logs - one with tracing set to 3 (my normal setting) and   
one with it set to 65535 (a guessed max). I'll also take the patches off   
and see if upping server tracing still makes Caller ID work properly.

I'll get back to you soon.

Thanks
Bill

 -----Original Message-----
From: faxguy@xxxxxxxxxxxxxxxx
Sent: 06 February 2008 14:26
To: Bill Allison
Cc: hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] CallID in 5.2.1


    

 --------------------------------------------------------------------------  
 --
Bill,

Attached is a patch that basically adds two lines of debugging
information to the session logs.  Please apply the patch, rebuild and
reinstall.  Then take a look at subsequent session logs.  You should see
a single instance of something like this:

Feb 06 06:16:09.08: [18008]: TRAINING succeeded
Feb 06 06:16:09.08: [18008]: FaxRecv id: "9375350907
100
Lee's Office
<NONE>
400"
Feb 06 06:16:09.08: [18008]: <-- [9:AT+FTH=3\r]

And then you should see one instance of something like this per-page:

Feb 06 06:16:10.18: [18008]: --> [2:OK]
Feb 06 06:16:10.18: [18008]: RECV/CQ: id: "9375350907
100
Lee's Office
<NONE>
400"
Feb 06 06:16:10.18: [18008]: <-- [11:AT+FRM=146\r]

The first one tells us about the construction of the "id" fxStr that
gets subsequently passed around, and the second one tells us the state
of "id" just before the TIFFTAG_IMAGEDESCRIPTION gets set.

(The fields in TIFFTAG_IMAGEDESCRIPTION are delimited by newlines.)

Thanks,

Lee.


bill.allison@xxxxxxxxx wrote:
> Humor you? *Me* humor *you*? :-)
>
> Other way round I think!! I fully expect this to turn out to be down to   
    

> some silly action on my part...
>
> I've done all you asked below with no effect on the symptom. I've done   
    

> almost no C/C++ coding but I might, if I can steal a few minutes, try a   
    

> debug statement or two in faxd/FaxRecv.c while waiting for your
> timezone-delayed reply.
>
> Thanks
> Bill A.
>
>  -----Original Message-----
> From: faxguy@xxxxxxxxxxxxxxxx
> Sent: 05 February 2008 18:17
> To: Bill Allison
> Subject: Re: [hylafax-users] CallID in 5.2.1
>
>
>
>
>   
 -------------------------------------------------------------------------  
 -

>  --
> bill.allison@xxxxxxxxx wrote:
>
>
>> fileserver-e1:/usr/local/lib # l|grep fax
>> drwxr-xr-x    3 bin      bin          4096 Jan 29 16:39 fax/
>> lrwxrwxrwx    1 root     root           21 Feb  5 09:13
>> libfaxserver.so -> libfaxserver.so.5.1.5*
>> -rwxr-xr-x    1 root     root       452176 Oct  9  2006
>> libfaxserver.so.4.3.0.12*
>> -rwxr-xr-x    1 root     root       452032 Aug 24  2006
>> libfaxserver.so.4.3.0.8*
>> -rwxr-xr-x    1 root     root       452032 Aug 28  2006
>> libfaxserver.so.4.3.0.9*
>> -rwxr-xr-x    1 root     root       463440 Jan 29 16:33
>> libfaxserver.so.5.1.5*
>> -rwxr-xr-x    1 root     root       472264 Jan 29 16:39
>> libfaxserver.so.5.2.1*
>> lrwxrwxrwx    1 root     root           19 Feb  5 09:13 libfaxutil.so
>> -> libfaxutil.so.5.1.5*
>> -rwxr-xr-x    1 root     root       410352 Oct  9  2006
>> libfaxutil.so.4.3.0.12*
>> -rwxr-xr-x    1 root     root       410320 Aug 24  2006
>> libfaxutil.so.4.3.0.8*
>> -rwxr-xr-x    1 root     root       410320 Aug 28  2006
>> libfaxutil.so.4.3.0.9*
>> -rwxr-xr-x    1 root     root       413104 Jan 29 16:33
>> libfaxutil.so.5.1.5*
>> -rwxr-xr-x    1 root     root       417296 Jan 29 16:39
>> libfaxutil.so.5.2.1*
>> drwxr-xr-x    2 root     root         4096 Apr 14  2005   
mgetty+sendfax/
>>
>
>
> Humor me, please, and delete all of the libfaxserver and libfaxutil   
DSOs
> except for the libfaxutil.so.5.2.1 and libfaxserver.so.5.2.1.  Even the
> symlinks can go away.
>
> Also, unless you need it, please uninstall mgetty+sendfax.
>
> Then, if you will, please do a make distclean, ./configure, make, make
> install again.  Then try again.
>
> The Caller*ID is written to the tiff with this line of code in
> faxd/CopyQuality.c++:
>
> TIFFSetField(tif, TIFFTAG_IMAGEDESCRIPTION, (const char*) id);
>
> That code is being called from either faxd/Class1Recv.c++ or
> faxd/Class2Recv.c++ depending on whether you're using Class 1 or Class
> 2.  However, in either case there really should be no processing being
> done on "id" and the call really comes from faxd/FaxRecv.c++ in this
> code here where the "id" string is constructed...
>
> bool
> FaxServer::recvFaxPhaseD(TIFF* tif, FaxRecvInfo& info, u_int& ppm,
> fxStr& emsg)
> {
>     fxStr id = info.sender;
>     for (u_int i = 0; i < info.callid.size(); i++) {
>         if (modem->doCallIDRecord(i)) {
>             id.append('\n');
>             if (modem->getCallIDLabel(i).length()) {
>                 id.append(modem->getCallIDLabel(i));
>                 id.append('\t');
>             }
>             id.append(info.callid[i]);
>         }
>     }
>     do {
>         ++recvPages;
>         if (!modem->recvPage(tif, ppm, emsg, id))
>             return (false);
>
> However, from other information you've shown (namely the xferfaxlog
> entry and the initial CallID logging in the session log) it seems clear
> that the "id" string construction is going fine.  Which means that ...
> I'm confused ... everything seems to be invoked fine except for the
> TIFFSetField call.
>
> Thanks,
>
> Lee.
>
>  --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
>
>


 --
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



[[ configs.txt : 4353 in configs.txt ]]

Attachment: configs.txt
Description: Binary data