[Freeswitch-users] Application redirect

[Pablo Hernan Saro]

Thanks for your answer Iñaki. You're right, I was messing it up... Handling
SIP trunks with a proxy between providers and my FS boxes is the best way to
accomplish that.

On Fri, Apr 1, 2011 at 6:43 AM, Iñaki Baz Castillo <ibc at aliax.net> wrote:

> 2011/4/1 Pablo Hernan Saro <pablosaro at gmail.com>:
> > As far as I understood from the documentation, when action application
> > redirect is invoked, the REFER method is implemented. Recently I signed
> up
> > for a VoIP service and realized that the provider only supports
> redirection
> > by implementing the UPDATE method. I want to redirect incoming calls
> > requesting specific DIDs to other FS box in a different network (not
> behind
> > the FS receiving the original INVITE). Perform the redirection by
> answering
> > the call and bridging it to the other FS box will result in resource
> wasting
> > and probably call quality degradation (and actually it will be transfer
> not
> > redirect). So, is there any way to use UPDATE instead of REFER to
> accomplish
> > redirection for requests received through specific gateway?
>
> UPDATE for a redirection? that's not possible, UPDATE is just use to
> allow modifyng an SDP during an early-dialog (but also works for
> establixhed dialogs similar to a re-INVITE).
>
> Usually SIP providers don't allow neither receiving a 302 from a
> client (to make a redirection) or a REFER, they are SIP trunk
> providers, not a PBX. Is your responsability to handle redirections in
> your platfform so the provider gets not involved at all.
>
> A good solution could be setting a SIP proxy (i.e. Kamailio) between
> the provider and your FS boxes so it can route incoming calls to the
> appropriate FS (or based on load-balancing/failover fashion) and could
> also receive a 302 from the first selected FS and convert it into a
> new INVITE for the second FS.
>
> Don't disturb a SIP trunk provider with your internal logic stuff, never.
>
> --
> Iñaki Baz Castillo
> <ibc at aliax.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110401/7a56783e/attachment.html