Thank you, Anthony, for your answer. I will write my comments in the
e-mail body.
Anthony Minessale napsal(a):
> 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.
>
Yes, I know it. But I just ask :-)
BTW: Very similar messaging concept is IMO used not only in SIP but in
ISUP (and thus in real telephony world) too.
> If you are trying to redirect the call we have 2 ways
> the redirect application
>
> <action application="redirect" data="sip:user@host"/>
> This will result in a 302 redirect in the case of a sip channel
>
I saw this app. But I want to forward the call, not redirect.
> <action application="deflect" data="sip:user@host"/>
> This will result in a REFER to the specified uri
>
REFER is IMO used for replacing of one leg of call with another one
(RFC3515), i.e. for "transfer".
> That is the only 2 ways we support, if you are looking to divert like a
> proxy does
Yes, this is what I have to do, because I need to be "transparent" for
calls come from PSTN and than go back to PSTN too (ISUP->SIP->ISUP).
> remember we are only a b2bua and do not perform proxy features,
OK. This is big advantage for me, because I need B2BUA :-)
But what I want is possible with B2BUA. Even with Asterisk, but only
with very ugly hacks I hope I am avoid with Freeswitch.
> see
> openser for that.
>
I'm intensive user of OpenSER. In my current setup it is used as
loadbalancer, registrar, presence server etc. But I realy need B2BUA and
ability to manipulate with media (with much more sophisticated way than
SEMS does).
Thanks again for your replay, regards