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.


Messages - marian

Pages: [1] 2 3 ... 30
1
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.

2
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!

3
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

4
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

5
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

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

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

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

9
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

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

12
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?

13
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

14
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

15
Please post logs for each case.
Make sure iax messages are printed on output (iax module debug must be at level 9).
Make sure message sniffer is enabled.

You may want to look at:
http://docs.yate.ro/wiki/Debugging_in_Yate
http://docs.yate.ro/wiki/Debug_Output
http://docs.yate.ro/wiki/Debugging_and,_or_Investigation_of_messages

Pages: [1] 2 3 ... 30