ivr script, originating a call
Hello I'm launching a javascript that originates a call to a user and then records a file. The problem is that the soundfiles ("record after the beep" and "message saved") sounds strange (choppy/vibrating, yeah I know, sucky explanation). The same phrases sounds fine when played for an incoming call. Is it a bitrate issue or something like that? Regards, Jonas
Jonas, Are you able to look at the FreeSWITCH console and see if the bitrate is an issue? Though I do not recall the exact message, the console will render this information when "console loglevel debug" has been turned on. I have experienced a similar issue, are you playing those files at 8000 bit rate? Anyways, the console will let you know if there is a mismatch and that FreeSWITCH is having to pull overtime in order to process the sounds. Cheers, Chris Jonas Gauffin wrote:
Hello
I'm launching a javascript that originates a call to a user and then records a file. The problem is that the soundfiles ("record after the beep" and "message saved") sounds strange (choppy/vibrating, yeah I know, sucky explanation).
The same phrases sounds fine when played for an incoming call.
Is it a bitrate issue or something like that?
Regards, Jonas
_______________________________________________ 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
It might be messed up ptime What are you making the outbound call too. And are you up to date on the code because we have fixed most issues that cause this in our latest release so if you are running latest it might be the other side of the call sending bad timestamps etc. On Mon, Apr 14, 2008 at 10:04 AM, Chris Danielson <chris@maxpowersoft.com> wrote:
Jonas, Are you able to look at the FreeSWITCH console and see if the bitrate is an issue? Though I do not recall the exact message, the console will render this information when "console loglevel debug" has been turned on. I have experienced a similar issue, are you playing those files at 8000 bit rate? Anyways, the console will let you know if there is a mismatch and that FreeSWITCH is having to pull overtime in order to process the sounds. Cheers, Chris
Jonas Gauffin wrote:
Hello
I'm launching a javascript that originates a call to a user and then records a file. The problem is that the soundfiles ("record after the beep" and "message saved") sounds strange (choppy/vibrating, yeah I know, sucky explanation).
The same phrases sounds fine when played for an incoming call.
Is it a bitrate issue or something like that?
Regards, Jonas
_______________________________________________ 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
_______________________________________________ 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 II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
I updated to lastest trunk yesterday and tried again. Same thing. Console log: http://pastebin.freeswitch.org/4233 Codec chosen for playing the file is: Codec Activated L16@8000hz 1 channels 20ms On Mon, Apr 14, 2008 at 5:34 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
It might be messed up ptime What are you making the outbound call too. And are you up to date on the code because we have fixed most issues that cause this in our latest release so if you are running latest it might be the other side of the call sending bad timestamps etc.
On Mon, Apr 14, 2008 at 10:04 AM, Chris Danielson <chris@maxpowersoft.com> wrote:
Jonas, Are you able to look at the FreeSWITCH console and see if the bitrate is an issue? Though I do not recall the exact message, the console will render this information when "console loglevel debug" has been turned on. I have experienced a similar issue, are you playing those files at 8000 bit rate? Anyways, the console will let you know if there is a mismatch and that FreeSWITCH is having to pull overtime in order to process the sounds. Cheers, Chris
Jonas Gauffin wrote:
Hello
I'm launching a javascript that originates a call to a user and then records a file. The problem is that the soundfiles ("record after the beep" and "message saved") sounds strange (choppy/vibrating, yeah I know, sucky explanation).
The same phrases sounds fine when played for an incoming call.
Is it a bitrate issue or something like that?
Regards, Jonas
_______________________________________________ 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
_______________________________________________ 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 II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ 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
Well you're playing a wav file aren't you? That is normal the codec for the call looks to be PCMU but to play the file it needs L16 so the core can translate it to the caller. Plus you seem to have not posted the full trace so I can see. console loglevel 8 and paste that. /b On Apr 16, 2008, at 1:35 AM, Jonas Gauffin wrote:
Codec chosen for playing the file is: Codec Activated L16@8000hz 1 channels 20ms
But why do the sound files work for incoming calls, but not for calls originated from a javascript? this feature have worked fine before (can't say which revision). a full log is coming. On Wed, Apr 16, 2008 at 2:59 PM, Brian West <brian@freeswitch.org> wrote:
Well you're playing a wav file aren't you? That is normal the codec for the call looks to be PCMU but to play the file it needs L16 so the core can translate it to the caller. Plus you seem to have not posted the full trace so I can see.
console loglevel 8
and paste that.
/b
On Apr 16, 2008, at 1:35 AM, Jonas Gauffin wrote:
Codec chosen for playing the file is: Codec Activated L16@8000hz 1 channels 20ms
_______________________________________________ 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
Can you please file it on jira and attach the script to reproduce it and any relevant logs? On Wed, Apr 16, 2008 at 8:17 AM, Jonas Gauffin <jonas.gauffin@gmail.com> wrote:
But why do the sound files work for incoming calls, but not for calls originated from a javascript? this feature have worked fine before (can't say which revision).
a full log is coming.
On Wed, Apr 16, 2008 at 2:59 PM, Brian West <brian@freeswitch.org> wrote:
Well you're playing a wav file aren't you? That is normal the codec for the call looks to be PCMU but to play the file it needs L16 so the core can translate it to the caller. Plus you seem to have not posted the full trace so I can see.
console loglevel 8
and paste that.
/b
On Apr 16, 2008, at 1:35 AM, Jonas Gauffin wrote:
Codec chosen for playing the file is: Codec Activated L16@8000hz 1 channels 20ms
_______________________________________________ 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
_______________________________________________ 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 II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
http://jira.freeswitch.org/browse/MODLANG-56 On Wed, Apr 16, 2008 at 4:15 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
Can you please file it on jira and attach the script to reproduce it and any relevant logs?
On Wed, Apr 16, 2008 at 8:17 AM, Jonas Gauffin <jonas.gauffin@gmail.com> wrote:
But why do the sound files work for incoming calls, but not for calls originated from a javascript? this feature have worked fine before (can't say which revision).
a full log is coming.
On Wed, Apr 16, 2008 at 2:59 PM, Brian West <brian@freeswitch.org> wrote:
Well you're playing a wav file aren't you? That is normal the codec for the call looks to be PCMU but to play the file it needs L16 so the core can translate it to the caller. Plus you seem to have not posted the full trace so I can see.
console loglevel 8
and paste that.
/b
On Apr 16, 2008, at 1:35 AM, Jonas Gauffin wrote:
Codec chosen for playing the file is: Codec Activated L16@8000hz 1 channels 20ms
_______________________________________________ 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
_______________________________________________ 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 II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ 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
We're busy integrating a heavy-duty call-control engine on top of the Freeswitch and I'm not sure if what's happening is by design or a bug: When originating a call via the "bgapi originate" call (mod_commands) the BACKGROUND event invoked only AFTER the call successfully terminated (answered/rejected). Because only the BACKGROUND event has the correlation between the JOB-UUID of the BGAPI command and the UNIQUE-ID, it's impossible to intercept all the events until that point (create, outgoing, ring, codec-exchange, etc). This becomes a real problem when originating multiple calls in a short time. It's impossible to distinguish which event belongs to which origination request. Resorting to pull that info from the DB or through SHOW CHANNELS might still cost missing few events. Anyone has any ideas on how to track an ORIGINATE call setup flow? Here's an extract from the log (just took the relevant parts): bgapi originate sofia/default/1001 &park Reply-Text: +OK Job-UUID: <UUID-A> Channel-State: CS_NEW Unique-ID: <UUID-B> Event-Name: CHANNEL_CREATE Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_OUTGOING Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_ORIGINATE Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: PRESENCE_IN Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: PRESENCE_IN Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_ANSWER API-Command: originate Event-Name: API Job-UUID: <UUID-A> Job-Command: originate Event-Name: BACKGROUND_JOB +OK <UUID-B> Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: PRESENCE_IN Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE Thanks, UV No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
You can set your own unique id reference as a variable to the originate using the {my_uuid=1234567ABCD} syntax and then track all events off that variable that should be included on every event. http://wiki.freeswitch.org/wiki/Freeswitch_IVR_Originate Also, we just fixed a little race that might have allowed you to get events before you got the background uuid so you probably want to update to most recent code. Mike On Apr 14, 2008, at 11:39 AM, UV wrote:
We're busy integrating a heavy-duty call-control engine on top of the Freeswitch and I'm not sure if what's happening is by design or a bug:
When originating a call via the "bgapi originate" call (mod_commands) the BACKGROUND event invoked only AFTER the call successfully terminated (answered/rejected). Because only the BACKGROUND event has the correlation between the JOB-UUID of the BGAPI command and the UNIQUE-ID, it's impossible to intercept all the events until that point (create, outgoing, ring, codec-exchange, etc).
This becomes a real problem when originating multiple calls in a short time. It's impossible to distinguish which event belongs to which origination request. Resorting to pull that info from the DB or through SHOW CHANNELS might still cost missing few events.
Anyone has any ideas on how to track an ORIGINATE call setup flow?
Here's an extract from the log (just took the relevant parts): bgapi originate sofia/default/1001 &park
Reply-Text: +OK Job-UUID: <UUID-A>
Channel-State: CS_NEW Unique-ID: <UUID-B> Event-Name: CHANNEL_CREATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_OUTGOING
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_ORIGINATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_ANSWER
API-Command: originate Event-Name: API
Job-UUID: <UUID-A> Job-Command: originate Event-Name: BACKGROUND_JOB +OK <UUID-B>
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Thanks, UV
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10- Apr-08 12:00 AM
_______________________________________________ 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
Thanks, Michael! Your advise seemed to be a workaround to most events although not all (missing some new, init and few others). I'll update to the newest version as soon as there's a fix for the win32 build (doesn't work for me either). Btw, Will that little race fixing allow me to correlate the BGPAI JOB-UUID to these missing events? It's not that I don't get those events - I just don't know what request initiated them... Cheers, UV -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: Tuesday, April 15, 2008 2:30 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] event BACKGROUND too late in ORIGINATEscenario? You can set your own unique id reference as a variable to the originate using the {my_uuid=1234567ABCD} syntax and then track all events off that variable that should be included on every event. http://wiki.freeswitch.org/wiki/Freeswitch_IVR_Originate Also, we just fixed a little race that might have allowed you to get events before you got the background uuid so you probably want to update to most recent code. Mike On Apr 14, 2008, at 11:39 AM, UV wrote:
We're busy integrating a heavy-duty call-control engine on top of the Freeswitch and I'm not sure if what's happening is by design or a bug:
When originating a call via the "bgapi originate" call (mod_commands) the BACKGROUND event invoked only AFTER the call successfully terminated (answered/rejected). Because only the BACKGROUND event has the correlation between the JOB-UUID of the BGAPI command and the UNIQUE-ID, it's impossible to intercept all the events until that point (create, outgoing, ring, codec-exchange, etc).
This becomes a real problem when originating multiple calls in a short time. It's impossible to distinguish which event belongs to which origination request. Resorting to pull that info from the DB or through SHOW CHANNELS might still cost missing few events.
Anyone has any ideas on how to track an ORIGINATE call setup flow?
Here's an extract from the log (just took the relevant parts): bgapi originate sofia/default/1001 &park
Reply-Text: +OK Job-UUID: <UUID-A>
Channel-State: CS_NEW Unique-ID: <UUID-B> Event-Name: CHANNEL_CREATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_OUTGOING
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_ORIGINATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_ANSWER
API-Command: originate Event-Name: API
Job-UUID: <UUID-A> Job-Command: originate Event-Name: BACKGROUND_JOB +OK <UUID-B>
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Thanks, UV
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10- Apr-08 12:00 AM
_______________________________________________ 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
_______________________________________________ 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 No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
I looked at the code and there is really only one place i can push the variables in sooner and that is before the CHANNEL_ORGINATE event. This event is fired as soon as the channel is created while it's waiting for it to ring etc. I moved the code that adds the variables from the {foo=bar} to right before this event. This is the earliest event you will be able to track an outbound call that you initiated. Any others that do not contain your param must be discarded because there is no way to get your information into the channel any sooner in the lifecycle of the channel. The change is in trunk so you will get that along with the other updates when we commit the fix to windows build. Note you can also pick your own job-uuid by adding the job-uuid header to your request using this with the suggestion the other guy gave you you can sync them api originate {my_uuid=ABC1234}sofia/default/1000@domain.com job-uuid: ABC1234 This will add the variable_my_uuid line to every event set to ABC1234 and the final job_uuid in the BACKGROUND event will also be ABC1234 On Mon, Apr 14, 2008 at 12:08 PM, UV <uv@talknet.com.au> wrote:
Thanks, Michael! Your advise seemed to be a workaround to most events although not all (missing some new, init and few others).
I'll update to the newest version as soon as there's a fix for the win32 build (doesn't work for me either).
Btw, Will that little race fixing allow me to correlate the BGPAI JOB-UUID to these missing events? It's not that I don't get those events - I just don't know what request initiated them...
Cheers, UV
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: Tuesday, April 15, 2008 2:30 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] event BACKGROUND too late in ORIGINATEscenario?
You can set your own unique id reference as a variable to the originate using the {my_uuid=1234567ABCD} syntax and then track all events off that variable that should be included on every event.
http://wiki.freeswitch.org/wiki/Freeswitch_IVR_Originate
Also, we just fixed a little race that might have allowed you to get events before you got the background uuid so you probably want to update to most recent code.
Mike
On Apr 14, 2008, at 11:39 AM, UV wrote:
We're busy integrating a heavy-duty call-control engine on top of the Freeswitch and I'm not sure if what's happening is by design or a bug:
When originating a call via the "bgapi originate" call (mod_commands) the BACKGROUND event invoked only AFTER the call successfully terminated (answered/rejected). Because only the BACKGROUND event has the correlation between the JOB-UUID of the BGAPI command and the UNIQUE-ID, it's impossible to intercept all the events until that point (create, outgoing, ring, codec-exchange, etc).
This becomes a real problem when originating multiple calls in a short time. It's impossible to distinguish which event belongs to which origination request. Resorting to pull that info from the DB or through SHOW CHANNELS might still cost missing few events.
Anyone has any ideas on how to track an ORIGINATE call setup flow?
Here's an extract from the log (just took the relevant parts): bgapi originate sofia/default/1001 &park
Reply-Text: +OK Job-UUID: <UUID-A>
Channel-State: CS_NEW Unique-ID: <UUID-B> Event-Name: CHANNEL_CREATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_OUTGOING
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_ORIGINATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_ANSWER
API-Command: originate Event-Name: API
Job-UUID: <UUID-A> Job-Command: originate Event-Name: BACKGROUND_JOB +OK <UUID-B>
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Thanks, UV
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10- Apr-08 12:00 AM
_______________________________________________ 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
_______________________________________________ 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
No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
_______________________________________________ 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 II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Excellent. So just to clarify, from the “Event-Name: CHANNEL_ORIGINATE” event, every thereafter will include the custom variable_{vars}. According to this, I’d only miss the two Event-Names: CHANNEL_CREATE and CHANNEL_OUTGOING (which I don’t really need). Thanks! _____ From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, April 15, 2008 3:31 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] event BACKGROUND too late inORIGINATEscenario? I looked at the code and there is really only one place i can push the variables in sooner and that is before the CHANNEL_ORGINATE event. This event is fired as soon as the channel is created while it's waiting for it to ring etc. I moved the code that adds the variables from the {foo=bar} to right before this event. This is the earliest event you will be able to track an outbound call that you initiated. Any others that do not contain your param must be discarded because there is no way to get your information into the channel any sooner in the lifecycle of the channel. The change is in trunk so you will get that along with the other updates when we commit the fix to windows build. Note you can also pick your own job-uuid by adding the job-uuid header to your request using this with the suggestion the other guy gave you you can sync them api originate {my_uuid=ABC1234}sofia/default/HYPERLINK "mailto:1000@domain.com"1000@domain.com job-uuid: ABC1234 This will add the variable_my_uuid line to every event set to ABC1234 and the final job_uuid in the BACKGROUND event will also be ABC1234 On Mon, Apr 14, 2008 at 12:08 PM, UV <HYPERLINK "mailto:uv@talknet.com.au"uv@talknet.com.au> wrote: Thanks, Michael! Your advise seemed to be a workaround to most events although not all (missing some new, init and few others). I'll update to the newest version as soon as there's a fix for the win32 build (doesn't work for me either). Btw, Will that little race fixing allow me to correlate the BGPAI JOB-UUID to these missing events? It's not that I don't get those events - I just don't know what request initiated them... Cheers, UV -----Original Message----- From: HYPERLINK "mailto:freeswitch-users-bounces@lists.freeswitch.org"freeswitch-users-bounc es@lists.freeswitch.org [mailto:HYPERLINK "mailto:freeswitch-users-bounces@lists.freeswitch.org"freeswitch-users-bounc es@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: Tuesday, April 15, 2008 2:30 AM To: HYPERLINK "mailto:freeswitch-users@lists.freeswitch.org"freeswitch-users@lists.freeswi tch.org Subject: Re: [Freeswitch-users] event BACKGROUND too late in ORIGINATEscenario? You can set your own unique id reference as a variable to the originate using the {my_uuid=1234567ABCD} syntax and then track all events off that variable that should be included on every event. HYPERLINK "http://wiki.freeswitch.org/wiki/Freeswitch_IVR_Originate" \nhttp://wiki.freeswitch.org/wiki/Freeswitch_IVR_Originate Also, we just fixed a little race that might have allowed you to get events before you got the background uuid so you probably want to update to most recent code. Mike On Apr 14, 2008, at 11:39 AM, UV wrote:
We're busy integrating a heavy-duty call-control engine on top of the Freeswitch and I'm not sure if what's happening is by design or a bug:
When originating a call via the "bgapi originate" call (mod_commands) the BACKGROUND event invoked only AFTER the call successfully terminated (answered/rejected). Because only the BACKGROUND event has the correlation between the JOB-UUID of the BGAPI command and the UNIQUE-ID, it's impossible to intercept all the events until that point (create, outgoing, ring, codec-exchange, etc).
This becomes a real problem when originating multiple calls in a short time. It's impossible to distinguish which event belongs to which origination request. Resorting to pull that info from the DB or through SHOW CHANNELS might still cost missing few events.
Anyone has any ideas on how to track an ORIGINATE call setup flow?
Here's an extract from the log (just took the relevant parts): bgapi originate sofia/default/1001 &park
Reply-Text: +OK Job-UUID: <UUID-A>
Channel-State: CS_NEW Unique-ID: <UUID-B> Event-Name: CHANNEL_CREATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_OUTGOING
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_ORIGINATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_ANSWER
API-Command: originate Event-Name: API
Job-UUID: <UUID-A> Job-Command: originate Event-Name: BACKGROUND_JOB +OK <UUID-B>
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Thanks, UV
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10- Apr-08 12:00 AM
_______________________________________________ Freeswitch-users mailing list HYPERLINK "mailto:Freeswitch-users@lists.freeswitch.org"Freeswitch-users@lists.freeswi tch.org HYPERLINK "http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" \nhttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:HYPERLINK "http://lists.freeswitch.org/mailman/options/freeswitch-users" \nhttp://lists.freeswitch.org/mailman/options/freeswitch-users HYPERLINK "http://www.freeswitch.org" \nhttp://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list HYPERLINK "mailto:Freeswitch-users@lists.freeswitch.org"Freeswitch-users@lists.freeswi tch.org HYPERLINK "http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" \nhttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:HYPERLINK "http://lists.freeswitch.org/mailman/options/freeswitch-users" \nhttp://lists.freeswitch.org/mailman/options/freeswitch-users HYPERLINK "http://www.freeswitch.org" \nhttp://www.freeswitch.org No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM _______________________________________________ Freeswitch-users mailing list HYPERLINK "mailto:Freeswitch-users@lists.freeswitch.org"Freeswitch-users@lists.freeswi tch.org HYPERLINK "http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" \nhttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:HYPERLINK "http://lists.freeswitch.org/mailman/options/freeswitch-users" \nhttp://lists.freeswitch.org/mailman/options/freeswitch-users HYPERLINK "http://www.freeswitch.org" \nhttp://www.freeswitch.org -- Anthony Minessale II FreeSWITCH HYPERLINK "http://www.freeswitch.org/"http://www.freeswitch.org/ ClueCon HYPERLINK "http://www.cluecon.com/"http://www.cluecon.com/ AIM: anthm HYPERLINK "mailto:MSN%3Aanthony_minessale@hotmail.com"MSN:anthony_minessale@hotmail.co m GTALK/JABBER/HYPERLINK "mailto:PAYPAL%3Aanthony.minessale@gmail.com"PAYPAL:anthony.minessale@gmail. com IRC: HYPERLINK "http://irc.freenode.net"irc.freenode.net #freeswitch FreeSWITCH Developer Conference HYPERLINK "mailto:sip%3A888@conference.freeswitch.org"sip:888@conference.freeswitch.or g HYPERLINK "http://iax:guest@conference.freeswitch.org/888"iax:guest@conference.freeswi tch.org/888 HYPERLINK "mailto:googletalk%3Aconf%2B888@conference.freeswitch.org"googletalk:conf+88 8@conference.freeswitch.org pstn:213-799-1400 No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
yes exactly. 2008/4/14 UV <uv@talknet.com.au>:
Excellent.
So just to clarify, from the "Event-Name: CHANNEL_ORIGINATE" event, every thereafter will include the custom variable_{vars}. According to this, I'd only miss the two Event-Names: CHANNEL_CREATE and CHANNEL_OUTGOING (which I don't really need).
Thanks!
------------------------------
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Anthony Minessale *Sent:* Tuesday, April 15, 2008 3:31 AM
*To:* freeswitch-users@lists.freeswitch.org *Subject:* Re: [Freeswitch-users] event BACKGROUND too late inORIGINATEscenario?
I looked at the code and there is really only one place i can push the variables in sooner and that is before the CHANNEL_ORGINATE event. This event is fired as soon as the channel is created while it's waiting for it to ring etc. I moved the code that adds the variables from the {foo=bar} to right before this event. This is the earliest event you will be able to track an outbound call that you initiated. Any others that do not contain your param must be discarded because there is no way to get your information into the channel any sooner in the lifecycle of the channel.
The change is in trunk so you will get that along with the other updates when we commit the fix to windows build.
Note you can also pick your own job-uuid by adding the job-uuid header to your request using this with the suggestion the other guy gave you you can sync them
api originate {my_uuid=ABC1234}sofia/default/1000@domain.com job-uuid: ABC1234
This will add the variable_my_uuid line to every event set to ABC1234 and the final job_uuid in the BACKGROUND event will also be ABC1234
On Mon, Apr 14, 2008 at 12:08 PM, UV <uv@talknet.com.au> wrote:
Thanks, Michael! Your advise seemed to be a workaround to most events although not all (missing some new, init and few others).
I'll update to the newest version as soon as there's a fix for the win32 build (doesn't work for me either).
Btw, Will that little race fixing allow me to correlate the BGPAI JOB-UUID to these missing events? It's not that I don't get those events - I just don't know what request initiated them...
Cheers, UV
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: Tuesday, April 15, 2008 2:30 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] event BACKGROUND too late in ORIGINATEscenario?
You can set your own unique id reference as a variable to the originate using the {my_uuid=1234567ABCD} syntax and then track all events off that variable that should be included on every event.
http://wiki.freeswitch.org/wiki/Freeswitch_IVR_Originate
Also, we just fixed a little race that might have allowed you to get events before you got the background uuid so you probably want to update to most recent code.
Mike
On Apr 14, 2008, at 11:39 AM, UV wrote:
We're busy integrating a heavy-duty call-control engine on top of the Freeswitch and I'm not sure if what's happening is by design or a bug:
When originating a call via the "bgapi originate" call (mod_commands) the BACKGROUND event invoked only AFTER the call successfully terminated (answered/rejected). Because only the BACKGROUND event has the correlation between the JOB-UUID of the BGAPI command and the UNIQUE-ID, it's impossible to intercept all the events until that point (create, outgoing, ring, codec-exchange, etc).
This becomes a real problem when originating multiple calls in a short time. It's impossible to distinguish which event belongs to which origination request. Resorting to pull that info from the DB or through SHOW CHANNELS might still cost missing few events.
Anyone has any ideas on how to track an ORIGINATE call setup flow?
Here's an extract from the log (just took the relevant parts): bgapi originate sofia/default/1001 &park
Reply-Text: +OK Job-UUID: <UUID-A>
Channel-State: CS_NEW Unique-ID: <UUID-B> Event-Name: CHANNEL_CREATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_OUTGOING
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_ORIGINATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_ANSWER
API-Command: originate Event-Name: API
Job-UUID: <UUID-A> Job-Command: originate Event-Name: BACKGROUND_JOB +OK <UUID-B>
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Thanks, UV
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10- Apr-08 12:00 AM
_______________________________________________ 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
_______________________________________________ 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
No virus found in this incoming message.
Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
_______________________________________________ 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 II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
_______________________________________________ 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 II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Hi I solved the exact same issue by setting an identifying variable on the channel when originating the call Bgapi originate {myVar=MyID}sofia/profile/dest You can parse that variable on the CHANNEL_ANSWER event or CHANNEL_HANGUP Bye. Cesar Cepeda.
-----Mensaje original----- De: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch- users-bounces@lists.freeswitch.org] En nombre de UV Enviado el: Lunes, 14 de Abril de 2008 10:40 Para: freeswitch-users@lists.freeswitch.org Asunto: [Freeswitch-users] event BACKGROUND too late in ORIGINATE scenario?
We're busy integrating a heavy-duty call-control engine on top of the Freeswitch and I'm not sure if what's happening is by design or a bug:
When originating a call via the "bgapi originate" call (mod_commands) the BACKGROUND event invoked only AFTER the call successfully terminated (answered/rejected). Because only the BACKGROUND event has the correlation between the JOB- UUID of the BGAPI command and the UNIQUE-ID, it's impossible to intercept all the events until that point (create, outgoing, ring, codec-exchange, etc).
This becomes a real problem when originating multiple calls in a short time. It's impossible to distinguish which event belongs to which origination request. Resorting to pull that info from the DB or through SHOW CHANNELS might still cost missing few events.
Anyone has any ideas on how to track an ORIGINATE call setup flow?
Here's an extract from the log (just took the relevant parts): bgapi originate sofia/default/1001 &park
Reply-Text: +OK Job-UUID: <UUID-A>
Channel-State: CS_NEW Unique-ID: <UUID-B> Event-Name: CHANNEL_CREATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_OUTGOING
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_ORIGINATE
Channel-State: CS_INIT Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_RING Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CODEC
Channel-State: CS_HOLD Unique-ID: <UUID-B> Event-Name: CHANNEL_ANSWER
API-Command: originate Event-Name: API
Job-UUID: <UUID-A> Job-Command: originate Event-Name: BACKGROUND_JOB +OK <UUID-B>
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: PRESENCE_IN
Channel-State: CS_EXECUTE Unique-ID: <UUID-B> Event-Name: CHANNEL_STATE
Thanks, UV
No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.12 - Release Date: 10-Apr-08 12:00 AM
_______________________________________________ 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
participants (7)
-
Anthony Minessale
-
Brian West
-
Cesar Cepeda
-
Chris Danielson
-
Jonas Gauffin
-
Michael Jerris
-
UV