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

Michael Collins msc at freeswitch.org
Tue Apr 5 23:09:46 MSD 2011


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
>>
>
>
> _______________________________________________
> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110405/5d4a72f8/attachment-0001.html 


More information about the FreeSWITCH-users mailing list