You can also try this:
<extension name="Eeee">
<condition field="destination_number" expression="^(23)$">
<action application="set" data="continue_on_fail=true"/>
<action application="bridge" data="sofia/default/$1%$${domain}"/>
<action application="respond" data="181 Call is being forwarded"/>
<action application="export" data="[EMAIL PROTECTED]
{domain};reason=unavailable"/>
<!-- Since we are a B2BUA this just sends the call back into the
dialplan which would be the same as bridge sofia/default/22%$${domain}
-->
<action application="transfer" data="22"/>
</condition>
</extension>
/b
On Apr 6, 2008, at 4:03 PM, Anthony Minessale wrote:
> The transfer app sends the same call to some other extension at some
> other dialplan within the switch.
> We are not a sip specific switch so we have to abstract many concepts.
>
> If you are trying to redirect the call we have 2 ways
> the redirect application
>
> <action application="redirect" data="sip:[EMAIL PROTECTED]"/>
> This will result in a 302 redirect in the case of a sip channel
>
> <action application="deflect" data="sip:[EMAIL PROTECTED]"/>
> This will result in a REFER to the specified uri
>
> That is the only 2 ways we support, if you are looking to divert
> like a proxy does
> remember we are only a b2bua and do not perform proxy features, see
> openser for that.
>
>
>
> On Sun, Apr 6, 2008 at 2:13 PM, kokoska rokoska <[EMAIL PROTECTED]
> > wrote:
>
> Hi all at third today :-)
>
> I'm trying to make call-forward (on all failures, but it is not
> relevant, I think) but don't know how...
> I used "transfer" application but it didn't work like i expected.
>
> The scenario was as follows:
>
> Really simple dialplan
> <extension name="Eeee">
> <condition field="destination_number" expression="^(23)$">
> <action application="set" data="continue_on_fail=true"/>
> <action application="bridge" data="sofia/default/$1%$${domain}"/>
> <action application="transfer" data="22"/>
> </condition>
> </extension>
>
> And than user 21 calls number 23 which is not registered. Call
> succesfully rings on user 22 but:
> 1. There is no "181 Call is being forwarded" sent.
> 2. INVITE to user 22 lacks "Diversion" header.
> If someone interested I have full pcap dump.
>
> Could someone point me to right solution how to properly implement
> call
> forwarding?
> I mean 181 send back, and INVITE with Diversion header with proper
> forwarding reason and forward counter. When I looked at
> Channel_Variables I didn't find anything suitable...
>
> Any suggestion is really appreciated :-)
>
> Best regards,
>
> kokoska.rokoska
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>
> AIM: anthm
> MSN:[EMAIL PROTECTED]
> GTALK/JABBER/PAYPAL:[EMAIL PROTECTED]
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:[EMAIL PROTECTED]
> iax:[EMAIL PROTECTED]/888
> googletalk:[EMAIL PROTECTED]
> pstn:213-799-1400 _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev@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@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
