[OpenSER-Devel] [ openser-Bugs-1983626 ] Openser Memory Corruption

[SourceForge.net]

Bugs item #1983626, was opened at 2008-06-03 10:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1983626&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Scott Mullen (smullen27)
Assigned to: Nobody/Anonymous (nobody)
Summary: Openser Memory Corruption

Initial Comment:
We are running an instance of openser 1.3.0 in our network and are seeing weird things happening to the destination set’s of calls at times.
I have not been able to reproduce this problem in a lab, however it does seem to happen enough in our network to cause concerns.

Since I am not able to provide a specific call scenario, I’ll do my best to document the main scenario’s were I’ve seen this happen.
For all scenarios we set the following two timers:
Fr_timer = 2
Fr_inv_timer = 120

Scenario 1:
Openser receives an Invite.  Openser pushes this invite to a redirect server that returns a 300 Mulitiple Choices with a single contact header containing anywhere between 1 and 7 contacts weighted by q value. This q value is unique for each contact and has a value between 0 and 1.0 down to the thousandths decimal place.  
example:

SIP/2.0 300 Multiple choices.
Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK1a1c.279e4a91.0,SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK62810cb4;rport=5060.
From: "DOC" <sip:+18668123456 at 3.3.3.3>;tag=as7e6accf1.
To: <sip:+18885551212 at 1.1.1.1>.
Call-ID: 6de77314108c97eb78835cea7b453597 at 3.3.3.3.
CSeq: 102 INVITE.
Contact: <sip:+18885551212 at 1.1.1.2:5060;transport=udp>;q=0.972;rate=0.0087,<sip:+18885551212 at 1.1.1.3:5060;transport=udp>;q=0.932;rate=0.0214,<sip:+18885551212 at 1.1.1.4:5060;transport=udp>;q=0.931;rate=0.0217,<sip:+18885551212 at 1.1.1.5:5060;transport=udp>;q=0.928;rate=0.0227,<sip:+18885551212 at 1.1.1.6:5060;transport=udp>;q=0.01;rate=0.0087,<sip:+18885551212 at 1.1.1.7:5060;transport=udp>;q=0.0090;rate=0.0227.
Content-Length: 0.


We catch this 300 in a failure route with the following code:
        if (t_check_status("300") || t_check_status("302"))
        {
                get_redirects("*");
                serialize_branches(0);
                next_branches();
                t_on_branch("1");
                t_on_failure("2");
                t_relay();
                return;
        }

Branch_Route[1] does nothing more than building an RPID Header and PAI Header and sticks them in the outgoing Invite.

Under normal circumstances the call is then sent to the contact with the highest Q value.  If we do not receive a 100 or any other provisional within 2 seconds, openser receives a 408 generated internally and we catch this in failure_route[2] (from above).  

failure_route[2]
{
        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 Route2: Status: Local $T_reply_code  Ran out of branches for callid $ci" );
                      }
                      else
                      {
                        xlog( "L_ERR", "Failure Route2: 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;
        }
}