hold_music var gets unset/lost by cancelled/failed att_xfer
I'm trying to do a second att_xfer on a call so that if the first attended transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that doesn't exist) then the call could be transferred to someone else. On the first att_xfer the person on hold hears the hold_music correctly. Once that transfer is cancelled or fails: -- On any subsequent att_xfer's the person on hold just hears silence. -- If they are put on hold they just hear silence. I tried setting hold_music again for each channel after the first att_xfer, but that didn't work, so it's probably not actually a problem with hold_music per se, but some other variable/setting that decides whether to use hold_music. I also tried doing a uuid_dump before and after each attempt, but didn't notice anything too different - unless it's a matter of unsetting one of the couple of changed/new vars like: variable_originate_disposition variable_current_application variable_playback_seconds I get the feeling other variables are probably also lost by the first failed transfer as the second att_xfer has some odd things happen if the third party does answer. Haven't been able to narrow it down as closely as the hold_music, but two things I've seen happen are: -- The party that initiated the transfer gets hung up automatically (after 30 sec) -- When the party that initiated the transfer hangs up it should connect the other two parties, but instead it hung up all three Cheers, Fraser
you really should report this to jira not to the mailing list. http://jira.freeswitch.org On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote:
I'm trying to do a second att_xfer on a call so that if the first attended transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that doesn't exist) then the call could be transferred to someone else.
On the first att_xfer the person on hold hears the hold_music correctly. Once that transfer is cancelled or fails: -- On any subsequent att_xfer's the person on hold just hears silence. -- If they are put on hold they just hear silence.
I tried setting hold_music again for each channel after the first att_xfer, but that didn't work, so it's probably not actually a problem with hold_music per se, but some other variable/setting that decides whether to use hold_music.
I also tried doing a uuid_dump before and after each attempt, but didn't notice anything too different - unless it's a matter of unsetting one of the couple of changed/new vars like: variable_originate_disposition variable_current_application variable_playback_seconds
I get the feeling other variables are probably also lost by the first failed transfer as the second att_xfer has some odd things happen if the third party does answer. Haven't been able to narrow it down as closely as the hold_music, but two things I've seen happen are: -- The party that initiated the transfer gets hung up automatically (after 30 sec) -- When the party that initiated the transfer hangs up it should connect the other two parties, but instead it hung up all three
Cheers, Fraser
_______________________________________________ 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/ 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
I have same issue with MOH and att_xfer on failed transfers, music on hold played only once At the same time, transfer_ringback always plays correctly to transferer 2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
you really should report this to jira not to the mailing list. http://jira.freeswitch.org
On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote:
I'm trying to do a second att_xfer on a call so that if the first attended transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that doesn't exist) then the call could be transferred to someone else.
On the first att_xfer the person on hold hears the hold_music correctly. Once that transfer is cancelled or fails: -- On any subsequent att_xfer's the person on hold just hears silence. -- If they are put on hold they just hear silence.
I tried setting hold_music again for each channel after the first att_xfer, but that didn't work, so it's probably not actually a problem with hold_music per se, but some other variable/setting that decides whether to use hold_music.
I also tried doing a uuid_dump before and after each attempt, but didn't notice anything too different - unless it's a matter of unsetting one of the couple of changed/new vars like: variable_originate_disposition variable_current_application variable_playback_seconds
I get the feeling other variables are probably also lost by the first failed transfer as the second att_xfer has some odd things happen if the third party does answer. Haven't been able to narrow it down as closely as the hold_music, but two things I've seen happen are: -- The party that initiated the transfer gets hung up automatically (after 30 sec) -- When the party that initiated the transfer hangs up it should connect the other two parties, but instead it hung up all three
Cheers, Fraser
_______________________________________________ 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/ 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-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
-- Best regards, Dmitry Sytchev, IT Engineer
try latest GIT On Tue, Feb 8, 2011 at 1:28 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I have same issue with MOH and att_xfer on failed transfers, music on hold played only once At the same time, transfer_ringback always plays correctly to transferer
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
you really should report this to jira not to the mailing list. http://jira.freeswitch.org
On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote:
I'm trying to do a second att_xfer on a call so that if the first attended transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that doesn't exist) then the call could be transferred to someone else.
On the first att_xfer the person on hold hears the hold_music correctly. Once that transfer is cancelled or fails: -- On any subsequent att_xfer's the person on hold just hears silence. -- If they are put on hold they just hear silence.
I tried setting hold_music again for each channel after the first att_xfer, but that didn't work, so it's probably not actually a problem with hold_music per se, but some other variable/setting that decides whether to use hold_music.
I also tried doing a uuid_dump before and after each attempt, but didn't notice anything too different - unless it's a matter of unsetting one of the couple of changed/new vars like: variable_originate_disposition variable_current_application variable_playback_seconds
I get the feeling other variables are probably also lost by the first failed transfer as the second att_xfer has some odd things happen if the third party does answer. Haven't been able to narrow it down as closely as the hold_music, but two things I've seen happen are: -- The party that initiated the transfer gets hung up automatically (after 30 sec) -- When the party that initiated the transfer hangs up it should connect the other two parties, but instead it hung up all three
Cheers, Fraser
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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
Thanks! It works now! BTW, att_xfer with loopback_bowout/bowout_on_execute set to false seems to be working too. Is there a way to make loopback channel leave the path? Without bowout turned off att_xfer doesn't work... 2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
try latest GIT
On Tue, Feb 8, 2011 at 1:28 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I have same issue with MOH and att_xfer on failed transfers, music on hold played only once At the same time, transfer_ringback always plays correctly to transferer
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
you really should report this to jira not to the mailing list. http://jira.freeswitch.org
On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote:
I'm trying to do a second att_xfer on a call so that if the first attended transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that doesn't exist) then the call could be transferred to someone else.
On the first att_xfer the person on hold hears the hold_music correctly. Once that transfer is cancelled or fails: -- On any subsequent att_xfer's the person on hold just hears silence. -- If they are put on hold they just hear silence.
I tried setting hold_music again for each channel after the first att_xfer, but that didn't work, so it's probably not actually a problem with hold_music per se, but some other variable/setting that decides whether to use hold_music.
I also tried doing a uuid_dump before and after each attempt, but didn't notice anything too different - unless it's a matter of unsetting one of the couple of changed/new vars like: variable_originate_disposition variable_current_application variable_playback_seconds
I get the feeling other variables are probably also lost by the first failed transfer as the second att_xfer has some odd things happen if the third party does answer. Haven't been able to narrow it down as closely as the hold_music, but two things I've seen happen are: -- The party that initiated the transfer gets hung up automatically (after 30 sec) -- When the party that initiated the transfer hangs up it should connect the other two parties, but instead it hung up all three
Cheers, Fraser
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards, Dmitry Sytchev, IT Engineer
I pushed a patch that will probably delay the bowout until after the att_xfer is over Give it a try. commit 3546654615f88058fb6769fe79e07162602fa4af Author: Anthony Minessale <anthm@freeswitch.org> Date: Thu Feb 10 12:37:14 2011 -0600 don't bow out on att_xfer bridge On Thu, Feb 10, 2011 at 1:03 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
Thanks! It works now! BTW, att_xfer with loopback_bowout/bowout_on_execute set to false seems to be working too. Is there a way to make loopback channel leave the path? Without bowout turned off att_xfer doesn't work...
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
try latest GIT
On Tue, Feb 8, 2011 at 1:28 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I have same issue with MOH and att_xfer on failed transfers, music on hold played only once At the same time, transfer_ringback always plays correctly to transferer
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
you really should report this to jira not to the mailing list. http://jira.freeswitch.org
On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote:
I'm trying to do a second att_xfer on a call so that if the first attended transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that doesn't exist) then the call could be transferred to someone else.
On the first att_xfer the person on hold hears the hold_music correctly. Once that transfer is cancelled or fails: -- On any subsequent att_xfer's the person on hold just hears silence. -- If they are put on hold they just hear silence.
I tried setting hold_music again for each channel after the first att_xfer, but that didn't work, so it's probably not actually a problem with hold_music per se, but some other variable/setting that decides whether to use hold_music.
I also tried doing a uuid_dump before and after each attempt, but didn't notice anything too different - unless it's a matter of unsetting one of the couple of changed/new vars like: variable_originate_disposition variable_current_application variable_playback_seconds
I get the feeling other variables are probably also lost by the first failed transfer as the second att_xfer has some odd things happen if the third party does answer. Haven't been able to narrow it down as closely as the hold_music, but two things I've seen happen are: -- The party that initiated the transfer gets hung up automatically (after 30 sec) -- When the party that initiated the transfer hangs up it should connect the other two parties, but instead it hung up all three
Cheers, Fraser
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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
I see your patch in git log, is it enough to do 'make current', or I should apply it in some special way? After make current issues are still present... What should i set loopback_bowout/bowout_on_execute variables to? I tried with false, this works as in previous versions, and loopback stays in path during the call. While loopback channels are present in path, there are issues with sound quality, there is robot voice effect for short periods of time. You mentioned setting rtp timer to none, where this should be done? In loopback channel execute_extension while doing att_xfer? When bowout variables set to true att_xfer doesn't work just as I described in my previous posts, and there is also issue with MOH - after transfer target answers to transferor, MOH is stoped for transferee. Maybe this can help somehow. 2011/2/10 Anthony Minessale <anthony.minessale@gmail.com>:
I pushed a patch that will probably delay the bowout until after the att_xfer is over Give it a try.
commit 3546654615f88058fb6769fe79e07162602fa4af Author: Anthony Minessale <anthm@freeswitch.org> Date: Thu Feb 10 12:37:14 2011 -0600
don't bow out on att_xfer bridge
On Thu, Feb 10, 2011 at 1:03 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
Thanks! It works now! BTW, att_xfer with loopback_bowout/bowout_on_execute set to false seems to be working too. Is there a way to make loopback channel leave the path? Without bowout turned off att_xfer doesn't work...
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
try latest GIT
On Tue, Feb 8, 2011 at 1:28 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I have same issue with MOH and att_xfer on failed transfers, music on hold played only once At the same time, transfer_ringback always plays correctly to transferer
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
you really should report this to jira not to the mailing list. http://jira.freeswitch.org
On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote:
I'm trying to do a second att_xfer on a call so that if the first attended transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that doesn't exist) then the call could be transferred to someone else.
On the first att_xfer the person on hold hears the hold_music correctly. Once that transfer is cancelled or fails: -- On any subsequent att_xfer's the person on hold just hears silence. -- If they are put on hold they just hear silence.
I tried setting hold_music again for each channel after the first att_xfer, but that didn't work, so it's probably not actually a problem with hold_music per se, but some other variable/setting that decides whether to use hold_music.
I also tried doing a uuid_dump before and after each attempt, but didn't notice anything too different - unless it's a matter of unsetting one of the couple of changed/new vars like: variable_originate_disposition variable_current_application variable_playback_seconds
I get the feeling other variables are probably also lost by the first failed transfer as the second att_xfer has some odd things happen if the third party does answer. Haven't been able to narrow it down as closely as the hold_music, but two things I've seen happen are: -- The party that initiated the transfer gets hung up automatically (after 30 sec) -- When the party that initiated the transfer hangs up it should connect the other two parties, but instead it hung up all three
Cheers, Fraser
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards, Dmitry Sytchev, IT Engineer
I reverted the patch, I guess it doesn't work based on your feedback. We will leave well enough alone when you said in your last email everything was working. There is a time when maybe you are taking things too far trying to solve things a silly way and maybe you should consider nicer equipment. On Fri, Feb 11, 2011 at 4:43 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I see your patch in git log, is it enough to do 'make current', or I should apply it in some special way? After make current issues are still present...
What should i set loopback_bowout/bowout_on_execute variables to? I tried with false, this works as in previous versions, and loopback stays in path during the call. While loopback channels are present in path, there are issues with sound quality, there is robot voice effect for short periods of time. You mentioned setting rtp timer to none, where this should be done? In loopback channel execute_extension while doing att_xfer?
When bowout variables set to true att_xfer doesn't work just as I described in my previous posts, and there is also issue with MOH - after transfer target answers to transferor, MOH is stoped for transferee. Maybe this can help somehow.
2011/2/10 Anthony Minessale <anthony.minessale@gmail.com>:
I pushed a patch that will probably delay the bowout until after the att_xfer is over Give it a try.
commit 3546654615f88058fb6769fe79e07162602fa4af Author: Anthony Minessale <anthm@freeswitch.org> Date: Thu Feb 10 12:37:14 2011 -0600
don't bow out on att_xfer bridge
On Thu, Feb 10, 2011 at 1:03 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
Thanks! It works now! BTW, att_xfer with loopback_bowout/bowout_on_execute set to false seems to be working too. Is there a way to make loopback channel leave the path? Without bowout turned off att_xfer doesn't work...
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
try latest GIT
On Tue, Feb 8, 2011 at 1:28 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I have same issue with MOH and att_xfer on failed transfers, music on hold played only once At the same time, transfer_ringback always plays correctly to transferer
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
you really should report this to jira not to the mailing list. http://jira.freeswitch.org
On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote: > I'm trying to do a second att_xfer on a call so that if the first attended > transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that > doesn't exist) then the call could be transferred to someone else. > > On the first att_xfer the person on hold hears the hold_music correctly. > Once that transfer is cancelled or fails: > -- On any subsequent att_xfer's the person on hold just hears silence. > -- If they are put on hold they just hear silence. > > I tried setting hold_music again for each channel after the first att_xfer, > but that didn't work, so it's probably not actually a problem with > hold_music per se, but some other variable/setting that decides whether to > use hold_music. > > I also tried doing a uuid_dump before and after each attempt, but didn't > notice anything too different - unless it's a matter of unsetting one of the > couple of changed/new vars like: > variable_originate_disposition > variable_current_application > variable_playback_seconds > > I get the feeling other variables are probably also lost by the first failed > transfer as the second att_xfer has some odd things happen if the third > party does answer. Haven't been able to narrow it down as closely as the > hold_music, but two things I've seen happen are: > -- The party that initiated the transfer gets hung up automatically (after > 30 sec) > -- When the party that initiated the transfer hangs up it should connect the > other two parties, but instead it hung up all three > > Cheers, > Fraser > > > > _______________________________________________ > 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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
Maybe you are right, but then tell me the right way :) att_xfer uses loopback by itself, and it doesn't work without tricks with not well documented loopback_bowout/bowout_on_execute variables... This behavior is not documented anywhere, but I can't propose wiki updates until I get it working or just give up with att_xfer in FS at all :) All I need is just working in-call att_xfer with Sofia channels :( SIP transfers are cool, but I need in-call DTMF triggered transfers :(( Is there a developer documentation about FS basic work principles? I'll try to dive in the code :)) 2011/2/11 Anthony Minessale <anthony.minessale@gmail.com>:
I reverted the patch, I guess it doesn't work based on your feedback. We will leave well enough alone when you said in your last email everything was working.
There is a time when maybe you are taking things too far trying to solve things a silly way and maybe you should consider nicer equipment.
On Fri, Feb 11, 2011 at 4:43 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I see your patch in git log, is it enough to do 'make current', or I should apply it in some special way? After make current issues are still present...
What should i set loopback_bowout/bowout_on_execute variables to? I tried with false, this works as in previous versions, and loopback stays in path during the call. While loopback channels are present in path, there are issues with sound quality, there is robot voice effect for short periods of time. You mentioned setting rtp timer to none, where this should be done? In loopback channel execute_extension while doing att_xfer?
When bowout variables set to true att_xfer doesn't work just as I described in my previous posts, and there is also issue with MOH - after transfer target answers to transferor, MOH is stoped for transferee. Maybe this can help somehow.
2011/2/10 Anthony Minessale <anthony.minessale@gmail.com>:
I pushed a patch that will probably delay the bowout until after the att_xfer is over Give it a try.
commit 3546654615f88058fb6769fe79e07162602fa4af Author: Anthony Minessale <anthm@freeswitch.org> Date: Thu Feb 10 12:37:14 2011 -0600
don't bow out on att_xfer bridge
On Thu, Feb 10, 2011 at 1:03 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
Thanks! It works now! BTW, att_xfer with loopback_bowout/bowout_on_execute set to false seems to be working too. Is there a way to make loopback channel leave the path? Without bowout turned off att_xfer doesn't work...
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
try latest GIT
On Tue, Feb 8, 2011 at 1:28 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I have same issue with MOH and att_xfer on failed transfers, music on hold played only once At the same time, transfer_ringback always plays correctly to transferer
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>: > you really should report this to jira not to the mailing list. > http://jira.freeswitch.org > > > > On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote: >> I'm trying to do a second att_xfer on a call so that if the first attended >> transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that >> doesn't exist) then the call could be transferred to someone else. >> >> On the first att_xfer the person on hold hears the hold_music correctly. >> Once that transfer is cancelled or fails: >> -- On any subsequent att_xfer's the person on hold just hears silence. >> -- If they are put on hold they just hear silence. >> >> I tried setting hold_music again for each channel after the first att_xfer, >> but that didn't work, so it's probably not actually a problem with >> hold_music per se, but some other variable/setting that decides whether to >> use hold_music. >> >> I also tried doing a uuid_dump before and after each attempt, but didn't >> notice anything too different - unless it's a matter of unsetting one of the >> couple of changed/new vars like: >> variable_originate_disposition >> variable_current_application >> variable_playback_seconds >> >> I get the feeling other variables are probably also lost by the first failed >> transfer as the second att_xfer has some odd things happen if the third >> party does answer. Haven't been able to narrow it down as closely as the >> hold_music, but two things I've seen happen are: >> -- The party that initiated the transfer gets hung up automatically (after >> 30 sec) >> -- When the party that initiated the transfer hangs up it should connect the >> other two parties, but instead it hung up all three >> >> Cheers, >> Fraser >> >> >> >> _______________________________________________ >> 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/ > 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-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 >
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards, Dmitry Sytchev, IT Engineer
bowout_on_execute is only useful to 1 leg calls you never have to set it. loopback_bowout is true by default it tries to cut loopback out by doing uuid_bridge which is certainly why it breaks for you. The last patch which is now reverted, prevented bowout when the CF_INNER_BRIDGE flag was set which is the case during att_xfer. You could save yourself some time and call your own box back over sip instead. On Fri, Feb 11, 2011 at 7:22 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
Maybe you are right, but then tell me the right way :) att_xfer uses loopback by itself, and it doesn't work without tricks with not well documented loopback_bowout/bowout_on_execute variables... This behavior is not documented anywhere, but I can't propose wiki updates until I get it working or just give up with att_xfer in FS at all :)
All I need is just working in-call att_xfer with Sofia channels :( SIP transfers are cool, but I need in-call DTMF triggered transfers :((
Is there a developer documentation about FS basic work principles? I'll try to dive in the code :))
2011/2/11 Anthony Minessale <anthony.minessale@gmail.com>:
I reverted the patch, I guess it doesn't work based on your feedback. We will leave well enough alone when you said in your last email everything was working.
There is a time when maybe you are taking things too far trying to solve things a silly way and maybe you should consider nicer equipment.
On Fri, Feb 11, 2011 at 4:43 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
I see your patch in git log, is it enough to do 'make current', or I should apply it in some special way? After make current issues are still present...
What should i set loopback_bowout/bowout_on_execute variables to? I tried with false, this works as in previous versions, and loopback stays in path during the call. While loopback channels are present in path, there are issues with sound quality, there is robot voice effect for short periods of time. You mentioned setting rtp timer to none, where this should be done? In loopback channel execute_extension while doing att_xfer?
When bowout variables set to true att_xfer doesn't work just as I described in my previous posts, and there is also issue with MOH - after transfer target answers to transferor, MOH is stoped for transferee. Maybe this can help somehow.
2011/2/10 Anthony Minessale <anthony.minessale@gmail.com>:
I pushed a patch that will probably delay the bowout until after the att_xfer is over Give it a try.
commit 3546654615f88058fb6769fe79e07162602fa4af Author: Anthony Minessale <anthm@freeswitch.org> Date: Thu Feb 10 12:37:14 2011 -0600
don't bow out on att_xfer bridge
On Thu, Feb 10, 2011 at 1:03 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote:
Thanks! It works now! BTW, att_xfer with loopback_bowout/bowout_on_execute set to false seems to be working too. Is there a way to make loopback channel leave the path? Without bowout turned off att_xfer doesn't work...
2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>:
try latest GIT
On Tue, Feb 8, 2011 at 1:28 AM, Dmitry Sytchev <kbdfck@gmail.com> wrote: > I have same issue with MOH and att_xfer on failed transfers, music on > hold played only once > At the same time, transfer_ringback always plays correctly to transferer > > 2011/2/8 Anthony Minessale <anthony.minessale@gmail.com>: >> you really should report this to jira not to the mailing list. >> http://jira.freeswitch.org >> >> >> >> On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond@gmail.com> wrote: >>> I'm trying to do a second att_xfer on a call so that if the first attended >>> transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that >>> doesn't exist) then the call could be transferred to someone else. >>> >>> On the first att_xfer the person on hold hears the hold_music correctly. >>> Once that transfer is cancelled or fails: >>> -- On any subsequent att_xfer's the person on hold just hears silence. >>> -- If they are put on hold they just hear silence. >>> >>> I tried setting hold_music again for each channel after the first att_xfer, >>> but that didn't work, so it's probably not actually a problem with >>> hold_music per se, but some other variable/setting that decides whether to >>> use hold_music. >>> >>> I also tried doing a uuid_dump before and after each attempt, but didn't >>> notice anything too different - unless it's a matter of unsetting one of the >>> couple of changed/new vars like: >>> variable_originate_disposition >>> variable_current_application >>> variable_playback_seconds >>> >>> I get the feeling other variables are probably also lost by the first failed >>> transfer as the second att_xfer has some odd things happen if the third >>> party does answer. Haven't been able to narrow it down as closely as the >>> hold_music, but two things I've seen happen are: >>> -- The party that initiated the transfer gets hung up automatically (after >>> 30 sec) >>> -- When the party that initiated the transfer hangs up it should connect the >>> other two parties, but instead it hung up all three >>> >>> Cheers, >>> Fraser >>> >>> >>> >>> _______________________________________________ >>> 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/ >> 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-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 >> > > > > -- > Best regards, > > Dmitry Sytchev, > IT Engineer > > _______________________________________________ > 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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-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
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ 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/ 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 (3)
-
Anthony Minessale
-
Dmitry Sytchev
-
Fraser Redmond