[Home]

Summary:ASTERISK-10082: Sending caller ID to ZAP Extension fails if sendcalleridafter=0 or sendcalleridafter=1
Reporter:Robert Jenkins (rjenkins)Labels:
Date Opened:2007-08-14 15:20:25Date Closed:2011-06-07 14:07:48
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:UK Caller ID setup is (or shoudl be):
cidsignalling=v23
cidstart=polarity
sendcalleridafter=0

This setup always fails to properly send the caller ID; logged error is:
WARNING[14416] chan_zap.c: Didn't finish Caller-ID spill. Cancelling.

(It still fails with sendcalleridafter=1, it must be 2 to avoid an error.)

Ideally, with this setup the first actual ring should be deferred until a short time after the cidspill has been completed (or the cidspill data should include a 200mS silence at the end, allowing ring to follow immediately).

The UK (British Telecom) standard timing sequence is:
Polarity reversal,
300mS delay (which may include other signalling),
V23 caller ID data burst, starting with 45 - 75mS MARK tone,
Minimum 200mS silence from end of data burst to start if ringing voltage.

[The idea is that caller ID can be received and processed before ring voltage arrives, so unwanted calls can be muted without any ringing]

The formal timing diagram is on page 8 of the BT document here:
http://www1.btwebworld.com/sinet/242v2p3.pdf


****** ADDITIONAL INFORMATION ******

ast->rings is incremented before checking if it's greater than cidrings,so with cidrings=0 it will always fail...

Existing code, in chan_zap.c around line 4134:
case ZT_EVENT_RINGEROFF:
if (p->inalarm) break;
if ((p->radio || (p->oprmode < 0))) break;
ast->rings++;
if ((ast->rings > p->cidrings) && (p->cidspill)) {
ast_log(LOG_WARNING, "Didn't finish Caller-ID spill.  Cancelling.\n");
free(p->cidspill);
p->cidspill = NULL;
p->callwaitcas = 0;
}
p->subs[index].f.frametype = AST_FRAME_CONTROL;
p->subs[index].f.subclass = AST_CONTROL_RINGING;
break;

Typical log result, call cancelled during first audible ring, about 1 second in. I don't know why there are THREE 'is ringing' notifications within that time, but I suspect that's why it also fails at 1:

[Aug 14 21:06:06] VERBOSE[16822] logger.c: -- Executing [s@macro-dial:10] Dial("SIP/200-082221c8", "ZAP/1||tr") in new stack
[Aug 14 21:06:06] VERBOSE[16822] logger.c: -- Called 1
[Aug 14 21:06:06] VERBOSE[16822] logger.c: -- Zap/1-1 is ringing
[Aug 14 21:06:06] VERBOSE[16706] logger.c: Extension Changed 201 new state Ringing for Notify User 200
[Aug 14 21:06:07] WARNING[16822] chan_zap.c: Didn't finish Caller-ID spill. Cancelling.
[Aug 14 21:06:07] VERBOSE[16822] logger.c: -- Zap/1-1 is ringing
[Aug 14 21:06:07] VERBOSE[16822] logger.c: -- Zap/1-1 is ringing
[Aug 14 21:06:09] VERBOSE[16822] logger.c: -- Hungup 'Zap/1-1'
Comments:By: Robert Jenkins (rjenkins) 2007-08-14 15:26:55

Category should be channels/chan_zap
By: Tilghman Lesher (tilghman) 2007-11-06 19:18:09.000-0600

I wonder if you might be able to get this simply by changing the ring parameter for indications.conf to start with "!0/500".  That should give you sufficient time for the callerid spill, and the initial "!" means that it won't repeat.
By: Michiel van Baak (mvanbaak) 2008-02-11 13:11:33.000-0600

Can you give Corydon's hint a try and report back on the bugtracker please.
By: () 2008-02-17 13:12:06.000-0600

any further comments or news ? Or can we close ?
By: Joshua C. Colp (jcolp) 2008-02-20 14:39:31.000-0600

Suspended due to lack of response per Corydon's suggestion.