headers
Monica Tepelus | 4 Jan 2010 09:31
Picon
Favicon

Re: Wave/play starts before ANSWER

Hi,

When a call is answered the message "call.answered" is emitted.
Try doing a php script that uses libyate.php.

Look at dialout-dialer.php from share/scripts directory for an example.

http://yate.null.ro/websvn/filedetails.php?repname=yate&path=%2Ftrunk%2Fshare%2Fscripts%2Fdialout-dialer.php

Regards,
Monica Tepelus

Isamar Maia wrote:
> I am using yate version "Yate 2.1.0 1" with an outbound IVR thru Rmanager.
>
> The call is done very simply from a PHP script:
>
> $e164dst1="557191468575";
> $timeout=1000;
> $socket = fsockopen("<ip address>","5038", $errno, $errstr, $timeout);
> fputs($socket, "<PASS>\r\n");
> fputs($socket, "call
> wave/play//usr/local/share/yate/sounds/soundfile.gsm $e164dst1\r\n");
>
> The problem is that the sound file starts playing before the call is
> answered, in the destination side,
> and the customer listen the message already in the middle.
>
> I thought the "autoprogress" parameter in the regexroute.conf could
> have anything related to that,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Monica Tepelus | 4 Jan 2010 10:18
Picon
Favicon

Re: Conference Dial-out

Hi,

recorder.php should not be disconnected. It should just start 
forwarder2.php and continue to get conference notifications. Check the 
code/logs.

Regards,
Monica Tepelus

Milan Rukavina wrote:
> Actually the main problem was trivial because forwarder2.php had no
> execute permission, also I fixed the initiation message to be (as in
> dialout-scheduler.php example):
>         $m = new Yate("call.execute");
>         $m->id = "";
>         $m->SetParam("callto","external/nodata/forwarder2.php");
>         $m->SetParam("direct",$callto);
>         $m->SetParam("caller",$caller);
>         $m->SetParam("callername",$callername);
>         $m->SetParam("called",$called);
>         $m->Dispatch();
> Now I have another problem. The script which sends this message -
> recorder.php, and which is conference listener, gets disconnected. Is
> there a way to make it online after this message and keep getting
> conference notifications?
>
> Thanks,
> Milan
>   
>> Hi All,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Isamar Maia | 4 Jan 2010 13:04
Picon

Re: Wave/play starts before ANSWER

Ok, Monica. Thanks a lok. I will do it.

Isamar

2010年1月4日5:31 Monica Tepelus <monica@...>:
> Hi,
>
> When a call is answered the message "call.answered" is emitted.
> Try doing a php script that uses libyate.php.
>
> Look at dialout-dialer.php from share/scripts directory for an example.
>
> http://yate.null.ro/websvn/filedetails.php?repname=yate&path=%2Ftrunk%2Fshare%2Fscripts%2Fdialout-dialer.php
>
> Regards,
> Monica Tepelus
>
>
> Isamar Maia wrote:
>> I am using yate version "Yate 2.1.0 1" with an outbound IVR thru Rmanager.
>>
>> The call is done very simply from a PHP script:
>>
>> $e164dst1="557191468575";
>> $timeout=1000;
>> $socket = fsockopen("<ip address>","5038", $errno, $errstr, $timeout);
>> fputs($socket, "<PASS>\r\n");
>> fputs($socket, "call
>> wave/play//usr/local/share/yate/sounds/soundfile.gsm $e164dst1\r\n");
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Milan Rukavina | 5 Jan 2010 10:12
Favicon

Re: Conference Dial-out

I'm not sure if I'm starting recorder the right way because I'm
receiving chan.notify events in the beginning, but on both forwarder.php
(the one that makes conference) and recorder.php. But when forwarder
dies,  I get for example chan.dtmf on recorder not chan.notify with
event dtmf, which should be normal I guess. After the connection is made
to forwarder2, recorder dies.

This is the code which makes a conference (forwarder.php):
                $location = new Yate("chan.masquerade");
                $location->params["message"] = "call.execute";
                $location->params["id"] = $partycallid;
                $location->params["callto"] = "conf/test";
                $location->params["caller"] = $caller;
                $location->params["callername"] = $callername;
                $location->params["called"] = $called;
                $location->params["billing"] = "true";
                $location->params["voice"] = "true";
                $location->params["lonely"] = "true";
                $location->params["record"] = "external/nodata/" .
getAppPath() . "recorder.php";
                $location->params['notify'] = "recorder/" . $partycallid;
                $location->Dispatch();

Here's how the recorder answers the call (recorder.php):
    switch($ev->type){
        case "incoming":
            switch ($ev->name) {
                case "call.execute":
                    if(!$ourcallid){
                        $partycallid = $ev->GetValue("id");
(Continue reading)

Permalink | Reply | 1 comment |
headers
Allan Sandfeld Jensen | 5 Jan 2010 13:42

Re: RFC: Yate 3 API changes and additions: Shared strings

On Monday 28 December 2009, Paul Chitescu wrote:
> 
> To be able to avoid the performance penalty the strings will have default
> shallow copy constructor and assignment operators. The memory for the
>  string will be shared between instances and will be atomically deep copied
>  only when the string is changed or on explicit demand.
> 
But if you are going to do atomic copying and possibly refcounting. Then why 
not just add a mutex or spinlock protection to the strings? The performance 
impact will be the same anyway. 

The alternative would be to use more mutex'es and just protect all uses of 
strings. I would prefer this as the performance would be better, but it would 
probably require more mutexes as the few YATE currently have are too global 
and thus dead-lock easily (a local mutex should not be held across a function-
call for instance).

`Allan
Permalink | Reply | 2 comments |
headers
Allan Sandfeld Jensen | 5 Jan 2010 13:45

Re: RFC: Yate 3 API changes and additions: Object query language

On Monday 28 December 2009, Paul Chitescu wrote:
> 
> The language is similar to SQL but the details make the difference. 
> 
> For performance reason the expression evaluation trees will be compiled on
> first use (or on demand).
> 
> Any ideas? Proposals? Comments?
> 
> 
Great idea, but I don't like the SQL part. It feels like too much overhead.

One solution I've been considering myself is a message that does something 
similar to chan->complete(msg). Imagine a call.complete or similar message 
where the cdrbuilder would extend the message with missing data.

`Allan
Permalink | Reply | 0 comments |
headers
Paul Chitescu | 5 Jan 2010 13:55
Picon
Favicon

Re: RFC: Yate 3 API changes and additions: Shared strings

On Tuesday 05 January 2010 02:42:35 pm Allan Sandfeld Jensen wrote:
> On Monday 28 December 2009, Paul Chitescu wrote:
> > 
> > To be able to avoid the performance penalty the strings will have default
> > shallow copy constructor and assignment operators. The memory for the
> >  string will be shared between instances and will be atomically deep 
copied
> >  only when the string is changed or on explicit demand.
> > 
> But if you are going to do atomic copying and possibly refcounting. Then why 
> not just add a mutex or spinlock protection to the strings? The performance 
> impact will be the same anyway. 
> 
> The alternative would be to use more mutex'es and just protect all uses of 
> strings. I would prefer this as the performance would be better, but it 
would 
> probably require more mutexes as the few YATE currently have are too global 
> and thus dead-lock easily (a local mutex should not be held across a 
function-
> call for instance).
> 
> `Allan

In many places you would need to acquire a lock that may not be easily 
accessible. The obvious case I'm trying to fix is CallEndpoint::getPeerId() 
which would require getting a lock on CallEndpoint::commonMutex() and making a 
deep copy of the string. Alternately the caller may need to hold the lock 
until it finishes using the string.

There are also some more places where if would be enough making a copy of the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Allan Sandfeld Jensen | 5 Jan 2010 16:36

Re: RFC: Yate 3 API changes and additions: Shared strings

On Tuesday 05 January 2010, Paul Chitescu wrote:
> In many places you would need to acquire a lock that may not be easily
> accessible. The obvious case I'm trying to fix is CallEndpoint::getPeerId()
> which would require getting a lock on CallEndpoint::commonMutex() and
>  making a deep copy of the string. Alternately the caller may need to hold
>  the lock until it finishes using the string.
> 
> There are also some more places where if would be enough making a copy of
>  the string by a method that can internally take the lock. I want to avoid
>  the overhead of always making a deep copy.
> 
Good point, though I have never seen the deep copy constructor appear anywhere 
significant in the performance traces. If we want to avoid deep copies we 
would be better served by fixing all the places that append one character at a 
time (currently causing a deep copy for every character which it also would 
under the proposed new system). I have patches for this and I know several 
other developers have too.

`Allan
Permalink | Reply | 0 comments |
headers
Monica Tepelus | 5 Jan 2010 17:32
Picon
Favicon

Re: Conference Dial-out

Hi,

Please see my answered inline.
The pieces that you send seem ok. It would be easier to just send the 
files and your how to test them.

Regards,
Monica Tepelus

Milan Rukavina wrote:
> I'm not sure if I'm starting recorder the right way because I'm
> receiving chan.notify events in the beginning, but on both forwarder.php
> (the one that makes conference) and recorder.php. But when forwarder
> dies,  I get for example chan.dtmf on recorder not chan.notify with
> event dtmf, which should be normal I guess. After the connection is made
> to forwarder2, recorder dies.
>
> This is the code which makes a conference (forwarder.php):
>                 $location = new Yate("chan.masquerade");
>                 $location->params["message"] = "call.execute";
>                 $location->params["id"] = $partycallid;
>                 $location->params["callto"] = "conf/test";
>                 $location->params["caller"] = $caller;
>                 $location->params["callername"] = $callername;
>                 $location->params["called"] = $called;
>                 $location->params["billing"] = "true";
>                 $location->params["voice"] = "true";
>                 $location->params["lonely"] = "true";
>                 $location->params["record"] = "external/nodata/" .
> getAppPath() . "recorder.php";
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Chitescu | 6 Jan 2010 14:18
Picon
Favicon

Change in register

Hi!

If you are using the register module to handle authentication please note that 
SVN Rev. 3008 (3009 for YATE_2) brings a little change.

Whatever password return column is designated in the result=... setting in 
[user.auth] it must be present in the result set. Even if you only authorize 
by address or some other parameter you must always return a password column, 
even if it's NULL.

You are only affected if you didn't return a password, for example by a query 
like:

query=SELECT x_param FROM gateways WHERE address='${address}'
result=

To make it work now you can change that to:

query=SELECT x_param, NULL AS no_pass FROM gateways WHERE address='${address}'
result=no_pass

The reason of the change is that a configuration mismatch between the result 
setting and the returned columns leads to authentication of users no matter 
the presented credentials.

Paul Chitescu
Permalink | Reply | 0 comments |

Gmane