Attended transfers to an external c-leg is breaking 3-way conference functionality for me. Like this: <action application="att_xfer" data="sofia/gateway/onesource/${attxfer_callthis}"/> The c-leg is established and hanging up the originator's leg will successfully bridge the other 2. However, pressing 0 on the originator, which should establish a 3-way conference, actually hangs up the c-leg. Is there another method by which I should specify the outbound leg for att_xfer?
Get a console log with full siptrace (on both internal and external profiles) and drop it into pastebin. Be sure to specific "FreeSWITCH log" for syntax highlighting to make it easier to read. Send the pb link here. Hopefully you or another user will be able to parse the logs to see what is happening. -MC On Tue, Apr 19, 2011 at 11:49 AM, elijah <elijah@crankenstein.com> wrote:
Attended transfers to an external c-leg is breaking 3-way conference functionality for me. Like this:
<action application="att_xfer" data="sofia/gateway/onesource/${attxfer_callthis}"/>
The c-leg is established and hanging up the originator's leg will successfully bridge the other 2. However, pressing 0 on the originator, which should establish a 3-way conference, actually hangs up the c-leg. Is there another method by which I should specify the outbound leg for att_xfer?
_______________________________________________ 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
Ok, here's the log: http://pastebin.freeswitch.org/16144 <http://pastebin.freeswitch.org/16144>Any input would be great - I'm not seeing the condition that is causing 0 to drop the c-leg after an attended bridge. thanks, elijah On Tue, Apr 19, 2011 at 12:39 PM, Michael Collins <msc@freeswitch.org>wrote:
Get a console log with full siptrace (on both internal and external profiles) and drop it into pastebin. Be sure to specific "FreeSWITCH log" for syntax highlighting to make it easier to read. Send the pb link here. Hopefully you or another user will be able to parse the logs to see what is happening.
-MC
On Tue, Apr 19, 2011 at 11:49 AM, elijah <elijah@crankenstein.com> wrote:
Attended transfers to an external c-leg is breaking 3-way conference functionality for me. Like this:
<action application="att_xfer" data="sofia/gateway/onesource/${attxfer_callthis}"/>
The c-leg is established and hanging up the originator's leg will successfully bridge the other 2. However, pressing 0 on the originator, which should establish a 3-way conference, actually hangs up the c-leg. Is there another method by which I should specify the outbound leg for att_xfer?
_______________________________________________ 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
There is an example of using this in the default config in features.xml /b On Apr 20, 2011, at 9:13 PM, elijah wrote:
Ok, here's the log: http://pastebin.freeswitch.org/16144 <http://pastebin.freeswitch.org/16144>Any input would be great - I'm not seeing the condition that is causing 0 to drop the c-leg after an attended bridge.
thanks, elijah
Right. That's the example I used. My config looks like this: <action application="bind_meta_app" data="1 b s execute_extension::ax XML callsdirect"/> <extension name="bind_receiver"> <condition field="destination_number" expression="^ax$"> <action application="answer"/> <action application="read" data="10 10 'tone_stream://%(10000,0,350,440)' attxfer_callthis 30000 *"/> <action application="execute_extension" data="attended_xfer XML callsdirect"/> </condition> </extension> <extension name="attended_xfer"> <condition field="destination_number" expression="^attended_xfer$"/> <condition field="${attxfer_callthis}" expression="^(\d+)$"> <action application="set" data="continue_on_fail=true"/> <action application="set" data="origination_cancel_key=#"/> <action application="att_xfer" data="sofia/gateway/onesource/${attxfer_callthis}"/> <anti-action application="eval" data="cancel transfer"/> </condition> </extension> On Thu, Apr 21, 2011 at 7:06 AM, Brian West <brian@freeswitch.org> wrote:
There is an example of using this in the default config in features.xml
/b
On Apr 20, 2011, at 9:13 PM, elijah wrote:
Ok, here's the log: http://pastebin.freeswitch.org/16144 <http://pastebin.freeswitch.org/16144>Any input would be great - I'm not seeing the condition that is causing 0 to drop the c-leg after an attended bridge.
thanks, elijah
_______________________________________________ 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
So I'm at the limit of my modest capabilities for troubleshooting this further. There is a workaround I am thinking of by which the documented 3-way conferencing feature of att-xfer could be simulated using a full-on conference bridge and if this is the end of any suggestions I receive on this thread I will pursue it. I have implemented att-xfer in a manner nearly identical to the online documentation and default config as is practical and within my understanding. I have documented here my configuration and corresponding logs in hope that someone else had encountered a similar problem and could advise me of a solution. Hopefully my experience does not indicate a larger issue within the att-xfer module, but if it does I hope the following documentation is useful. I understand FreeSwitch is an enormous commitment for everyone who has contributed to source and I hope to be in a position to personally contribute in the future whether with my own time or financially. If I can help now to get this thread resolved and prevent someone else from having an implementation issue please let me know. thanks, elijah On Thu, Apr 21, 2011 at 10:15 AM, elijah <elijah@crankenstein.com> wrote:
<action application="bind_meta_app" data="1 b s execute_extension::ax XML callsdirect"/>
<extension name="bind_receiver"> <condition field="destination_number" expression="^ax$"> <action application="answer"/> <action application="read" data="10 10 'tone_stream://%(10000,0,350,440)' attxfer_callthis 30000 *"/> <action application="execute_extension" data="attended_xfer XML callsdirect"/> </condition> </extension>
<extension name="attended_xfer"> <condition field="destination_number" expression="^attended_xfer$"/> <condition field="${attxfer_callthis}" expression="^(\d+)$"> <action application="set" data="continue_on_fail=true"/> <action application="set" data="origination_cancel_key=#"/> <action application="att_xfer" data="sofia/gateway/onesource/${attxfer_callthis}"/> <anti-action application="eval" data="cancel transfer"/> </condition> </extension>
I had the same problem when I was testing attended transfer last year - pressing "0" just hung up the channel. But I was thinking that it is because I messed with some configuration settings, and decided to lower priority on this problem, until I will really need this. Now it looks like it is indeed a general problem. Is anybody on the list have this functionality working? Meaning pressing "0" should convert the attended transfer to the 3-way call as described here: http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_att_xfer Thank you, Vitalie 2011/4/26 elijah <elijah@crankenstein.com>
So I'm at the limit of my modest capabilities for troubleshooting this further. There is a workaround I am thinking of by which the documented 3-way conferencing feature of att-xfer could be simulated using a full-on conference bridge and if this is the end of any suggestions I receive on this thread I will pursue it. I have implemented att-xfer in a manner nearly identical to the online documentation and default config as is practical and within my understanding. I have documented here my configuration and corresponding logs in hope that someone else had encountered a similar problem and could advise me of a solution. Hopefully my experience does not indicate a larger issue within the att-xfer module, but if it does I hope the following documentation is useful.
I understand FreeSwitch is an enormous commitment for everyone who has contributed to source and I hope to be in a position to personally contribute in the future whether with my own time or financially. If I can help now to get this thread resolved and prevent someone else from having an implementation issue please let me know.
thanks, elijah
On Thu, Apr 21, 2011 at 10:15 AM, elijah <elijah@crankenstein.com> wrote:
<action application="bind_meta_app" data="1 b s execute_extension::ax XML callsdirect"/>
<extension name="bind_receiver"> <condition field="destination_number" expression="^ax$"> <action application="answer"/> <action application="read" data="10 10 'tone_stream://%(10000,0,350,440)' attxfer_callthis 30000 *"/> <action application="execute_extension" data="attended_xfer XML callsdirect"/> </condition> </extension>
<extension name="attended_xfer"> <condition field="destination_number" expression="^attended_xfer$"/> <condition field="${attxfer_callthis}" expression="^(\d+)$"> <action application="set" data="continue_on_fail=true"/> <action application="set" data="origination_cancel_key=#"/> <action application="att_xfer" data="sofia/gateway/onesource/${attxfer_callthis}"/> <anti-action application="eval" data="cancel transfer"/> </condition> </extension>
_______________________________________________ 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
Please open a Jira on this and attach all relevent information enable debug logging sofia siptrace global on And if it is reproducable by the default config - outline the flow and make notes in the bug report. Thanks -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/attended-transfer-to-gateway-t... Sent from the freeswitch-users mailing list archive at Nabble.com.
I was able to reproduce it using the latest git with absolutely no changes. So the problem is confirmed. Jira issue was opened: http://jira.freeswitch.org/browse/FS-3275 Thank you, Vitalie 2011/4/27 Jeff Lenk <jeff@jefflenk.com>
Please open a Jira on this and attach all relevent information
enable debug logging sofia siptrace global on
And if it is reproducable by the default config - outline the flow and make notes in the bug report.
Thanks
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/attended-transfer-to-gateway-t... Sent from the freeswitch-users mailing list archive at Nabble.com.
_______________________________________________ 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 (5)
-
Brian West
-
elijah
-
Jeff Lenk
-
Michael Collins
-
Vitalie Colosov