Transfer attempt for a previously a replaced call fails
Hi List, I have a scenario where a bridged call has been replaced due to a consultative transfer. This works pretty well and audio is bidirectional. I have the original uuid of the call in a var somewhere. The trouble begins when I uuid_deflect the bridged call once again to attempt another transfer. Sofia disconnects the channel. I am using the original uuid of the call (uuid prior to replaces). Is this the right way of doing it? Joegen
What do you see on the console when you try this? A console debug log with siptrace would go a long way toward figuring out what is happening. -MC On Mon, Apr 4, 2011 at 9:27 PM, Joegen E. Baclor <joegen@opensipstack.org>wrote:
Hi List,
I have a scenario where a bridged call has been replaced due to a consultative transfer. This works pretty well and audio is bidirectional. I have the original uuid of the call in a var somewhere. The trouble begins when I uuid_deflect the bridged call once again to attempt another transfer. Sofia disconnects the channel. I am using the original uuid of the call (uuid prior to replaces). Is this the right way of doing it?
Joegen
_______________________________________________ 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
Hi Michael, I have pasted both working and none working logs on pastebin. FreeSWITCH Version 1.0.7 (hacked-20110326T123355Z) working: http://pastebin.freeswitch.org/16008 not working: http://pastebin.freeswitch.org/16009 The call flow for the working call is UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) FSIVRApp knows the uuid of the bridge call. Pressing # on the IVR results to a uuid_deflect on the bridged channel. This works and call successfully transfers to the new destination. The call flow for the none working call is 1. UA1 -> UA2 is in conversation 2. UA1 puts UA2 on hold -- start of FS interaction here -- 3. UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) (on line 2) 4. UA1 sends REFER (replacing its call with UA2) to FSBridgeDialPlan. 5. Flow is now UA2 -> ([REPLACED]FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) 6. UA2 presses #. 7. IVRApp performs uuid_deflect on FSBridgeDialPlan. 8. FSBridgeDialPlan drops call (no REFER is done) Thanks for your help. Joegen On 04/05/2011 12:35 PM, Michael Collins wrote:
What do you see on the console when you try this? A console debug log with siptrace would go a long way toward figuring out what is happening.
-MC
On Mon, Apr 4, 2011 at 9:27 PM, Joegen E. Baclor <joegen@opensipstack.org <mailto:joegen@opensipstack.org>> wrote:
Hi List,
I have a scenario where a bridged call has been replaced due to a consultative transfer. This works pretty well and audio is bidirectional. I have the original uuid of the call in a var somewhere. The trouble begins when I uuid_deflect the bridged call once again to attempt another transfer. Sofia disconnects the channel. I am using the original uuid of the call (uuid prior to replaces). Is this the right way of doing it?
Joegen
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
I'll have to defer to those more experienced than I in such matters. However, I can offer two tips: #1 - turn off the crazy sofia debugging - it's just noise. All you need to do to enable SIP trace is "sofia global siptrace on" #2 - when you pastebin the console output use the FreeSWITCH log syntax highlighting - it makes it *much* easier to see what's going on. -MC On Mon, Apr 4, 2011 at 10:51 PM, Joegen E. Baclor <joegen@opensipstack.org>wrote:
Hi Michael,
I have pasted both working and none working logs on pastebin.
FreeSWITCH Version 1.0.7 (hacked-20110326T123355Z) working: http://pastebin.freeswitch.org/16008 not working: http://pastebin.freeswitch.org/16009
The call flow for the working call is UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) FSIVRApp knows the uuid of the bridge call. Pressing # on the IVR results to a uuid_deflect on the bridged channel. This works and call successfully transfers to the new destination.
The call flow for the none working call is
1. UA1 -> UA2 is in conversation 2. UA1 puts UA2 on hold
-- start of FS interaction here --
3. UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) (on line 2) 4. UA1 sends REFER (replacing its call with UA2) to FSBridgeDialPlan. 5. Flow is now UA2 -> ([REPLACED]FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) 6. UA2 presses #. 7. IVRApp performs uuid_deflect on FSBridgeDialPlan. 8. FSBridgeDialPlan drops call (no REFER is done)
Thanks for your help.
Joegen
On 04/05/2011 12:35 PM, Michael Collins wrote:
What do you see on the console when you try this? A console debug log with siptrace would go a long way toward figuring out what is happening.
-MC
On Mon, Apr 4, 2011 at 9:27 PM, Joegen E. Baclor <joegen@opensipstack.org>wrote:
Hi List,
I have a scenario where a bridged call has been replaced due to a consultative transfer. This works pretty well and audio is bidirectional. I have the original uuid of the call in a var somewhere. The trouble begins when I uuid_deflect the bridged call once again to attempt another transfer. Sofia disconnects the channel. I am using the original uuid of the call (uuid prior to replaces). Is this the right way of doing it?
Joegen
_______________________________________________ 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 listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
I'll keep that in mind. If more information is needed to get into the bottom of this, I will happily oblige. Thanks for helping. On 04/06/2011 03:09 AM, Michael Collins wrote:
I'll have to defer to those more experienced than I in such matters. However, I can offer two tips:
#1 - turn off the crazy sofia debugging - it's just noise. All you need to do to enable SIP trace is "sofia global siptrace on" #2 - when you pastebin the console output use the FreeSWITCH log syntax highlighting - it makes it *much* easier to see what's going on.
-MC
On Mon, Apr 4, 2011 at 10:51 PM, Joegen E. Baclor <joegen@opensipstack.org <mailto:joegen@opensipstack.org>> wrote:
Hi Michael,
I have pasted both working and none working logs on pastebin.
FreeSWITCH Version 1.0.7 (hacked-20110326T123355Z) working: http://pastebin.freeswitch.org/16008 not working: http://pastebin.freeswitch.org/16009
The call flow for the working call is UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) FSIVRApp knows the uuid of the bridge call. Pressing # on the IVR results to a uuid_deflect on the bridged channel. This works and call successfully transfers to the new destination.
The call flow for the none working call is
1. UA1 -> UA2 is in conversation 2. UA1 puts UA2 on hold
-- start of FS interaction here --
3. UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) (on line 2) 4. UA1 sends REFER (replacing its call with UA2) to FSBridgeDialPlan. 5. Flow is now UA2 -> ([REPLACED]FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) 6. UA2 presses #. 7. IVRApp performs uuid_deflect on FSBridgeDialPlan. 8. FSBridgeDialPlan drops call (no REFER is done)
Thanks for your help.
Joegen
On 04/05/2011 12:35 PM, Michael Collins wrote:
What do you see on the console when you try this? A console debug log with siptrace would go a long way toward figuring out what is happening.
-MC
On Mon, Apr 4, 2011 at 9:27 PM, Joegen E. Baclor <joegen@opensipstack.org <mailto:joegen@opensipstack.org>> wrote:
Hi List,
I have a scenario where a bridged call has been replaced due to a consultative transfer. This works pretty well and audio is bidirectional. I have the original uuid of the call in a var somewhere. The trouble begins when I uuid_deflect the bridged call once again to attempt another transfer. Sofia disconnects the channel. I am using the original uuid of the call (uuid prior to replaces). Is this the right way of doing it?
Joegen
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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 <mailto: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
Just bumping this thread. If I need to provide more info, just let me know. Or if this is a known bug and a fix is due for a future version that is also acceptable. On 04/06/2011 08:02 AM, Joegen E. Baclor wrote:
I'll keep that in mind. If more information is needed to get into the bottom of this, I will happily oblige. Thanks for helping.
On 04/06/2011 03:09 AM, Michael Collins wrote:
I'll have to defer to those more experienced than I in such matters. However, I can offer two tips:
#1 - turn off the crazy sofia debugging - it's just noise. All you need to do to enable SIP trace is "sofia global siptrace on" #2 - when you pastebin the console output use the FreeSWITCH log syntax highlighting - it makes it *much* easier to see what's going on.
-MC
On Mon, Apr 4, 2011 at 10:51 PM, Joegen E. Baclor <joegen@opensipstack.org <mailto:joegen@opensipstack.org>> wrote:
Hi Michael,
I have pasted both working and none working logs on pastebin.
FreeSWITCH Version 1.0.7 (hacked-20110326T123355Z) working: http://pastebin.freeswitch.org/16008 not working: http://pastebin.freeswitch.org/16009
The call flow for the working call is UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) FSIVRApp knows the uuid of the bridge call. Pressing # on the IVR results to a uuid_deflect on the bridged channel. This works and call successfully transfers to the new destination.
The call flow for the none working call is
1. UA1 -> UA2 is in conversation 2. UA1 puts UA2 on hold
-- start of FS interaction here --
3. UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) (on line 2) 4. UA1 sends REFER (replacing its call with UA2) to FSBridgeDialPlan. 5. Flow is now UA2 -> ([REPLACED]FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) 6. UA2 presses #. 7. IVRApp performs uuid_deflect on FSBridgeDialPlan. 8. FSBridgeDialPlan drops call (no REFER is done)
Thanks for your help.
Joegen
On 04/05/2011 12:35 PM, Michael Collins wrote:
What do you see on the console when you try this? A console debug log with siptrace would go a long way toward figuring out what is happening.
-MC
On Mon, Apr 4, 2011 at 9:27 PM, Joegen E. Baclor <joegen@opensipstack.org <mailto:joegen@opensipstack.org>> wrote:
Hi List,
I have a scenario where a bridged call has been replaced due to a consultative transfer. This works pretty well and audio is bidirectional. I have the original uuid of the call in a var somewhere. The trouble begins when I uuid_deflect the bridged call once again to attempt another transfer. Sofia disconnects the channel. I am using the original uuid of the call (uuid prior to replaces). Is this the right way of doing it?
Joegen
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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 <mailto: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
The case where you are saying it doesnt work, the refer is to a call on another box so its doing what we call a nightmare transfer where FS INVITES the remote leg then cross connects them. According to the log as soon as they are bridge one leg of the call seems to be hungup or disconnected. Is this when you press #? On Thu, Apr 7, 2011 at 11:05 AM, Joegen E. Baclor <joegen@opensipstack.org> wrote:
Just bumping this thread. If I need to provide more info, just let me know. Or if this is a known bug and a fix is due for a future version that is also acceptable.
On 04/06/2011 08:02 AM, Joegen E. Baclor wrote:
I'll keep that in mind. If more information is needed to get into the bottom of this, I will happily oblige. Thanks for helping.
On 04/06/2011 03:09 AM, Michael Collins wrote:
I'll have to defer to those more experienced than I in such matters. However, I can offer two tips: #1 - turn off the crazy sofia debugging - it's just noise. All you need to do to enable SIP trace is "sofia global siptrace on" #2 - when you pastebin the console output use the FreeSWITCH log syntax highlighting - it makes it *much* easier to see what's going on. -MC
On Mon, Apr 4, 2011 at 10:51 PM, Joegen E. Baclor <joegen@opensipstack.org> wrote:
Hi Michael,
I have pasted both working and none working logs on pastebin.
FreeSWITCH Version 1.0.7 (hacked-20110326T123355Z) working: http://pastebin.freeswitch.org/16008 not working: http://pastebin.freeswitch.org/16009
The call flow for the working call is UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) FSIVRApp knows the uuid of the bridge call. Pressing # on the IVR results to a uuid_deflect on the bridged channel. This works and call successfully transfers to the new destination.
The call flow for the none working call is
1. UA1 -> UA2 is in conversation 2. UA1 puts UA2 on hold
-- start of FS interaction here --
3. UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) (on line 2) 4. UA1 sends REFER (replacing its call with UA2) to FSBridgeDialPlan. 5. Flow is now UA2 -> ([REPLACED]FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) 6. UA2 presses #. 7. IVRApp performs uuid_deflect on FSBridgeDialPlan. 8. FSBridgeDialPlan drops call (no REFER is done)
Thanks for your help.
Joegen
On 04/05/2011 12:35 PM, Michael Collins wrote:
What do you see on the console when you try this? A console debug log with siptrace would go a long way toward figuring out what is happening. -MC
On Mon, Apr 4, 2011 at 9:27 PM, Joegen E. Baclor <joegen@opensipstack.org> wrote:
Hi List,
I have a scenario where a bridged call has been replaced due to a consultative transfer. This works pretty well and audio is bidirectional. I have the original uuid of the call in a var somewhere. The trouble begins when I uuid_deflect the bridged call once again to attempt another transfer. Sofia disconnects the channel. I am using the original uuid of the call (uuid prior to replaces). Is this the right way of doing it?
Joegen
_______________________________________________ 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
_______________________________________________ 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/ 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
Anthony, Thanks for looking into it. Yes, it is right after I press pound. If you need me to reproduce using a specific setting let me know. I can pastebin the logs required. Let me know if this requires a Jira tracker as well. Joegen On 04/08/2011 05:03 AM, Anthony Minessale wrote:
The case where you are saying it doesnt work, the refer is to a call on another box so its doing what we call a nightmare transfer where FS INVITES the remote leg then cross connects them. According to the log as soon as they are bridge one leg of the call seems to be hungup or disconnected. Is this when you press #?
On Thu, Apr 7, 2011 at 11:05 AM, Joegen E. Baclor <joegen@opensipstack.org> wrote:
Just bumping this thread. If I need to provide more info, just let me know. Or if this is a known bug and a fix is due for a future version that is also acceptable.
On 04/06/2011 08:02 AM, Joegen E. Baclor wrote:
I'll keep that in mind. If more information is needed to get into the bottom of this, I will happily oblige. Thanks for helping.
On 04/06/2011 03:09 AM, Michael Collins wrote:
I'll have to defer to those more experienced than I in such matters. However, I can offer two tips: #1 - turn off the crazy sofia debugging - it's just noise. All you need to do to enable SIP trace is "sofia global siptrace on" #2 - when you pastebin the console output use the FreeSWITCH log syntax highlighting - it makes it *much* easier to see what's going on. -MC
On Mon, Apr 4, 2011 at 10:51 PM, Joegen E. Baclor<joegen@opensipstack.org> wrote:
Hi Michael,
I have pasted both working and none working logs on pastebin.
FreeSWITCH Version 1.0.7 (hacked-20110326T123355Z) working: http://pastebin.freeswitch.org/16008 not working: http://pastebin.freeswitch.org/16009
The call flow for the working call is UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) FSIVRApp knows the uuid of the bridge call. Pressing # on the IVR results to a uuid_deflect on the bridged channel. This works and call successfully transfers to the new destination.
The call flow for the none working call is
1. UA1 -> UA2 is in conversation 2. UA1 puts UA2 on hold
-- start of FS interaction here --
3. UA1 -> (FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) (on line 2) 4. UA1 sends REFER (replacing its call with UA2) to FSBridgeDialPlan. 5. Flow is now UA2 -> ([REPLACED]FSBridgeDialPlan) -> (SIP-Loopback) -> (FSIVRApp) 6. UA2 presses #. 7. IVRApp performs uuid_deflect on FSBridgeDialPlan. 8. FSBridgeDialPlan drops call (no REFER is done)
Thanks for your help.
Joegen
On 04/05/2011 12:35 PM, Michael Collins wrote:
What do you see on the console when you try this? A console debug log with siptrace would go a long way toward figuring out what is happening. -MC
On Mon, Apr 4, 2011 at 9:27 PM, Joegen E. Baclor<joegen@opensipstack.org> wrote:
Hi List,
I have a scenario where a bridged call has been replaced due to a consultative transfer. This works pretty well and audio is bidirectional. I have the original uuid of the call in a var somewhere. The trouble begins when I uuid_deflect the bridged call once again to attempt another transfer. Sofia disconnects the channel. I am using the original uuid of the call (uuid prior to replaces). Is this the right way of doing it?
Joegen
_______________________________________________ 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 (3)
-
Anthony Minessale
-
Joegen E. Baclor
-
Michael Collins