After a little testing it seems that the problem is related to calling "mf_process_maxfwd_header()" more than once before the call is routed. So the function is dealing with the sip message as it came in instead of the in-memory copy (where the header has already been added) Perhaps it would be useful if the "mf_process_maxfwd_header()" was able to work with the in-memory copy of a sip message. For people who are doing dynamic call forwarding it is useful to have this feature to catch forwarding loops for local users Tests Done: 1. create a simple config with only several maxfwd lines, a t_relay() and a break; -- if ( !mf_process_maxfwd_header("10") ) { if ( method != "ACK" ) { sl_send_reply("483", "Too many hops"); } log(1, "Message Max-Forwards == 0"); break; } if ( !mf_process_maxfwd_header("10") ) { if ( method != "ACK" ) { sl_send_reply("483", "Too many hops"); } log(1, "Message Max-Forwards == 0"); break; } if ( !mf_process_maxfwd_header("10") ) { if ( method != "ACK" ) { sl_send_reply("483", "Too many hops"); } log(1, "Message Max-Forwards == 0"); break; } if ( !mf_process_maxfwd_header("10") ) { if ( method != "ACK" ) { sl_send_reply("483", "Too many hops"); } log(1, "Message Max-Forwards == 0"); break; } t_relay(); break; -- reticent wrote: