provided by Star2Billing S.L.

Call back CID works as normal when dial string comes in as shown.
Call back All works as normal when dial string come in as shown.

From: "8127392xxx" <sip:[email protected]>;tag=as1eda99b7

however Cid works as normal but All will not work as supposed to when presented with the following string.

From: <sip:[email protected]>;tag=944632087

notice the blank space above. The first CLI does not appear.

Without the first CLI it will not authenticate if the number is in the system and will always request a PIN.

2 different carriers 2 different formats it appears they are both the same
from the word <Sip on.

Where can we find the section to use the second CLI instead of the first in the program.

Yenod
[/b]

Having exact same problem here.
The Access calling card numbers and callback CID numbers works great when the inbound CID is received in Either of these formats listed blow.
From: "8127392121" <sip:[email protected]>;tag=as1eda99b7
From: <sip:[email protected]>;tag=944632087
The client is authenticated by their CID in either case and not asked for a pinnumber.

However just as Yenod stated, the callback all feature does not work the same and will not except both these formats. If the inbound CID string is not in the below format
From: "8127392121" <sip:[email protected]>;tag=as1eda99b7
It simply will not authenticate the caller by their CID and instead ask for a pin number.

Some companies send only inbound CID string as
"From: <sip:[email protected]>;tag=944632087"
with out listing the CID number twice in the same string as you see it in the above string in bold text.

Can anyone please tell me where to change the A2billing AGI so the callback ALL will work the SAME as the CALLBACK CID in how it gets the CID. The callback ALL feature should also be able to read both formats as the rest of a2billing is capable of doing.

It's difficult to be sure, but I'd be very surprised if we can fix this within A2B. It looks like Asterisk is failing to parse the caller's identity out of their SIP URI.
To gauge whether or not Asterisk is the problem you could try adding a little to the dialplan before A2B is launched. This should show you what Asterisk thinks the CLI was:

Thanks Stavros,

I come to find out I was mistaken. It wasn’t working the way I thought it was. Call_back_all always ask for a pinnumber after calling back regardless of the format of the incoming CID string.

The Question I have now, is this how it works? Shouldnt the call_back_all not ask for a pin number if it reconizes the caller?

For traveling the call_back_cid Is not what I or my clients need. The call_ back_all works fine other than that it doesnt authenticated by caller ID under any circumstance.

Any ideas on this.

Thanks Stavros,

I come to find out I was mistaken. It wasn’t working the way I thought it was. Call_back_all always ask for a pin number after calling back regardless of the format of the incoming CID string.

The Question I have now, is this how it works? Shouldn’t the call_back_all not ask for a pin number if it recognizes the caller?

For traveling the call_back_cid Is not what I or my clients need. The call_ back_all works fine other than that it doesn’t authenticated by caller ID under any circumstance.

Any ideas on this.

No, all-callback will never authenticate by CID; that's what cid-callback is for.

[cidcallback]
exten => _X.,1,MYSQL(Connect connid 209.40.000.000 a2billinguser dxxxx a2b)
exten => _X.,2,MYSQL(Query resultid ${connid} SELECT\ cc_callerid.cid\ FROM\ cc_callerid\ WHERE\ cc_callerid.cid = ${CALLERID(number)})
;exten => _X.,3,Noop(${resultid})
exten => _X.,3,MYSQL(Fetch fetchid ${resultid} callernumber)
exten => _X.,4,Noop(${callernumber})
exten => _X.,5,MYSQL(Clear ${resultid})
exten => _X.,6,MYSQL(Disconnect ${connid})
exten => _X.,7,GotoIf($[${CALLERID(number)} = ${callernumber}]?8:9)
exten => _X.,8,GoTo(custom-a2billing-cid-callback,${EXTEN},1)
exten => _X.,9,GoTo(custom-a2billing-all-callback,${EXTEN},1)
exten => _X.,10,Noop(${DIALEDPEERNUMBER})
exten => _X.,11,Hangup

Hi Stavros
I got the promblem fixed I was having. With the Dialplan above when caller calls in it will check the cc_callerid.cid and see if thier CID is in the cc_callerid.cid table and if its not they will be routed to the CallB_ACK_all EXT. But if found it will call them back and not prompt for a a pin.

SAM

This is interesting Sam. It appears that the need to do some sort of mixed CID/ALL callback can lead to an interesting additional mode in a2billing.