subject:"Re\: \[asterisk\-dev\] AMD"

Re: [asterisk-dev] AMD

2020-01-31 Thread i...@magnussolution.com

hello,

thanks Kevin, I use ast_check_hangup(chan_peer) and I can get the user CANCEL. 

for now my APP work ok, I’ll test in production. 


Thanks



> On 30 Jan 2020, at 16:04, i...@magnussolution.com wrote:
> 
> Hi Kevin, thanks for your help
> 
> I’ll to try your recommendation and send you the feedback.
> 
> There is any existent method to execute AMD on the 183? 
> 
> best regards
> 
> 
>> On 30 Jan 2020, at 14:21, Kevin Harwell > > wrote:
>> 
>> On Wed, Jan 29, 2020 at 3:07 PM i...@magnussolution.com 
>>  > > wrote:
>> Hello
>> 
>> I’m to try execute AMD on the 183 signalisation, to detect audio on early 
>> media.
>> 
>> 
>> I’m work in  app_dial.c and it work ok when the audio start on the beginner, 
>> but when keep ringing I need to continue analyse until receive the 200 OK or 
>> some error. I already do it
>> 
>> but, always there a but, when the call is canceled I need to stop the 
>> whatfor() method.
>> 
>> 
>> while ((res = ast_waitfor(chan, 2 * maxWaitTimeForFrame)) > -1) {
>> //here is where I analise the 183 
>> 
>> /* this code check the chan status to break the while()*/
>> if (ast_channel_state(chan) != 5) { 
>>  ast_verb(1,"status channel answere %d 
>> \n",ast_channel_state(chan));
>>  ast_frfree(f); 
>> break; 
>>  }
>> 
>> }
>> 
>> 
>> there are any method to check if the originate channel CANCEL the call?
>> 
>> 
>> Looking through the app_dial code it looks like the peerflags gets set upon 
>> hangup. If you can get access to that (not sure where your code is located) 
>> then you should be able to check the OPT_CALLER_HANGUP value for that.
>> 
>> Another alternative maybe is the hangupcause as it gets set on the channel 
>> too when hung up so you might be able to retrieve that and check it for some 
>> value, but not sure if the causes will give you what you need.
>> 
>> A third way is to check if the channel hung up using the "ast_check_hangup" 
>> or "ast_check_hangup_locked" function (maybe the best option?).
>> 
>> -- 
>> Kevin Harwell
>> Senior Software Developer
>> Sangoma Technologies
>> Check us out at: https://sangoma.com  & 
>> https://asterisk.org -- 
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com 
>>  --
>> 
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev 
>> 

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AMD

2020-01-30 Thread Richard Mudgett

On Thu, Jan 30, 2020 at 5:19 PM Kevin Harwell  wrote:

> On Thu, Jan 30, 2020 at 2:58 PM i...@magnussolution.com <
> i...@magnussolution.com> wrote:
>
>> in my country when I dial to a mobile and I not answer the call, the call
>> going to the voicemail, but the audio is executed before the 200OK, on 183
>> early media.
>>
>> so, I need to execute the AMD when I receive the 183, not the 200 OK.
>>
>
> Unfortunately I am unaware of any easy solution.
>
> Something to be aware of if you are not. From what I understand app_dial
> is reading the frames from the channel. Any solution that attempts to also
> read frames from the same channel at the same time is going to run into
> problems. So for instance, you can't execute app_dial and app_amd at the
> same time.
>
> If you wish to inject some kind of audio listening, and detection
> algorithms while dialing you'll have to do that within the confines of the
> dial application. Basically, while app_dial is waiting for the other side
> to answer it's processing frames. When an audio frame is received then that
> is where you'll want to do your detection. Also once answered you'll need
> to continue processing incoming audio frames. Maybe you are already doing
> all of this?
>
> If that's the case then if a hangup occurs app_dial will automatically
> handle what you need since it will detect the hangup and stop reading
> frames, which in turn means audio will not get passed down into your
> detection checks anymore. There is no loop to break out of since the dial
> application is handing that for you (reading of frames, etc.).
>

Frame hooks or audio hooks might help here.  Off hand, I don't know if they
are active at this time but they might make it easier to implement in
another module.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AMD

2020-01-30 Thread Kevin Harwell

On Thu, Jan 30, 2020 at 2:58 PM i...@magnussolution.com <
i...@magnussolution.com> wrote:

> in my country when I dial to a mobile and I not answer the call, the call
> going to the voicemail, but the audio is executed before the 200OK, on 183
> early media.
>
> so, I need to execute the AMD when I receive the 183, not the 200 OK.
>

Unfortunately I am unaware of any easy solution.

Something to be aware of if you are not. From what I understand app_dial is
reading the frames from the channel. Any solution that attempts to also
read frames from the same channel at the same time is going to run into
problems. So for instance, you can't execute app_dial and app_amd at the
same time.

If you wish to inject some kind of audio listening, and detection
algorithms while dialing you'll have to do that within the confines of the
dial application. Basically, while app_dial is waiting for the other side
to answer it's processing frames. When an audio frame is received then that
is where you'll want to do your detection. Also once answered you'll need
to continue processing incoming audio frames. Maybe you are already doing
all of this?

If that's the case then if a hangup occurs app_dial will automatically
handle what you need since it will detect the hangup and stop reading
frames, which in turn means audio will not get passed down into your
detection checks anymore. There is no loop to break out of since the dial
application is handing that for you (reading of frames, etc.).

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AMD

2020-01-30 Thread i...@magnussolution.com

in my country when I dial to a mobile and I not answer the call, the call going 
to the voicemail, but the audio is executed before the 200OK, on 183 early 
media.

so, I need to execute the AMD when I receive the 183, not the 200 OK.

I hope I my explanation was enough 

best regards
Adilson Magnus




> On 30 Jan 2020, at 17:44, Kevin Harwell  wrote:
> 
> On Thu, Jan 30, 2020 at 1:04 PM i...@magnussolution.com 
>   > wrote:
> Hi Kevin, thanks for your help
> 
> I’ll to try your recommendation and send you the feedback.
> 
> There is any existent method to execute AMD on the 183? 
> 
> I'm not sure. If you can please describe the overall scenario you are trying 
> to implement, or the problem you are trying to solve. With a bigger picture 
> of what you are trying to do someone might be able to point you in a 
> direction.
>  
> -- 
> Kevin Harwell
> Senior Software Developer
> Sangoma Technologies
> Check us out at: https://sangoma.com  & 
> https://asterisk.org -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AMD

2020-01-30 Thread Kevin Harwell

On Thu, Jan 30, 2020 at 1:04 PM i...@magnussolution.com <
i...@magnussolution.com> wrote:

> Hi Kevin, thanks for your help
>
> I’ll to try your recommendation and send you the feedback.
>
> There is any existent method to execute AMD on the 183?
>

I'm not sure. If you can please describe the overall scenario you are
trying to implement, or the problem you are trying to solve. With a bigger
picture of what you are trying to do someone might be able to point you in
a direction.

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AMD

2020-01-30 Thread i...@magnussolution.com

Hi Kevin, thanks for your help

I’ll to try your recommendation and send you the feedback.

There is any existent method to execute AMD on the 183? 

best regards


> On 30 Jan 2020, at 14:21, Kevin Harwell  wrote:
> 
> On Wed, Jan 29, 2020 at 3:07 PM i...@magnussolution.com 
>   > wrote:
> Hello
> 
> I’m to try execute AMD on the 183 signalisation, to detect audio on early 
> media.
> 
> 
> I’m work in  app_dial.c and it work ok when the audio start on the beginner, 
> but when keep ringing I need to continue analyse until receive the 200 OK or 
> some error. I already do it
> 
> but, always there a but, when the call is canceled I need to stop the 
> whatfor() method.
> 
> 
> while ((res = ast_waitfor(chan, 2 * maxWaitTimeForFrame)) > -1) {
> //here is where I analise the 183 
> 
> /* this code check the chan status to break the while()*/
> if (ast_channel_state(chan) != 5) { 
>  ast_verb(1,"status channel answere %d 
> \n",ast_channel_state(chan));
>  ast_frfree(f); 
> break; 
>  }
> 
> }
> 
> 
> there are any method to check if the originate channel CANCEL the call?
> 
> 
> Looking through the app_dial code it looks like the peerflags gets set upon 
> hangup. If you can get access to that (not sure where your code is located) 
> then you should be able to check the OPT_CALLER_HANGUP value for that.
> 
> Another alternative maybe is the hangupcause as it gets set on the channel 
> too when hung up so you might be able to retrieve that and check it for some 
> value, but not sure if the causes will give you what you need.
> 
> A third way is to check if the channel hung up using the "ast_check_hangup" 
> or "ast_check_hangup_locked" function (maybe the best option?).
> 
> -- 
> Kevin Harwell
> Senior Software Developer
> Sangoma Technologies
> Check us out at: https://sangoma.com  & 
> https://asterisk.org -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com 
>  --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev 
> 
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AMD

2020-01-30 Thread Kevin Harwell

On Wed, Jan 29, 2020 at 3:07 PM i...@magnussolution.com <
i...@magnussolution.com> wrote:

> Hello
>
> I’m to try execute AMD on the 183 signalisation, to detect audio on early
> media.
>
>
> I’m work in  app_dial.c and it work ok when the audio start on the
> beginner, but when keep ringing I need to continue analyse until receive
> the 200 OK or some error. I already do it
>
> but, always there a but, when the call is canceled I need to stop the
> whatfor() method.
>
>
> while ((res = ast_waitfor(chan, 2 * maxWaitTimeForFrame)) > -1) {
> //here is where I analise the 183
>
> /* this code check the chan status to break the while()*/
> if (ast_channel_state(chan) != 5) {
>  ast_verb(1,"status channel answere %d
> \n",ast_channel_state(chan));
>  ast_frfree(f);
> break;
>  }
>
> }
>
>
> there are any method to check if the originate channel CANCEL the call?
>
>
Looking through the app_dial code it looks like the peerflags gets set upon
hangup. If you can get access to that (not sure where your code is located)
then you should be able to check the OPT_CALLER_HANGUP value for that.

Another alternative maybe is the hangupcause as it gets set on the channel
too when hung up so you might be able to retrieve that and check it for
some value, but not sure if the causes will give you what you need.

A third way is to check if the channel hung up using the "ast_check_hangup"
or "ast_check_hangup_locked" function (maybe the best option?).

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AMD

Re: [asterisk-dev] AMD

Re: [asterisk-dev] AMD

Re: [asterisk-dev] AMD

Re: [asterisk-dev] AMD

Re: [asterisk-dev] AMD

Re: [asterisk-dev] AMD

7 matches

Site Navigation

Mail list logo

Footer information