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

[Joegen E. Baclor]

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