[ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue

[ganapathi]

Hi

As i recently noticed as CDR module is initialized for Wave channel and keep available on cdrbuild status

Code: [Select]

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 :

Code: [Select]

%%+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 :

Code: [Select]

%%+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.

Code: [Select]

Sniffed 'chan.locate' time=1530551429.087579
  thread=0x7f4f9c02a4e0 'YSIP Register'
  data=(nil)
  retval='(null)'
  param['id'] = ''

Kindly help me to avoid this issue.

[marian]

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?

[ganapathi]

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

[marian]

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.

[ganapathi]

This is my configuration, only once am executing call.execute.

It's for playback to caller for hangup reason.

regexroute.conf :

Code: [Select]

[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.

[ganapathi]

Is this would help to avoid re-executing to wave channel?

Code: [Select]

[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

[marian]

Yes

[ganapathi]

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

[marian]

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

[ganapathi]

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 .

[marian]

If you want to drop a call use the drop command:
drop sip/5951

[ganapathi]

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.

[marian]

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.

[ganapathi]

See this is my cdrcombine status , as per this status there are 3 active channel but there is no active channel at the moment.

Code: [Select]

%%+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 ?

[marian]

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.