Re: [hylafax-users] Update on Problem with Distinctive Ring-- hacked faxgetty

["Sunil William Savkar" <savkar@inthespace.com>]

Patrice--

I agree that looking at the code, there is just something weird since with
the fix, I should no longer get CID = "RING A".

I recompiled with a hard coding of the extended ring to be "RING;" (i.e.
instead of changing all the code to add an option I simply changed the
string compare).

However, that didn't change anything, even with the fix to the "if" clause
(i.e. calling parseCID within the clause itself).

This just doesn't make sense and I must be doing SOMETHING wrong now.  I
restarted faxgetty but still the same behavior... Let me do some more
testing (probably something completely stupid) and I will give you more
feedback.

Thanks in advance.

Sunil

> Quoting Sunil William Savkar <savkar@inthespace.com>:
>
>> Patrice's explanation + fix has not solved the problem.  As I was
>> suspecting looking at his indication and looking at my symptoms, they
>> are not one in the same thing.  I added the patch, rebuilt, etc., but
>> even looking at the patch, it was obvious it was not targeting my
>> issue.
>
> Really?
>
> Before the patch, a call would be answered after receiving a number of
> rings which can appear as either:
>
> - What is specified by RingData
> - What is specified by RingFax
> - What is specified by RingVoice
> - "RING " followed by anything. The line would then be put in CID.
> (that's
>
> the extended ring)
> - "RING"
>
> Why are "RING A" ring type answered? As RingData and RingVoice are
> empty,  we can forget about them. The RingFax is set to "RING B" so it's
> not that  either. Neither is "RING". Starting with "RING "? YES. And to
> even prove  it's the one used, you get the RING line in CID.
>
> The patch on bug 346 lets us specify what is to be considered for that
> Extended ring (a ring with CID information) by setting RingExtended to
> whatever we want. It defaults to "RING " for backward compatibility and
> accepts things after the string (of course, there's suppose to be CID
> information at the end of the string). So setting RingExtended to
> anything
>
> you want which would never occur would disable it.
>
>> The fact that CID was being set with Ring data told me that there is
>> somewhat of a bug in parsing the incoming modem data stream. That
>> somehow even though I did not have CID set on for my modem, hylafax
>> was still parsing the first string as CID information.
>
> It's not a bug, anything starting by "RING " (and this is) is considered
>  as a RING with CID information. (there are modems that give CID as a
> one  line ring like "RING CID=5551212". That's what HylaFAX is thinking
> it  receives)
>
> Look at ClassModem.c++ at lines arround 1199.
>
> Now if you did try the patch and set RingExtended: "RING;" in your
> config.ttyXX and it didn't work, give some information. Was there any
> difference? Do you still get the CID info in the log files? (you did
> restart faxgetty, right?)
>
> --
> Patrice Fournier
> pfournier@loups.net
>
> ____________________ HylaFAX(tm) Users Mailing List
> _______________________
>   To subscribe/unsubscribe, click
> http://lists.hylafax.org/cgi-bin/lsg2.cgi
>  On UNIX: mail -s unsubscribe hylafax-users-request@hylafax.org <
> /dev/null
>   *To learn about commercial HylaFAX(tm) support, mail
> sales@hylafax.org.*




____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@hylafax.org.*