[Freeswitch-users] Transfer attempt for a previously a replaced call fails

[Joegen E. Baclor]

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 at opensipstack.org <mailto:joegen at 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 at opensipstack.org <mailto:joegen at 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 at lists.freeswitch.org
>>         <mailto:FreeSWITCH-users at 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 at lists.freeswitch.org  <mailto:FreeSWITCH-users at lists.freeswitch.org>
>>     http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>     UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>     http://www.freeswitch.org
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110406/bcf2cbc2/attachment-0001.html