Forum Discussion

Rich_Hill_11043's avatar
Rich_Hill_11043
Icon for Nimbostratus rankNimbostratus
Jun 24, 2011

SIP 480 RESELECT

I'm load balancing UDP SIP traffic across 4 SIP proxies, using CALL-ID for persistence. When we exceed a certain number of calls per second or a certain number of sessions, the SIP proxy responds with a response code of 480.

 

 

I'm trying to write an iRule to respond to the receipt of the 480 error code by performing a reselect from the same pool.

 

 

My problem is that the response code comes as part of the SIP_RESPONSE event, but the LB::reselect isn't valid in that event context.

 

 

Any help would be greatly appreciated!

 

3 Replies

  • Hi Rich,

     

    Have you thought of approaching this a bit differently. Have the F5 more responsible in maintaining the connection based on calls per second or numbers of session - such that the SIP proxies wouldn't have to send a 480 error code.

     

     

    There are some iRules that were already made for some kind of rate limiting connections

     

     

    Here are some that you can possibly leverage (NOTE: Some may require v10.x)

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/virtual_server_connection_rate_limit_with_tables.html

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/LimitConnectionsFromClient.html

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/Version_9_x_Session_Limiting_iRule.html

     

     

    You can also go to http://devcentral.f5.com/wiki/Default.aspx/iRules.HomePage which provides a list of all iRules that many in this forum have contributed.

     

     

    I hope this helps

     

     

    Bhattman

     

  • I have a call per second limiting rule in place already. Rate limiting isn't the problem, it's responding to error codes from the SIP proxies. I want to be able to receive a 480 error code from a SIP proxy and then respond to that by selecting a different SIP proxy for that call.

     

     

    It's a very specific problem, but because of our architecture it's something I have to be able to do.

     

     

    Also, I have to mention that we're doing SIP over UDP, so a lot of the connection-based rules aren't going to work, since they are based on TCP connections.

     

     

    The SIP Proxies are set with a hard connection limit and will send back 480 error codes if they receive connection requests that will take them over that.

     

  • Hi Rich,

     

     

    I'm not sure it's possible to select a new pool member based on the SIP response code. LB::reselect is fairly limited in terms of the events you can call it from. I haven't worked with SIP much though, so maybe someone else has a clever idea...

     

     

    Aaron