[Freeswitch-users] Transfer calls to internal user VS. dialing out

Noah Silverman noah at allresearch.com
Sun Sep 21 18:05:49 EDT 2008


Hi,

I have a VERY simple FS setup.

1) Calls come in and go out via Vitelity.  (I just route to their IP  
address, don't even need a gateway.)

2) I have users registered remotely with anything from a single SIP  
phone to an asterisk box.

3) Basically, I am a "pass through" of calls to and from Vitelity.

I have my user registering their phones on my "default" context.
Calls that come back in on a DID route through the public context.

Outgoing calls work perfectly.

My problem is with incoming calls.  My users register with their DID  
as their username.
So, when a call comes in on "323-555-1212", I want to route it to the  
device registered with the username of "3235551212".
With my current setup, it is getting routed over to the default  
context, and then FS is attempting to DIAL THE DID BACK OUT.  which  
creates a nasty loop.

HOW CAN I TELL FS TO ROUTE A CALL TO A REGISTERED USER AS OPPOSED TO  
DIALING OUT???

My guess is that's its an adjustment to the "transfer" application in  
my public context???

Thanks,

-Noah


-----------------------------------------------------------------------------------------------------


I can call out just fine using the following in my dialplan:

<context name="default">
	<extension name="Vitelity">
	    <condition field="destination_number" expression="^(1{0,1}\d{10}) 
$">
		<action application="set"  
data="effective_caller_id_number=12223334444"/>
		<!--<action application="bridge" data="sofia/gateway/vitelity/$1"/>-->
		<action application="bridge" data="sofia/external/$1 at outbound1.vitelity.net 
"/>
	     </condition>
	    </extension>
</context>

<context name="public">
	 <extension name="inbound">
	      <condition field="destination_number"  
expression="^(3235551212)$">
		<action application="transfer" data="$1 XML default"/>
	      </condition>
	    </extension>
</context>






More information about the Freeswitch-users mailing list