Re: [hylafax-users] CID REJECTED... Solution

[Campbell McKilligan <cowboycam@2die4.com>]

Ok.  I looked at the code to solve the problem.

The short answer is that CID functionality operates fine if the modem
answers directly after number presentation from the exchange.  So to
make it work, find out when CID is presented by the switch and set
ringsbeforeanswer to that number.  Here is Australia the CID is
presented with the second ring so I set ringsbeforeanswer=2 and it works
fine.

It's at this time (when CID is presented from the exchange) that the CID
information is logged by Hylafax.  If Hylafax answers at this point the
CID Number that was logged is also passed to the CID pattern matching,
the CID number compares fine and the call is answered.  (That's why the
CID information logged is always correct).

However the CID number is not kept if one or more subsequent rings occur
- or more to the point - a different instance of the CID number is
created (which is null) and this is used for the comparison - which
means that the only pattern that matches is a null regex.

This explains this behaviour for the following regex's in etc/cid (if
the call is answered on a subsequent ring):

^$	call is answered (ie a null string)
^.*$	call is answered (ie any string)
^.+$	call is rejected (ie any string not null)
^<---anthing here at all--->$	call is rejected

Also - the TSI and CID codes are virtually the same.  TSITEST works
correctly if you run "tsitest cid" to test your regular expression
writing ability.

Campbell.



Lee Howard wrote:
> 
> At 10:47 PM 4/16/01 +1000, Campbell McKilligan wrote:
> >
> >I applied the patch against bug #100 as Lee suggested.  The result was
> >that CID now half works.  (An improvement I think!?!)  With the
> >expression ^.*$ in the etc/cid file calls are accepted based on CID.  (I
> >terminated the call below during the handshake):
> 
> Now's the time when we really need a 'cidtest' utility!  But, based upon
> your success with the patch on Bug 100, I'd say that we can use 'tsitest'
> in its place.  The trick is to understand in what format that CID string is
> being seen by HylaFAX.
> 
> ^0298723980$ doesn't work, apparently, because "0298723980" is not the
> entirety of the CID string that is being reported from the modem and parsed
> by HylaFAX.  Why it's not showing up in the logs that way... I'm not sure.
> I don't have enough experience with CID in HylaFAX to know how the CID
> string is expected.
> 
> You're gonna have to try a bunch of things to see if it works.
> 
> I'd start with:
> 
> ^.*0298723980.*$
> if that goes, then try ^.*0298723980$ or ^0298723980.*$ to see where the
> issue is.
> and if that rejects, then do the long, tedious process of...
> ^.*0.*$
> ^.*02.*$
> ^.*029.*$
> and so on...
> 
> I've browsed the archives, but they're not very encouraging on this topic.
> If you find the problem, an explanation would be appreciated.
> 
> Lee.
> 
> ____________________ HylaFAX(tm) Users Mailing List _______________________
>  To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null


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