No subject

In one of the “weird” scenarios, I’ve seen openser parallel fork out the Invite(s) to all of the contacts in the 300 rather than building different branches.  (this shouldn’t happen)
In another one of the “weird” scenarios, I’ve seen openser fail on the next_branches call in the failure route and push the 408 out instead.  I’m able to pull a trace for these calls and can see there multiple contacts in the 300, so I know there should still be additional branches...

Scenario 2:
Openser receives an Invite.  Openser calls rewritehostport(“1.1.1.1:5060”), arms failure route 3 and t_relays the message

failure_route[3]
{
        if (t_check_status("503") ||
            t_check_status("480") ||
            t_check_status("502") ||
            t_check_status("504") ||
            t_check_status("403") ||
            t_check_status("404") ||
            t_check_status("484") ||
            t_check_status("488") ||                 
            t_check_status("500") ||
            t_check_status("400") ||
            t_check_status("606") ||                  
            t_check_status("408"))
        {
                if(!next_branches())
                {
                      if((t_check_status("408")) && (t_local_replied("last")))
                      { 
                        xlog( "L_ERR", "Failure Route3: Status: Local $T_reply_code  Ran out of branches for callid $ci" );

                        # One last try for this call....
                        rewritehostport("3.4.5.6:5060");
                        append_branch();
                        t_on_failure("0");
                        t_on_branch("0");
                        route(2);   # simple t_relay
                        return;

                      }
                      else
                      {
                        xlog( "L_ERR", "Failure Route3: Status: Network $T_reply_code  Ran out of branches for callid $ci" );
                      }
                      return;
                }
                else
                {
                      t_on_branch("1");
                      t_on_failure("2");
                }
                route(2);   # simple t_relay
                return;
        }
}

Openser does not receive any provisional responses within 2 seconds and therefore falls into a failure route when the fr_timer expires.  This failure route calls next_branches (which should fail).  We then check if it was an internally generated 408, we build one last branch to try the call a last time.....However sometimes this comes up with additional branches and parallel forks out the invite to multiple Ips.  In this scenario I know there are no additional branches, so not sure how this is happening either.



Most of these problems seem to be related to a 300 with multiple routes in the contact and the fr_timer expiring.  I realize that I’ve not really given much to go on here, but I’m willing to help out in any way I can...even adding some additional debug into openser core and the TM module and running for a while with traffic.

Is it possible to describe or point me to documentation on the following:
    1.  What sort of information is stored in the fr_timer structure?  (A pointer referencing ???)  What files and functions should I be looking at in the TM module?
    2.  How are the destination sets stored in the above scenarios?  It looks to me like sometimes openser stores the destination set as an array, but some of the documentation mentions that serialize_branches stores the destination set in AVP(s).  Can you again point me to files and functions that would help in analyzing this code.


Thanks

Scott

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-12 12:20

Message:
Found that not checking for canceled transaction in failure route will
cause a lot of this.  The failure route will add the branch but the branch
route generates a 500 internal server error.  Next thing you know the
contacts for the failed call are showing up as parallel branches in the
next call to hit the failure route.

----------------------------------------------------------------------

Comment By: Daniel-Constantin Mierla (miconda)
Date: 2008-08-06 08:24

Message:
Logged In: YES 
user_id=1246013
Originator: NO

Renamed to express better the problem, as I haven't really seen a relation
with memory corruption. Please correct me if I am wrong.

Your scenario implies the uac_redirect module as well. I am going to ask
for your assistance in troubleshooting this issue after the new release. I
need to make a replica in my testbed to be able to debug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1983626&group_id=139143