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 ... 26
1
Linux / Re: Unique ringtone device or action - how?
« on: November 21, 2017, 02:19:36 AM »
YateClient has no support for separate audio device for incoming call alert.

You may implement some script to track incoming calls and play some alert on a device you want.
Audio device modules are located in modules/client (for various platforms there are alsa/oss (Linux), coreaudio (Mac) and dsound (Windows)).
Your script should track incoming calls, play a sound on a device at your choice and stop it when call is answered.

You may find some documentation at docs.yate.ro
You may want to look at chan.* and call.* messages.

2
Other Yate server issues / Re: Record all call
« on: October 20, 2017, 07:43:09 AM »
gsm codec is not available
It is implemented in gsmcodec.yate module

3
An incoming call has 3 stages of processing:
1. Pre-route. This may be used to handle the call origin, adjust parameters ... The [contexts] section in regexroute.conf handles the call.preroute message. The pre-route stage stopes when a context is returned.
2. Route. This is used to return an internal target and additional parameters used to make the outgoing call. The [default] section or sections matching 'context' returned in pre-route are used by regexroute module to return (or not) a target. Route stops when a target or error is returned
3. Execute. Execute the call to specified target

The regfile module is a routing module. When call.route is handled and called party number indicates a registered user the module will return its location (target). Routing process stops. No other module will handle call.route.
If you want to handle the call.route in regexroute just lower its call.route priority (see the 'route' parameter in [priorities] section. This will make regexroute to handle the call.route message before regfile module.

An alternative is to install a call.execute message handler in regexroute:
[extra]
call.execute=30

[call.execute]
${context}^INTERNAL$= ............ Call was routed by regfile
${context}^BLACKHOLE$= .............. Call was routed by regexroute

4
Didn't saw it in first post: message name parameter in chan.masquerade should be 'message' not 'messagae'

5
Other Yate server issues / Re: Yate Redirect SIP 300 Multiple Choices
« on: September 20, 2017, 03:29:56 AM »
You'll have to track the call to know its parameters.

A way to do it is to use a javascript routing script (see http://docs.yate.ro/wiki/How_to_do_routing_using_javascript)
The script will be attached to the incoming call leg. You may remember caller party in the script and handle redirect

You may also write a global script to track all call legs, remember their parameters and re-execute on disconnected.

I don't understand what do you mean by 'routing is not stopped'.
chan.disconnected is sent when the incoming call leg was detached: any internal routing process was terminated.
Please attach a log with message sniffer enabled.

6
You should post a log to see what happens.

7
Other Yate server issues / Re: Yate Redirect SIP 300 Multiple Choices
« on: September 19, 2017, 04:48:51 AM »
Javascript is not an external module. Yate has a javascript module. See http://docs.yate.ro/wiki/Javascript

A regexroute example:

[extra]
chan.disconnected=

[chan.disconnected]
${cause_sip}^300$={
  ; TODO:
  ; - Logic to detect choices from message
  ; - Logic to setup called target from choices (route)
  ; On success set 'CALLTO' parameter in handled message
  ${CALLTO}.=dispatch chan.masquerade;message=call.execute;id=${id};callto=${CALLTO}
}

You can find more at docs.yate.ro

http://docs.yate.ro/wiki/Regular_expressions
http://docs.yate.ro/wiki/How_to_convert_SIP_headers_into_SIP_parameters_names_in_messages
http://docs.yate.ro/wiki/Debugging_and,_or_Investigation_of_messages

8
Other Yate server issues / Re: Yate Redirect SIP 300 Multiple Choices
« on: September 19, 2017, 02:03:22 AM »
I don't know how choices are returned in contact header.

A call may be re-executed using chan.masquerade message.
Here is a javascript example of handling chan.disconnected:

function onChanDisc(msg)
{
    if (300 == msg.cause_sip) {
        var callto;
        // TODO:
        // - Logic to detect choices from message
        // - Logic to setup callto from choices (route)
        if (callto) {
            var m = new Message("chan.masquerade");
            m.message = "call.execute";
            m.id = msg.id;
            m.callto = callto;
            m.dispatch();
        }
   }
}

You may re-execute

9
Other Yate server issues / Re: Yate Redirect SIP 300 Multiple Choices
« on: September 19, 2017, 01:02:19 AM »
You may handle yate internal messages.
Received contact may be found in 'sip_contact' parameter of:
chan.hangup message sent by outgoing sip call leg
chan.disconnected message sent by incoming call leg when disconnected from outgoing channel.

I would recommend to watch the chann.disconnected message: you may re-execute the incoming call leg

10
Yate users hangout place / Re: 4 digit dialing
« on: September 13, 2017, 12:34:50 AM »
You must escape chars used by regexp:

^\([0-9]\{4\}=goto ....

Note that this regexp will match any target starting with 4 digits. If you to match exactly 4 digits you must add a $ char at the end

11
YateBTS / Re: Hi I have problem with mine BladeRF
« on: September 08, 2017, 01:19:24 AM »
Maybe you should still post a log: it may show some warning...

12
YateBTS / Re: Hi I have problem with mine BladeRF
« on: September 07, 2017, 08:37:28 AM »
I can't help you you with the RSSI warning. Hope someone will tell something about it.

Maybe you should post a yate log to see what happens.

13
Yate users hangout place / Re: SIP line logon failure 401: Unauthorized
« on: September 07, 2017, 04:01:23 AM »
Don't know what to say.
Did you tried another SIP client (X-lite) as suggested by provider? If it doesn't work this will definitely indicate a server failure.

You may also take a look at RFC 2617.
For 'qop'='auth' the response is calculated by:
response = md5(md5(username:realm:password):nonce:nc:cnonce:qop:md5(method:uri))
You may check Yate's response using log data (fields in Authorization header) and known password

You may also check (and dump here if possible) failed REGISTER transactions.
You may check for differences or patterns.

14
Yate users hangout place / Re: SIP line logon failure 401: Unauthorized
« on: September 07, 2017, 01:17:03 AM »
Can you post the log before last 401 (full REGISTER transaction)?
Can you say what is wrong with nonce handling?

15
YateBTS / Re: Hi I have problem with mine BladeRF
« on: September 07, 2017, 01:14:00 AM »
Radio (ybladerf) module is missing.
Possible causes: not loaded, not installed, not built.
Are you running yatebts from installed package or locally compiled?

Pages: [1] 2 3 ... 26