Application redirect
Hi there, 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? Thanks in advance. Pablo
2011/4/1 Pablo Hernan Saro <pablosaro@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@aliax.net>
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@aliax.net> wrote:
2011/4/1 Pablo Hernan Saro <pablosaro@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@aliax.net>
participants (2)
-
Iñaki Baz Castillo
-
Pablo Hernan Saro