Good morning/afternoon/evening! I'm trying to accomplish two things.
* First, I'd like to try sending a call from our B2BUA through Kamailio to one of our SIP peers, but in the event that the peer is unreachable, try the same call across an alternate peer. I'm currently trying something in our routing block like this.
if(!t_relay("udp:1.1.1.1:5060","0x2")) { if(!t_relay("udp:2.2.2.2:5060")) { xlog("L_INFO", "Could not complete"); } }
I've also been trying to put together something similar using t_on_failure(#) and a failure_route[#] block to say "if the first t_relay fails, try this instead". In both instances, when fr_timer elapses because the first peer hasn't responded to an INVITE, I can't stop Kamailio from throwing a "SIP/2.0 408 Request Timeout" back to the B2BUA.
I have tried setting the flag on t_relay to keep quiet in the event of a forward failure, and instead use something like sl_send_reply("181", "Call Is Being Forwarded") to say to the agent "hold on, we're still trying". I can't seem to find the syntax to make any of that work. The 408 still keeps getting delivered (in spite of the flag on t_relay) to our server, which causes it to stop trying to deliver the call through Kamailio.
* The second thing I'd like is that if the first two peers are unavailable, the request is rewritten to go across a third peer as a PSTN call. (eg: a call tries to reach 101@1.1.1.1 fails, then 101@2.2.2.2 fails, so then 2015551234@3.3.3.3 is tried). This requires rewriting the username field of the request URI, but I'm not sure how to do that without confusing the originating server.
Could anyone help with the config syntax to resolve either of those two problems? Thank you very much!
Hi Tyler!
This is the wrong logic!
t_relay fails only if the proxy fails to send the message (e.g. internal problems) - not if the client is not reachable. For this you ahve to use a failure route:
in normal route: t_on_failure("1"); t_relay("udp:1.1.1.1:5060","0x2"); exit;
failure_route[1] { t_relay("udp:2.2.2.2:5060"); exit(); }
regards klaus
Tyler Brauer schrieb:
Good morning/afternoon/evening! I'm trying to accomplish two things.
- First, I'd like to try sending a call from our B2BUA through
Kamailio to one of our SIP peers, but in the event that the peer is unreachable, try the same call across an alternate peer. I'm currently trying something in our routing block like this.
if(!t_relay("udp:1.1.1.1:5060","0x2")) { if(!t_relay("udp:2.2.2.2:5060")) { xlog("L_INFO", "Could not complete"); } }
I've also been trying to put together something similar using t_on_failure(#) and a failure_route[#] block to say "if the first t_relay fails, try this instead". In both instances, when fr_timer elapses because the first peer hasn't responded to an INVITE, I can't stop Kamailio from throwing a "SIP/2.0 408 Request Timeout" back to the B2BUA.
I have tried setting the flag on t_relay to keep quiet in the event of a forward failure, and instead use something like sl_send_reply("181", "Call Is Being Forwarded") to say to the agent "hold on, we're still trying". I can't seem to find the syntax to make any of that work. The 408 still keeps getting delivered (in spite of the flag on t_relay) to our server, which causes it to stop trying to deliver the call through Kamailio.
- The second thing I'd like is that if the first two peers are
unavailable, the request is rewritten to go across a third peer as a PSTN call. (eg: a call tries to reach 101@1.1.1.1 fails, then 101@2.2.2.2 fails, so then 2015551234@3.3.3.3 is tried). This requires rewriting the username field of the request URI, but I'm not sure how to do that without confusing the originating server.
Could anyone help with the config syntax to resolve either of those two problems? Thank you very much!
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Viernes, 28 de Noviembre de 2008, Tyler Brauer escribió:
if(!t_relay("udp:1.1.1.1:5060","0x2")) { if(!t_relay("udp:2.2.2.2:5060")) { xlog("L_INFO", "Could not complete"); } }
This is not how Kamailio works. Please refer to failure_route documentation to understand how to handle it.