responce code 183 related functionality
As far as I know, when, during the calling, FS recieves 183 responce, call is considered succesful, it is marked in cdr and so on. While, there's possibility for this call to be failed, as after ringing the call might be declined. Asking in IRC on #freeswitch got me answer like "it's a question of conventions" - and it is right, but our convention (dictated by users) is that such call can not be marked as successful "a priori" - only when it really succeeded. I tried looking at sources of FS finding the place where it is judged, found something like it in switch_ivr_originate.c but i'm not sure it is the right place and tests i did - they didn't get me needed result. So here is my question: is it possible to make configurable behavior upon recieving 183? I'm aware about ignoring all early media, but this is not an option. I'm interested in managing status of call on recieving 183. -- Bambr in da house
On Sep 28, 2010, at 10:46 AM, Bambr wrote:
As far as I know, when, during the calling, FS recieves 183 responce, call is considered succesful, it is marked in cdr and so on. While, there's possibility for this call to be failed, as after ringing the call might be declined. Asking in IRC on #freeswitch got me answer like "it's a question of conventions" - and it is right, but our convention (dictated by users) is that such call can not be marked as successful "a priori" - only when it really succeeded. I tried looking at sources of FS finding the place where it is judged, found something like it in switch_ivr_originate.c but i'm not sure it is the right place and tests i did - they didn't get me needed result. So here is my question: is it possible to make configurable behavior upon recieving 183?
I'm aware about ignoring all early media, but this is not an option. I'm interested in managing status of call on recieving 183.
thats what ignore_early_media setting does.
It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call. On Tue, Sep 28, 2010 at 11:27 AM, Michael Jerris <mike@jerris.com> wrote:
On Sep 28, 2010, at 10:46 AM, Bambr wrote:
As far as I know, when, during the calling, FS recieves 183 responce, call is considered succesful, it is marked in cdr and so on. While, there's possibility for this call to be failed, as after ringing the call might be declined. Asking in IRC on #freeswitch got me answer like "it's a question of conventions" - and it is right, but our convention (dictated by users) is that such call can not be marked as successful "a priori" - only when it really succeeded. I tried looking at sources of FS finding the place where it is judged, found something like it in switch_ivr_originate.c but i'm not sure it is the right place and tests i did - they didn't get me needed result. So here is my question: is it possible to make configurable behavior upon recieving 183?
I'm aware about ignoring all early media, but this is not an option. I'm interested in managing status of call on recieving 183.
thats what ignore_early_media setting does.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire 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 googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan. On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call.
On Tue, Sep 28, 2010 at 11:27 AM, Michael Jerris <mike@jerris.com> wrote:
On Sep 28, 2010, at 10:46 AM, Bambr wrote:
As far as I know, when, during the calling, FS recieves 183 responce,
call is considered succesful, it is marked in cdr and so on. While, there's possibility for this call to be failed, as after ringing the call might be declined. Asking in IRC on #freeswitch got me answer like "it's a question of conventions" - and it is right, but our convention (dictated by users) is that such call can not be marked as successful "a priori" - only when it really succeeded. I tried looking at sources of FS finding the place where it is judged, found something like it in switch_ivr_originate.c but i'm not sure it is the right place and tests i did - they didn't get me needed result.
So here is my question: is it possible to make configurable behavior upon recieving 183?
I'm aware about ignoring all early media, but this is not an option. I'm interested in managing status of call on recieving 183.
thats what ignore_early_media setting does.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
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> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
Might I recommend you open a trouble ticket with your carrier and make them fix their problem since you do PAY them for services and they are clearly screwing up. /b On Oct 4, 2010, at 8:33 AM, Bambr wrote:
Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan.
On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote: It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call.
Carrier support said that sending 183 and then 486 is ok and they don't see the problem. I'm a bit messed with what is wrong and what is ok. So, just to clarify: they should be sending 486 and no 183 before it when needed, right? On Mon, Oct 4, 2010 at 4:10 PM, Brian West <brian@freeswitch.org> wrote:
Might I recommend you open a trouble ticket with your carrier and make them fix their problem since you do PAY them for services and they are clearly screwing up.
/b
On Oct 4, 2010, at 8:33 AM, Bambr wrote:
Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan.
On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote: It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
Another clarification, just a simple use case: 1. Calling a number, getting 486 right away -> "continue on fail" is triggered, it's OK 2. Calling a number, getting 183 and then 486 -> "continue on fail" is not triggered, which is not OK So usecase 2 is causing the troubles. On Mon, Oct 4, 2010 at 5:25 PM, Bambr <wooshie@gmail.com> wrote:
Carrier support said that sending 183 and then 486 is ok and they don't see the problem. I'm a bit messed with what is wrong and what is ok. So, just to clarify: they should be sending 486 and no 183 before it when needed, right?
On Mon, Oct 4, 2010 at 4:10 PM, Brian West <brian@freeswitch.org> wrote:
Might I recommend you open a trouble ticket with your carrier and make them fix their problem since you do PAY them for services and they are clearly screwing up.
/b
On Oct 4, 2010, at 8:33 AM, Bambr wrote:
Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan.
On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote: It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
-- Bambr in da house
What happens in case #2 when you have ignore_early_media=true ? -MC On Mon, Oct 4, 2010 at 8:35 AM, Bambr <wooshie@gmail.com> wrote:
Another clarification, just a simple use case: 1. Calling a number, getting 486 right away -> "continue on fail" is triggered, it's OK 2. Calling a number, getting 183 and then 486 -> "continue on fail" is not triggered, which is not OK So usecase 2 is causing the troubles.
On Mon, Oct 4, 2010 at 5:25 PM, Bambr <wooshie@gmail.com> wrote:
Carrier support said that sending 183 and then 486 is ok and they don't see the problem. I'm a bit messed with what is wrong and what is ok. So, just to clarify: they should be sending 486 and no 183 before it when needed, right?
On Mon, Oct 4, 2010 at 4:10 PM, Brian West <brian@freeswitch.org> wrote:
Might I recommend you open a trouble ticket with your carrier and make them fix their problem since you do PAY them for services and they are clearly screwing up.
/b
On Oct 4, 2010, at 8:33 AM, Bambr wrote:
Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan.
On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote: It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
-- Bambr in da house
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Well, we can not use ignore_early_media=true, it's dictated by client, so we have it on false, but, for testing purposes i think it's possible to make small test. On Mon, Oct 4, 2010 at 7:49 PM, Michael Collins <msc@freeswitch.org> wrote:
What happens in case #2 when you have ignore_early_media=true ? -MC
On Mon, Oct 4, 2010 at 8:35 AM, Bambr <wooshie@gmail.com> wrote:
Another clarification, just a simple use case: 1. Calling a number, getting 486 right away -> "continue on fail" is triggered, it's OK 2. Calling a number, getting 183 and then 486 -> "continue on fail" is not triggered, which is not OK So usecase 2 is causing the troubles.
On Mon, Oct 4, 2010 at 5:25 PM, Bambr <wooshie@gmail.com> wrote:
Carrier support said that sending 183 and then 486 is ok and they don't see the problem. I'm a bit messed with what is wrong and what is ok. So, just to clarify: they should be sending 486 and no 183 before it when needed, right?
On Mon, Oct 4, 2010 at 4:10 PM, Brian West <brian@freeswitch.org> wrote:
Might I recommend you open a trouble ticket with your carrier and make them fix their problem since you do PAY them for services and they are clearly screwing up.
/b
On Oct 4, 2010, at 8:33 AM, Bambr wrote:
Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan.
On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote: It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
-- Bambr in da house
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
Could you remind me why you can't use ignore_early_media? I mean, what does your client need that ignore_early_media does not provide? -MC On Mon, Oct 4, 2010 at 12:15 PM, Bambr <wooshie@gmail.com> wrote:
Well, we can not use ignore_early_media=true, it's dictated by client, so we have it on false, but, for testing purposes i think it's possible to make small test.
On Mon, Oct 4, 2010 at 7:49 PM, Michael Collins <msc@freeswitch.org>wrote:
What happens in case #2 when you have ignore_early_media=true ? -MC
On Mon, Oct 4, 2010 at 8:35 AM, Bambr <wooshie@gmail.com> wrote:
Another clarification, just a simple use case: 1. Calling a number, getting 486 right away -> "continue on fail" is triggered, it's OK 2. Calling a number, getting 183 and then 486 -> "continue on fail" is not triggered, which is not OK So usecase 2 is causing the troubles.
On Mon, Oct 4, 2010 at 5:25 PM, Bambr <wooshie@gmail.com> wrote:
Carrier support said that sending 183 and then 486 is ok and they don't see the problem. I'm a bit messed with what is wrong and what is ok. So, just to clarify: they should be sending 486 and no 183 before it when needed, right?
On Mon, Oct 4, 2010 at 4:10 PM, Brian West <brian@freeswitch.org>wrote:
Might I recommend you open a trouble ticket with your carrier and make them fix their problem since you do PAY them for services and they are clearly screwing up.
/b
On Oct 4, 2010, at 8:33 AM, Bambr wrote:
Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan.
On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote: It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
-- Bambr in da house
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
well, if we set ignore_early_media to true, then, while the call is getting to other side, there's either silence or we can play some music from our side. silence is not accepted by client, and playing music and then getting busy tone - considered misleading and confusing. client - sort of call center On Mon, Oct 4, 2010 at 10:56 PM, Michael Collins <msc@freeswitch.org> wrote:
Could you remind me why you can't use ignore_early_media? I mean, what does your client need that ignore_early_media does not provide? -MC
On Mon, Oct 4, 2010 at 12:15 PM, Bambr <wooshie@gmail.com> wrote:
Well, we can not use ignore_early_media=true, it's dictated by client, so we have it on false, but, for testing purposes i think it's possible to make small test.
On Mon, Oct 4, 2010 at 7:49 PM, Michael Collins <msc@freeswitch.org>wrote:
What happens in case #2 when you have ignore_early_media=true ? -MC
On Mon, Oct 4, 2010 at 8:35 AM, Bambr <wooshie@gmail.com> wrote:
Another clarification, just a simple use case: 1. Calling a number, getting 486 right away -> "continue on fail" is triggered, it's OK 2. Calling a number, getting 183 and then 486 -> "continue on fail" is not triggered, which is not OK So usecase 2 is causing the troubles.
On Mon, Oct 4, 2010 at 5:25 PM, Bambr <wooshie@gmail.com> wrote:
Carrier support said that sending 183 and then 486 is ok and they don't see the problem. I'm a bit messed with what is wrong and what is ok. So, just to clarify: they should be sending 486 and no 183 before it when needed, right?
On Mon, Oct 4, 2010 at 4:10 PM, Brian West <brian@freeswitch.org>wrote:
Might I recommend you open a trouble ticket with your carrier and make them fix their problem since you do PAY them for services and they are clearly screwing up.
/b
On Oct 4, 2010, at 8:33 AM, Bambr wrote:
> Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan. > > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote: > It doesn't say the call was successful it says the originate was. > The purpose of the originate function is to produce a channel with media. > The call can still end and you can still tell when and why from the > data in the call.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
-- Bambr in da house
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
check out "ringback" variable... and transfer_ringback. /b On Oct 4, 2010, at 7:50 PM, Bambr wrote:
well, if we set ignore_early_media to true, then, while the call is getting to other side, there's either silence or we can play some music from our side. silence is not accepted by client, and playing music and then getting busy tone - considered misleading and confusing. client - sort of call center
On Mon, Oct 4, 2010 at 10:56 PM, Michael Collins <msc@freeswitch.org> wrote: Could you remind me why you can't use ignore_early_media? I mean, what does your client need that ignore_early_media does not provide? -MC
did you try http://wiki.freeswitch.org/wiki/Variable_bridge_early_media ? be aware this comes with additional resource consumption required, but I think will do what your asking for. On Oct 4, 2010, at 9:19 PM, Brian West wrote:
check out "ringback" variable... and transfer_ringback.
/b
On Oct 4, 2010, at 7:50 PM, Bambr wrote:
well, if we set ignore_early_media to true, then, while the call is getting to other side, there's either silence or we can play some music from our side. silence is not accepted by client, and playing music and then getting busy tone - considered misleading and confusing. client - sort of call center
On Mon, Oct 4, 2010 at 10:56 PM, Michael Collins <msc@freeswitch.org> wrote: Could you remind me why you can't use ignore_early_media? I mean, what does your client need that ignore_early_media does not provide? -MC
once again, that is what setting ignore_early_media=true is for, when set, it keeps the channel in the originate function until either the call is answered or rejected. It does not ignore the responses it ignores the 183 as a possible reason to stop the originate. On Mon, Oct 4, 2010 at 8:33 AM, Bambr <wooshie@gmail.com> wrote:
Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan.
On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
It doesn't say the call was successful it says the originate was. The purpose of the originate function is to produce a channel with media. The call can still end and you can still tell when and why from the data in the call.
On Tue, Sep 28, 2010 at 11:27 AM, Michael Jerris <mike@jerris.com> wrote:
On Sep 28, 2010, at 10:46 AM, Bambr wrote:
As far as I know, when, during the calling, FS recieves 183 responce, call is considered succesful, it is marked in cdr and so on. While, there's possibility for this call to be failed, as after ringing the call might be declined. Asking in IRC on #freeswitch got me answer like "it's a question of conventions" - and it is right, but our convention (dictated by users) is that such call can not be marked as successful "a priori" - only when it really succeeded. I tried looking at sources of FS finding the place where it is judged, found something like it in switch_ivr_originate.c but i'm not sure it is the right place and tests i did - they didn't get me needed result. So here is my question: is it possible to make configurable behavior upon recieving 183?
I'm aware about ignoring all early media, but this is not an option. I'm interested in managing status of call on recieving 183.
thats what ignore_early_media setting does.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
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 googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Bambr in da house
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire 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 googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
participants (5)
-
Anthony Minessale
-
Bambr
-
Brian West
-
Michael Collins
-
Michael Jerris