76
YateBTS / Re: Yate will not start
« on: July 27, 2018, 01:27:57 AM »
Hi,
Try to run as root.
Try to run as root.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
77
Windows / Re: YATE client with Cisco Expressway
« on: July 12, 2018, 12:30:23 AM »
The failed message may appear due to some race in audio channel open.
In order to provide a proper answer I would need a log with message sniffer enabled.
Please check docs.yate.ro on how to start yate (YateClient also) with logging, increase debug, enable message sniffer.
In order to provide a proper answer I would need a log with message sniffer enabled.
Please check docs.yate.ro on how to start yate (YateClient also) with logging, increase debug, enable message sniffer.
78
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 11, 2018, 12:39:07 AM »
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!
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!
79
Features requests / Re: SIP UPDATE support
« on: July 09, 2018, 08:10:38 AM »
1xx messages are provisional, not final.
For custom methods (added in methods section, not handled internally) you must handle a sip.method_name message.
For your need you must handle the sip.update message and return true.
A simple regexroute would be:
[extra]
sip.update=50
[sip.update]
.*=return true
For custom methods (added in methods section, not handled internally) you must handle a sip.method_name message.
For your need you must handle the sip.update message and return true.
A simple regexroute would be:
[extra]
sip.update=50
[sip.update]
.*=return true
80
Features requests / Re: SIP UPDATE support
« on: July 09, 2018, 01:40:40 AM »
ysipchan.conf
[methods]
update=BOOLEAN
The value of parameter is a boolean (yes/no) indicating auth is required (this is the default) or not
[methods]
update=BOOLEAN
The value of parameter is a boolean (yes/no) indicating auth is required (this is the default) or not
81
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 09, 2018, 01:36:17 AM »
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
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
82
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 04, 2018, 07:18:40 AM »
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.
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.
83
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 04, 2018, 12:53:44 AM »
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.
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.
84
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 03, 2018, 08:10:59 AM »
If you want to drop a call use the drop command:
drop sip/5951
drop sip/5951
85
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 03, 2018, 07:53:04 AM »
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
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
86
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 03, 2018, 06:26:34 AM »
Yes
87
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 03, 2018, 05:47:27 AM »
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.
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.
88
Yate users hangout place / Re: [ YATE-6.0.1 ] CDRBuild Initialize & Finalize Issue
« on: July 03, 2018, 04:18:34 AM »
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?
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?
89
Yate users hangout place / Re: SS7 call redirect
« on: June 28, 2018, 01:24:02 AM »
You may try to set error to desired code.
Regexroute example:
[default]
^123=-;error=2
Regexroute example:
[default]
^123=-;error=2
90
Other Yate server issues / Re: MGCP FXS call to IAX trunk not signalling ringing
« on: June 25, 2018, 08:54:13 AM »
This is not a good idea:
I suppose this will indicate to the gateway to generate ringback (early media).
What will be GW's bahaviour when early media is received:
- ignore it ?
- stop generating ringback and forward early media?
- worst case: mix them?
Each gateway may have its own handling.
If you have targets indicating early media without actually playing it you should handle it by catching call.ringing/call.progress messages and explicitly set earlymedia=false
I suppose this will indicate to the gateway to generate ringback (early media).
What will be GW's bahaviour when early media is received:
- ignore it ?
- stop generating ringback and forward early media?
- worst case: mix them?
Each gateway may have its own handling.
If you have targets indicating early media without actually playing it you should handle it by catching call.ringing/call.progress messages and explicitly set earlymedia=false