Yate Community Forum
General Category => Yate users hangout place => Topic started by: ganapathi on July 02, 2018, 11:03:25 AM
-
Hi
As i recently noticed as CDR module is initialized for Wave channel and keep available on cdrbuild status
name=cdrbuild,type=cdr,format=Status|Caller|Called|BillId|Duration;cdrs=8,hungup=0;wave/90=unknown||||462416,
And some original channel created by call doesn't finalizing and it's keep available until service restart and finalized once service ended , due to that call end time shows inappropriately.
CDRBuild :
%%+status:cdrbuild
name=cdrbuild,type=cdr,format=Status|Caller|Called|BillId|Duration;cdrs=8,hungup=0;wave/90=unknown||||462416,sip/5951=answered|6027|7002|1530000462-5867|275148,sip/5952=answered|6027|7002|1530000462-5867|275148,sip/5956=answered|6034|6033|1530000462-5871|275135,sip/5957=answered|6034|6033|1530000462-5871|275135,wave/262=unknown||||191456,wave/267=unknown||||42145,wave/302=unknown||||27914
%%-status
CDRCombine :
%%+status:cdrcombine
name=cdrcombine,type=cdr,format=ChanId|Caller|Called|Address|OutLegs;cdrs=3;1530000462-5867=sip/5951|6027|7002|192.168.1.74:5060|1,1530000462-5871=sip/5956|6034|6033|192.168.1.93:5268|1,1530000462-6703=sip/6739|6033|6004|192.168.1.78:5629|1
%%-status
And yate keep throws chan.locate message with null value like mentioned below.
Sniffed 'chan.locate' time=1530551429.087579
thread=0x7f4f9c02a4e0 'YSIP Register'
data=(nil)
retval='(null)'
param['id'] = ''
Kindly help me to avoid this issue.
-
How did you managed to add a wave channel to cdrbuild?
Wave file module channels are not tracked.
They are not sending any chan.hangup message which would lead to cdr finalize.
Can you post a log with message sniffer enabled?
-
Even my question as well almost same , how wave channel are tracked on cdrbuild.
Find the log which emitted cdrbuild for wave channel
https://paste.linux.community/view/98b35ef1
-
You are re-executing a wave channel to a wave target!
See:
2018-07-03_10:06:49.763390 <RegexRoute:ALL> Dispatching new message 'call.execute' by rule #4 '${reason}^(35|offline|noconn|busy)$' in context 'chan.disconnected'
Sniffed 'call.execute' time=1530592609.763377
thread=0x13d77c0 'Engine Worker'
data=0x7f5bf40228c0
retval='(null)'^M
param['id'] = 'wave/5'
param['callto'] = 'wave/play//usr/local/share/yate/sounds/error/noconn.slin'
This is very wrong: you end up by connecting a wave chan to another one!
Pay attention to channel id when handling chan.disconnected.
Wave channels are utility channels: they are not supposed to be tracked by cdr build.
-
This is my configuration, only once am executing call.execute.
It's for playback to caller for hangup reason.
regexroute.conf :
[chan.disconnected]
${lastpeerid}^$=return
${lastpeerid}^\(wave\|tone\)/=return
;${reason}^\(35\)$^=return
${reason}^\(35\|offline\|noconn\|busy\)$=enqueue call.progress;targetid=${id};osip_Warning=399 $(nodename) "Subscriber ${reason}"
${reason}^\(35\|offline\|noconn\|busy\)$=dispatch call.execute;id=${id};callto=wave/play//usr/local/share/yate/sounds/error/${reason}.slin
Is there any mistake on above configuration.
-
Is this would help to avoid re-executing to wave channel?
[chan.disconnected]
${lastpeerid}^$=return
${lastpeerid}^\(wave\|tone\)/=return
${id}^(wave\|tone\)/=return
${reason}^\(35\|offline\|noconn\|busy\)$=enqueue call.progress;targetid=${id};osip_Warning=399 $(nodename) "Subscriber ${reason}"
${reason}^\(35\|offline\|noconn\|busy\)$=dispatch call.execute;id=${id};callto=wave/play//usr/local/share/yate/sounds/error/${reason}.slin
-
Yes
-
Ok. And about some original call doesn't finalize for longer period until restart the service.
%%+status:cdrcombine
name=cdrcombine,type=cdr,format=ChanId|Caller|Called|Address|OutLegs;cdrs=3;1530000462-5867=sip/5951|6027|7002|192.168.1.74:5060|1,1530000462-5871=sip/5956|6034|6033|192.168.1.93:5268|1,1530000462-6703=sip/6739|6033|6004|192.168.1.78:5629|1
%%-status
Log :
https://paste.linux.community/view/0eacac67
-
You can always inspect channel status by using the status command:
status sip/5951
This will show sip/5951 status including its peer id
As long as a channel is connected to another one it won't terminate
-
So in that case how to identify and emit the finalize cdr with Old channel/New Channel ?. Because i need to finalize & cdrcombine the cdr to update cdr table .
-
If you want to drop a call use the drop command:
drop sip/5951
-
But my problem is
- How to identify when channel is connected to another one.
- How to identify new channel originally hangup , so that i can hangup old channel as well or forcefully emit the cdr finalize
Is there any special emit message on these cases, so that i can drop old un-used channel. Because as i need to automate the hangup unused channel.
-
1. Each channel will send a chan.connected message when internally connected to a new peer channel.
2. What do you mean by 'unused' channel?
You should not need to automate hangup: I suppose the user (human) calling/called party will hangup.
Non utility channels will send a chan.hangup when hung up by remote party. This applies for call legs from external protocols (sip ...).
Maybe you should describe what are you trying to achieve.
-
See this is my cdrcombine status , as per this status there are 3 active channel but there is no active channel at the moment.
%%+status:cdrcombine
name=cdrcombine,type=cdr,format=ChanId|Caller|Called|Address|OutLegs;cdrs=3;1530000462-5867=sip/5951|6027|7002|192.168.1.74:5060|1,1530000462-5871=sip/5956|6034|6033|192.168.1.93:5268|1,1530000462-6703=sip/6739|6033|6004|192.168.1.78:5629|1
%%-status
For ex : sip/5951 is shows as active but channel/call closed days before. there is no chan.hangup for this channel. As per your previous reply i thought if channel connected to another channel then it won't terminate, so in that case how to identify the original status of those non-terminated channel to terminate forcefully.
Simply expecting there is no mismatch on channel/cdr status.
As i hope you understand my issue now ?
-
If you ever made an utility channel sending a call.cdr this may affect cdr combiner: the utility channel will never send a chan.hangup wich would finalize its cdr.
The result will be the entry in cdrcombiner will remain forever: remember that cdr combiner will keep a record as long as at least one leg is not finalized.
-
Ok then i guess because of my wave channel and configuration mismatch which was mentioned on this previous replies on this thread may cause this issue and these sip channel is not finalized. Let me observe it current status then would come back if any doubt on this.
-
Hi
As i seen that some calls are not finalized properly. Mainly when made a transfer the current call to another local user. Please find the status and logs attached here.
name=cdrcombine,type=cdr,format=ChanId|Caller|Called|Address|OutLegs;cdrs=1;1530798280-611=sip/665|6033|6032|192.168.1.78:5629|1
-
You are internally connect 2 call legs with different billing id.
cdrcombine does its job based on billid parameter.
cdrcombine is not designed to track channels with different billid.
This would require a custom logic.
You may store individual CDRs into database and run whatever logic you need for billing.
Keep in mind you must make a decision for the following:
A calls B: billid1
C calls D: billid2
You connect C with B !
You must run a complex logic to look at call time, answer time, duration, channel id ...
Bottom line:
- cdrcombine does not replace a charging application
- For custom logic you may need to build your own cdr combiner
-
Hi
No My question is to clear cdrcombine entry where it's still not cleared when call legs are cleared.
A(sig/1) calls B(sip/1) : billid 1
then
B(sip/1) calls C ( sip/2) : billid 2
In here cdrcombine is does the job for billid 1. But sometime is not doing for billid2. Where sip/1 & sip/2& sig/1 channels are disconnected but cdrcombine is not performed for billid2 and i think incoming finalize also not performed here.
Logic : It's Just conference call ( A -> B then B calls C with A on another line ).
Please help me to understand and solve this.
-
There is an issue with billid: outgoing channel may change its billid when incoming channel is forked and outgoing channel is connected to another channel before being connected to initial channel.
This will be fixed (I can't say when).
Meanwhile just stop using cdrcombine.
You may implement some logic to track all channels and their billid.
You may send a call.cdr with operation=finalize when necessary.
Keep in mind that this may affect cdr storage!
-
Sorry. Still i couldn't understand the issue, even i tried to read the log , didn't get any clue until.
Anyway you says it's known issue,let me wait for the issue to be solve.
And am more into cdrcombine as of now. Let me modify my logic with cdrbuild itself until it's get resolved.