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.<br><br><div class="gmail_quote">On Fri, Apr 1, 2011 at 6:43 AM, Iņaki Baz Castillo <span dir="ltr"><<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2011/4/1 Pablo Hernan Saro <<a href="mailto:pablosaro@gmail.com">pablosaro@gmail.com</a>>:<br>
<div><div></div><div class="h5">> As far as I understood from the documentation, when action application<br>
> redirect is invoked, the REFER method is implemented. Recently I signed up<br>
> for a VoIP service and realized that the provider only supports redirection<br>
> by implementing the UPDATE method. I want to redirect incoming calls<br>
> requesting specific DIDs to other FS box in a different network (not behind<br>
> the FS receiving the original INVITE). Perform the redirection by answering<br>
> the call and bridging it to the other FS box will result in resource wasting<br>
> and probably call quality degradation (and actually it will be transfer not<br>
> redirect). So, is there any way to use UPDATE instead of REFER to accomplish<br>
> redirection for requests received through specific gateway?<br>
<br>
</div></div>UPDATE for a redirection? that's not possible, UPDATE is just use to<br>
allow modifyng an SDP during an early-dialog (but also works for<br>
establixhed dialogs similar to a re-INVITE).<br>
<br>
Usually SIP providers don't allow neither receiving a 302 from a<br>
client (to make a redirection) or a REFER, they are SIP trunk<br>
providers, not a PBX. Is your responsability to handle redirections in<br>
your platfform so the provider gets not involved at all.<br>
<br>
A good solution could be setting a SIP proxy (i.e. Kamailio) between<br>
the provider and your FS boxes so it can route incoming calls to the<br>
appropriate FS (or based on load-balancing/failover fashion) and could<br>
also receive a 302 from the first selected FS and convert it into a<br>
new INVITE for the second FS.<br>
<br>
Don't disturb a SIP trunk provider with your internal logic stuff, never.<br>
<font color="#888888"><br>
--<br>
Iņaki Baz Castillo<br>
<<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>><br>
</font></blockquote></div><br>