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 ... 3 4 [5] 6 7 ... 35
61
Yate users hangout place / Re: Channel Message Direction Modification
« on: September 24, 2018, 11:59:30 PM »
How did you configure parameter storage in cdrbuild?
Did you disabled override?
See https://docs.yate.ro/wiki/CDR_Build_Module

62
You are passing a very long line.
This can be a yate message or a very long debug message.

63
Yate users hangout place / Re: Channel Message Direction Modification
« on: September 24, 2018, 03:49:27 AM »
TB_direction is missing in initial call.execute message 'copyparams' parameter list

64
Yate users hangout place / Re: Channel Message Direction Modification
« on: September 24, 2018, 02:47:03 AM »
Please post a log with message sniffer enabled.

65
Hi,
There no need to drop the channel: when it is re-executed it will be connected to a new channel (call leg) and disconnected from the old one.
You only need to make sure the call execute target module is loaded.

66
Yate users hangout place / Re: Channel Message Direction Modification
« on: September 18, 2018, 08:13:08 AM »
When used in call.execute parameters set in 'copyparams' are copied in outbound call leg's chan.startup.

Please unload cdrcombine.

67
Yate users hangout place / Re: Channel Message Direction Modification
« on: September 18, 2018, 07:35:46 AM »
Hi,

You should not use cdrcombine for this kind of application.

You should use your own logic to track and manage channels belonging to the same call. Your script may retain any information it needs to implement your application (remember: for outgoing calls you may dispatch the call.execute message and learn the target channel's id on return).

You may also use custom CDR parameters for this: when you start a call custom parameters (given in 'copyparams': comma separated list of parameter names) may be copied in chan.startup message which will be stored and used by cdrbuild if configured so.
Custom parameters will be set in all call.cdr messages sent by cdrbuild.

68
You may:
- Drop the channel (use call.drop message with 'id' parameter)
- Re-execute it to another destination (masquerade a call.execute message): the channel will be removed from conference and connected to new destination

You need to remember its channel id for both actions.

69
Yate based projects / Re: simple install - from SIP message
« on: September 03, 2018, 03:38:42 AM »
You may start at:
http://docs.yate.ro/wiki/SIP_Configuration_File

You may set the role parameter of local listener
role=local

Assuming outbound connection (listener) name is 'OUTBOUND' a simple regexroute routing:
[default]
${role}local=sip/sip:${called}@ADDR;oconnection_id=OUTBOUND


70
The 401 reply means server challenge (requires the client to authenticate).

71
The Proxy-Authorization header looks ok.
You should:
- re-check account settings. Make sure the password don't contain leading or trailing spaces
- try to use another sip client with same settings (to make sure everything is ok with credentials)
- ask Zadarma what happens (if possible)

72
Windows / Re: Is Yate client portable (on flash disk for instance)?
« on: August 09, 2018, 12:36:41 AM »
Here are some useful command line options:
   -c pathname    Path to conf files directory
   -u pathname    Path to user files directory
   -w directory   Change working directory

Settings are kept in user directory.
It may be an absolute path or relative to working directory


73
Yate users hangout place / Re: SIP Authentication Multi-Request
« on: August 06, 2018, 04:42:05 AM »
No.

74
Yate users hangout place / Re: Call.Route after call answered
« on: August 06, 2018, 03:27:08 AM »
call.route is not enough.
It just returns a target.

You must dispatch call.route, check result and masquerade a call.execute for the channel.

75
Yate users hangout place / Re: SIP Authentication Multi-Request
« on: August 06, 2018, 03:25:37 AM »
SIP MD5 auth is done in the following way:
Client sends method
Server replies with 401 with realm, nonce ...
Client repeats the request with response

The response is built from request name, realm, username (may be overridden by 'authname' when registered username is different than authenticated one), realm, nonce ...
To avoid reply attacks the server will expire the generated nonce after some period.

Pages: 1 ... 3 4 [5] 6 7 ... 35