VoIP Mailing List Archives

[odermann at googlemail...]

hi,

i am using socket outbound with fs.

if i do an originate over the console, for starting an outbound call
without having an inbound call, and send the originate directly to the
socket, the socket is first started, if the call is in answer or
ringing state.
before this, i will not receive any event, because the socket was not
started. therefore i will not know, if the target is "busy" (hangup,
hangup cause: user busy).

it would be very helpful, if the socket would start immediately on an
event like "channel originate".


thanks for the help
dennis

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[anthony.minessale at g...]

when an originate is unsuccessful the failure and the cause code is returned as the reply to the originate request.


On Mon, Feb 9, 2009 at 9:16 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote:

[odermann at googlemail...]

yes, you are right. we are receiving the reply.

but, we are using socket outbound and manage all calls over this
socket. we also measure the durations (like variable_duration and
variable_billsec) and count all outgoing calls over the socket.
but, if the originate (without an inbound call) will not start the
socket, we can not count up, how many calls failed because of "user
busy" or how long the platform was in use.

a possible workarround: is it possible to trigger a dialplan over the
cli (like our default dialplan, which starts the socket), so that the
dialplan starts the originates?

the basic problem for us, that, if we just want to make dialouts, we
are missing the inbound call to start the socket.


kind regards
dennis



2009/2/9 Anthony Minessale <anthony.minessale@gmail.com>:

[odermann at googlemail...]

anthony, did you make the changes with "add {instant_ringback=true} to
make ringback not wait for indication to generate ringback" for the
described problem?

we read something like this out of it, but we can not test it, because
we get errors with the latest fs version (switch_ivr.c:674
switch_ivr_park() Cannot park channels that have no read codec.).



2009/2/10 Dennis <odermann@googlemail.com>:

[brian at freeswitch.org]

Try answer or pre_answer before park.

/b

On Feb 11, 2009, at 12:37 PM, Dennis wrote:

[odermann at googlemail...]

this does not help. we are using socket outbound and everything worked
before the changes yesterday.

we have the same error with other dialplans.

[brian at freeswitch.org]

Please collect the backtrace and report it on Jira.

/b

On Feb 11, 2009, at 2:11 PM, Dennis wrote:

[odermann at googlemail...]

the problem is fixed in the latest version of fs - at least it is
working as before without any errors.

but there is still the question, if the changes where made because of
our problem with the not starting socket!?
we can see in the cli, that the var is set, but it does not change
anything regarding our problem.



2009/2/11 Brian West <brian@freeswitch.org>:

[anthony.minessale at g...]

No, I have not made any changes to reflect anything you asked about.
instant_ringback=true is designed to send artificial ringback to the a leg while it's executing the bridge app.
it will be meaningless to you if you do not use it with the bridge application


On Thu, Feb 12, 2009 at 1:39 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote: