There is difference in CDR when I am calling from SIP to SIP and SIP to Mobile number. I use same dial plan and just modify technology/number field in dial application. for example-
using SIP:
exten => _XXXXXXXXXXX,1,Dial(SIP/test,5,g,H,h)
Using dahdi:
exten => _XXXXXXXXXXX,1,Dial(dahdi/g0/${EXTEN:},5,g,H,h)
I am getting separate result for call duration, billsec and disposition. When I call through dahdi disposition is always answered.
Please assist me to get the correct CDR.
Assuming the mobile number is a red herring and the dahdi channel is analogue.
What answer supervision does your PSTN operator provide? If none, there is no easy solution. (If you are using a domestic service, don’t expect the customer support person to know what you are talking about. For BT in the UK, this is detailed in BT SIN 351, for single analogue lines; maybe your operator has a similar document. I think that BT SIN 352 is the equivalent for lines intended for PABX use.)
What answer supervision option do you have configured in chan_dahdi.conf? (Look for options beginning with answer!) Are they compatible with the answer to the previous question?
I have tested it by changing settings of chan_dahdi.conf.
[trunkgroups]
[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
signalling=fxs_ks
group=1
callgroup=1
pickupgroup=1
immediate=no
callerid=asreceived
cidsignalling=dtmf
cidstart=polarity
answeronpolarityswitch=yes
useincomingcalleridondahditransfer = yes
hanguponpolarityswitch=yes
busydetect=yes
busycount=3
;callprogress=yes
sendcalleridafter=2
;Sangoma AFT-A200 [slot:2 bus:1 span:1]
context=from-internal
group=1
echocancel=yes
signalling = fxo_ks
channel => 1
context=from-internal
group=1
echocancel=yes
signalling = fxo_ks
channel => 2
context=from-zaptel
group=0
callerid=asreceived
echocancel=yes
signalling = fxs_ks
channel => 3
context=from-zaptel
callerid=asreceived
group=0
echocancel=yes
signalling = fxs_ks
channel => 4
If callprogress=yes disposition is still answered otherwise busy(billsec=0).
Console output is :
testCLI>
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– Executing [0XXXXXXXXXX@from-internal:1] ResetCDR(“SIP/101-00000007”, “”) in new stack
– Executing [0XXXXXXXXXX@from-internal:2] Dial(“SIP/101-00000007”, “dahdi/g0/0XXXXXXXXXX,30000,gtTCcHh”) in new stack
– Called dahdi/g0/0XXXXXXXXXX
– DAHDI/3-1 is busy
– Hanging up on ‘DAHDI/3-1’
– Hungup ‘DAHDI/3-1’
== Everyone is busy/congested at this time (1:1/0/0)
– Executing [0XXXXXXXXXX@from-internal:3] Verbose(“SIP/101-00000007”, “Dial Status : BUSY”) in new stack
Dial Status : BUSY
– Executing [0XXXXXXXXXX@from-internal:4] Goto(“SIP/101-00000007”, “s-BUSY,1”) in new stack
– Goto (from-internal,s-BUSY,1)
– Executing [s-BUSY@from-internal:1] NoOp(“SIP/101-00000007”, “busy”) in new stack
– Executing [s-BUSY@from-internal:2] Hangup(“SIP/101-00000007”, “”) in new stack
== Spawn extension (from-internal, s-BUSY, 2) exited non-zero on ‘SIP/101-00000007’
– Executing [h@from-internal:1] Verbose(“SIP/101-00000007”, “”) in new stack
– Executing [h@from-internal:2] Verbose(“SIP/101-00000007”, “”) in new stack
– Executing [h@from-internal:3] Hangup(“SIP/101-00000007”, “”) in new stack
== Spawn extension (from-internal, h, 3) exited non-zero on 'SIP/101-00000007’
testCLI>
and debug log
[Sep 14 14:13:43] DEBUG[14361] sig_analog.c: analog_exception 3
[Sep 14 14:13:43] DEBUG[14361] sig_analog.c: Exception on 21, channel 3
[Sep 14 14:13:43] DEBUG[14361] sig_analog.c: __analog_handle_event 3
[Sep 14 14:13:43] DEBUG[14361] sig_analog.c: Got event ANALOG_EVENT_HOOKCOMPLETE(9) on channel 3 (index 0)
[Sep 14 14:13:43] DEBUG[14361] chan_dahdi.c: Channel 3: Sending ‘T0XXXXXXXXXXw’ to DAHDI_DIAL.
[Sep 14 14:13:43] DEBUG[14361] sig_analog.c: Sent deferred digit string on channel 3: T0XXXXXXXXXXw
[Sep 14 14:13:46] DEBUG[14311] manager.c: Running action ‘Command’
[Sep 14 14:13:46] DEBUG[14311] manager.c: Running action ‘Command’
[Sep 14 14:13:46] DEBUG[14311] manager.c: Running action ‘Command’
[Sep 14 14:13:46] DEBUG[14311] manager.c: Running action ‘MailboxStatus’
[Sep 14 14:13:46] DEBUG[14361] sig_analog.c: analog_exception 3
[Sep 14 14:13:46] DEBUG[14361] sig_analog.c: Exception on 21, channel 3
[Sep 14 14:13:46] DEBUG[14361] sig_analog.c: __analog_handle_event 3
[Sep 14 14:13:46] DEBUG[14361] sig_analog.c: Got event ANALOG_EVENT_DIALCOMPLETE(6) on channel 3 (index 0)
[Sep 14 14:13:46] DEBUG[14361] chan_dahdi.c: Enabled echo cancellation on channel 3
[Sep 14 14:13:46] DEBUG[14361] res_rtp_asterisk.c: Setting the marker bit due to a source update
[Sep 14 14:13:46] DEBUG[14361] res_rtp_asterisk.c: Ooh, format changed from unknown to ulaw
[Sep 14 14:13:46] DEBUG[14361] res_rtp_asterisk.c: Created smoother: format: ulaw ms: 20 len: 160
[Sep 14 14:13:46] DEBUG[14361] res_rtp_asterisk.c: Starting RTCP transmission on RTP instance ‘0x8e6d6d0’
[Sep 14 14:13:46] DEBUG[14361] res_rtp_asterisk.c: Setting the marker bit due to a source update
[Sep 14 14:13:46] DEBUG[14311] manager.c: Running action ‘MailboxCount’
[Sep 14 14:13:46] DEBUG[14361] res_rtp_asterisk.c: Setting the marker bit due to a source update
[Sep 14 14:13:46] DEBUG[14361] res_rtp_asterisk.c: Setting the marker bit due to a source update
.
.
.
.
[Sep 14 11:50:37] DEBUG[13043] dsp.c: Requesting Hangup because the busy tone was detected on channel DAHDI/3-1
[Sep 14 11:50:37] DEBUG[13043] channel.c: Hanging up channel ‘DAHDI/3-1’
[Sep 14 11:50:37] DEBUG[13043] chan_dahdi.c: dahdi_hangup(DAHDI/3-1)
[Sep 14 11:50:37] DEBUG[13043] sig_analog.c: analog_hangup 3
[Sep 14 11:50:37] DEBUG[13043] sig_analog.c: Hangup: channel: 3 index = 0, normal = 1, callwait = 0, thirdcall = 0
[Sep 14 11:50:37] DEBUG[13043] chan_dahdi.c: Disabled echo cancellation on channel 3
[Sep 14 11:50:37] DEBUG[13043] chan_dahdi.c: Set option TONE VERIFY, mode: OFF(0) on DAHDI/3-1
[Sep 14 11:50:37] DEBUG[13043] chan_dahdi.c: Set option TDD MODE, value: OFF(0) on DAHDI/3-1
[Sep 14 11:50:37] DEBUG[13043] sig_analog.c: Updated conferencing on 3, with 0 conference users
[Sep 14 11:50:37] DEBUG[13043] app_dial.c: Exiting with DIALSTATUS=BUSY.
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Result of ‘DIALSTATUS’ is ‘BUSY’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Launching ‘Verbose’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Result of ‘DIALSTATUS’ is ‘BUSY’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Launching ‘Goto’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Launching ‘NoOp’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Launching ‘Hangup’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Spawn extension (from-internal,s-BUSY,2) exited non-zero on ‘SIP/101-00000000’
[Sep 14 11:50:37] DEBUG[13043] channel.c: Soft-Hanging up channel ‘SIP/101-00000000’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Function result is ‘(null)’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Launching ‘Verbose’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Function result is ‘(null)’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Launching ‘Verbose’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Launching ‘Hangup’
[Sep 14 11:50:37] DEBUG[13043] pbx.c: Spawn extension (from-internal,h,3) exited non-zero on ‘SIP/101-00000000’
[Sep 14 11:50:37] DEBUG[13043] channel.c: Hanging up channel ‘SIP/101-00000000’
[Sep 14 11:50:37] DEBUG[13043] chan_sip.c: Hanging up zombie call. Be scared.
[Sep 14 11:50:37] DEBUG[13043] chan_sip.c: Updating call counter for incoming call
[Sep 14 11:50:37] DEBUG[13043] chan_sip.c: Hanging up channel in state Ring (not UP)
[Sep 14 11:50:37] DEBUG[13043] res_rtp_asterisk.c: Setting RTCP address on RTP instance ‘0x9557688’
[Sep 14 11:50:37] DEBUG[13043] chan_sip.c: AST hangup cause 16 (no match found in SIP)
[Sep 14 11:50:37] DEBUG[13043] chan_sip.c: Trying to put ‘SIP/2.0 603’ onto UDP socket destined for 192.168.5.15:46825
[Sep 14 11:50:37] DEBUG[13035] manager.c: Examining event:
please check analog exception 3 and AST hangup cause 16 (no match found in SIP) lines. Is this normal output?
I faced one more issue during testing when cidstart=polarity_IN incomming calls stop working.
Looks like you need to contact Sangoma. (Digium would provide support for this sort of problem, on their commercial support channels, if you were using genuine current Digium products.)
Cause 16 is normal clearing.
The analogue exception is a debug report, so not necessarily siginficant, but one would need to look at the code to find out exactly what it means.
Specifying answer on polarity assumes the network provides that service. If it doesn’t, there is probably no way of detecting answer, so Asterisk will need to assume the call is answered immediately.
I have contacted sangoma. Its support staff suggested to contact asterisk community.
That either means their hardware isn’t supported on Asterisk, or that you confused them by referring to CDRs, when the actual problem looks like a failure to detect answer supervision from the network.
My guess is that the network doesn’t provide answer supervision, so your requirement is not achievable. Often people use heuristics in the logging software to work out ring time in the absence of answer supevision.