No subject

Mon Jul 28 18:09:54 CEST 2008

In one of the weird scenarios, Ive seen openser parallel fork out the Invite(s) to all of the contacts in the 300 rather than building different branches.  (this shouldnt happen)
In another one of the weird scenarios, Ive seen openser fail on the next_branches call in the failure route and push the 408 out instead.  Im 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(, arms failure route 3 and t_relays the message

        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") ||                  
                      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....
                        route(2);   # simple t_relay

                        xlog( "L_ERR", "Failure Route3: Status: Network $T_reply_code  Ran out of branches for callid $ci" );
                route(2);   # simple t_relay

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 Ive not really given much to go on here, but Im 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.




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

Logged In: YES 
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:

More information about the Devel mailing list