Re: [hylafax-users] Update on Problem with Distinctive Ring (346 patch does not fix CID issue)

[Patrice Fournier <pfournier@loups.net>]

Quoting Sunil William Savkar <savkar@inthespace.com>:

> It also does not fix the "mystified" situation I had with CID.  I
> demystified it by staring at the code.
> 
> Since RING A does not match to anything else in the if-then-else clause
> because of the separate bug with matches between the distinctive ring
> string and the buffer, it defaults to calling parseCID at the end (from
> ModemConfig.c++).  The parseCID script performs a stringcompare between

Right, the parseCID line should be in the if block as such:

    else {
        if (strneq(rbuf, conf.ringExtended,
          conf.ringExtended.length())) {        // extended RING
            n--;
            conf.parseCID(rbuf, cinfo);
        }
        break;

or to stay consistent, we could also rewrite it as such:

    else if (strneq(rbuf, conf.ringExtended,
      conf.ringExtended.length()))        // extended RING
        conf.parseCID(rbuf, cinfo);
    else
        break;


> Thus CIDName and CIDNumber are thus both incorrectly set to RING A
> instead. 

Right.

> Mystery solved, bug still there with patch 346 which does not touch the
> parseCID routine.  Have not tried to fix yet but may be as simple as
> switching the two arguments to the strnequ() macro.

CID would still be parsed, but the RING should not get counted and 
answered though. Are you saying that faxgetty still answer the phone after 
the patch from bug 346 and the RingExtended configuration option was 
added?

-- 
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.*