[Serusers] Re: route loop quandary

Daniel Poulsen dpoulsen at gmail.com
Thu Aug 4 17:50:04 CEST 2005


I am not necessarily looking for somebody to tell me how to fix my code, 
more for somebody to suggest how it might be done or how they have done it.

Thoughts:

1. Is there a way for one branch to check the status of another?

2. Do you think it is possible with AVP to lookup from original ruri and 
then append_brach only if lookup suceeds? 


On 8/3/05, Daniel Poulsen <dpoulsen at gmail.com> wrote:
> 
> 
> I am having a problem with calls that are parallel forked. The problem 
> happens when a call comes in, gets forked using multiple aliases and one UA 
> is unavailable. The question is, how do I handle the offline call leg?
> 
> I can't do if (!lookup("location")) { break; (or sl_send_reply("404") } 
> because then the whole call dies since each branch of the call uses the same 
> callid.
> 
> If I t_relay them both, then the fork works but I the offline leg gets 
> repeatedly relayed unltil I get a 483 "Too many hops". This scenario would 
> be OK [althought certainly not ideal], except it does not allow me to add a 
> condition to hunt to the next number upon a failed lookup("location"). If I 
> do, the online UA will ring once and the offline UA will get routed 
> immediately to voicemail which picks up after just one ring.
> 
> How are other handling these problems? I think the answer lies in letting 
> failure_route handle everything, but I don't know how to get that to work 
> because if I don't handle the offline users in the (!lookup("location"), I 
> end up with routing loops and eventualluy a 483. Anybody that has no online 
> contacts whatsoever never makes it to failure_route (where the forward to VM 
> is handled).
> 
> Below is my ser.cfg. I've been playing around with things like if 
> (isflagset(6)) { route(x) } but I still need some way to handle the failed 
> portion of the fork. Is there a way to "null route" the failed portion or 
> something?
> 
> 
> 
> route {
> 
> /* Registration and other logic snipped for brevity */
> 
> # Translate local address according to aliases table
> xlog("L_INFO", "%ci: Preparing to look up alias for %ru\n");
> if(lookup("aliases")) {
> xlog("L_NOTICE", "%ci: alias lookup changed uri to %ru\n");
> 
> if (!(uri==myself)) {
> xlog("L_NOTICE", "%ci: Outbound aliases %ru\n");
> route(4);
> break;
> };
> 
> };
> 
> 
> if ( (uri=~"^sip:411 at .*") | (uri=~"^sip:911 at .*") | 
> (uri=~"^sip:011[0-9]+ at .*") | (uri=~"^sip:1[0-9]{10}@.*") ) {
> route(3); # 3: PSTN with authentication
> break;
> };
> 
> # Anything left is a local call.
> 
> xlog("L_INFO", "%ci: Preparing to look up location for %ru\n");
> if (!lookup("location")) {
> xlog("L_NOTICE", "%ci: no location for %ru\n");
> setflag(5);
> } else {
> # Had a sucessful lookup
> setflag(6);
> };
> 
> route(4);
> 
> }
> 
> 
> 
> route[4] {
> # If an invitation, we want to hunt on failure
> 
> if(method == "INVITE") {
> t_on_failure("1"); # first hunt
> };
> 
> append_hf("P-hint: relay\r\n");
> 
> xlog("L_NOTICE", "%ci: r4: t_relay %ru\n");
> if (!t_relay()) {
> xlog("L_NOTICE", "%ci: %ru r4: Relay Failed\n");
> sl_reply_error();
> break;
> };
> 
> }
> 
> 
> failure_route[1] { revert_uri(); route(7); } ### Handle hunt sequences.
> 
> 
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050804/e45dc73f/attachment.htm>


More information about the sr-users mailing list