[Freeswitch-dev] Bridge dialplan to sipx IVR services problem

[Joegen E. Baclor]

That is actually what's being done now and the problem i am trying to 
solve.  calling deflect in the IVR app will let the bridged call handle 
the REFER.  I need the bridge call to send the REFER in behalf of the 
IVR.  Thus, the IVR needs to know the UUID of the bridge so that it 
could instruct it to send a REFER via uuid_deflect.


On Thursday, 21 October, 2010 08:21 PM, Peter Olsson wrote:
> Just call "deflect" in dialplan, with new destination as parameter (sip:xxx at domain.com)
>
> /Peter
>
>
> -----Ursprungligt meddelande-----
> Från: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] För Joegen E. Baclor
> Skickat: den 21 oktober 2010 14:12
> Till: freeswitch-dev at lists.freeswitch.org
> Ämne: Re: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem
>
> I just saw uuid_deflect in the API reference so i guess this is
> doable.   Is there a means to send the UUID of the bridged call as a uri
> parameter by simply using the XML dialplan?  If not I guess I have to
> create a new socket app just the do the bridging.
>
>
> On Thursday, 21 October, 2010 10:54 AM, Joegen E. Baclor wrote:
>    
>> Hi Anthony sorry for being vague.  The call flow i am experimenting on
>> looks like this
>>
>> 1.  UA1 ->    sipXproxy ->   [FS (bridged-dial-plan)] ->   [FS
>> (auto-attendant-socket dial-plan)]
>> 2.  [FS (auto-attendant-socket dial-plan]) sends REFER to [FS
>> (bridged-dial-plan)]
>> 3.  B-Leg of [FS (bridged-dial-plan)] consumes REFER and sends INVITE
>> to  Refer-to URI via sipXproxy
>>
>> The way sipX does this right now is REFER is actually processed by UA1.
>> Having [FS (bridged-dial-plan)] breaks this.
>>
>> I have reason to believe that the ultimate answer to my previous
>> question would be a no.  Replicating authentication credentials would be
>> costly as well as create a security hole since any UA which has a valid
>> extension in the from URI can now make calls through the AA without
>> being challenged since FS assumes authentication.
>>
>> I am thinking that we could still make the old behavior a possibility if
>> there is a way to intsruct A Leg of the bridge call perform the REFER
>> instead of the auto-attendant leg sending it.  Is this possible?
>>
>> Thanks for you patience.
>>
>> Joegen
>>
>>
>> On Wednesday, 20 October, 2010 11:07 PM, Anthony Minessale wrote:
>>
>>      
>>> I don't quite get what you are saying but..
>>> Can't you define credentials in FS as noreg gateway and match it up to
>>> the challenge realm?
>>>
>>>
>>> On Tue, Oct 19, 2010 at 11:06 PM, Joegen E. Baclor
>>> <joegen at opensipstack.org>    wrote:
>>>
>>>
>>>        
>>>> Hi,
>>>>
>>>> Following Anthonys advise to configure a bridged dial plan infront of
>>>> sipX socket based apps proves to be a reasonable approach to let
>>>> attended transfer work for our apps.  However, bridged dial plans for
>>>> the auto-attendant has a side effect.  sipX uses blind transfer to
>>>> forward a caller to its intended destination.  sipX proxy would then
>>>> authenticate the user  if it has proper permission to reach the resource
>>>> as it receives to new INVITE as a result of the blind transfer.  Since
>>>> the call is bridged, b-leg will consume the REFER and send its own
>>>> INVITE which doesn't have the notion how to authenticate against sipX.
>>>> My question is is there a way to propagate the REFER to the caller
>>>> instead of being consumed by the bridge?
>>>>
>>>> Thanks for any advise in advance.
>>>>
>>>> Joegen
>>>>
>>>> _______________________________________________
>>>> FreeSWITCH-dev mailing list
>>>> FreeSWITCH-dev at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>>
>>>>          
>>>
>>>
>>>        
>> _______________________________________________
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>>
>>
>>      
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
> !DSPAM:4cc02ff332932087729767!
>
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
>