Forum Discussion

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


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)






    You can also go to which provides a list of all iRules that many in this forum have contributed.



    I hope this helps





  • 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...