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.
Submitted By: reticent (unspin)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: maxfwd module - internal corruption
The issue occurs when calling 'mf_process_maxfwd_header' or 'is_maxfwd_lt' script functions more than once within a single script execution
The second occurrence always returns as if the max forward header value has reached zero due to an issue with the temporary value (max forwards count) stored by the module being overwritten with zero during an int to string conversion
We are calling it more than once during a single execution to detect and trap possible call forwarding loops between accounts
Peter Baer (pbaer at galaxytelecom dot net)
Tavis Paquette (tavis at galaxytelecom dot net)
I do not see how this patch solves something - you have the mf header body
and trim it in a foo variable which is not used - it returns the value
stored into "parsed" value.....
maybe something is missing me :)..
We've found a rather serious problem (seg fault) but we havn't tracked it
We suspect the issue is related to maxfwd overwriting the pointer to the
max-forward value in the sip-msg with an integer. Where before it was
always zero, which would be treated as a null pointer (potentially causing
a problem when TM interacts with that pointer), but we havn't had the
chance to prove this theory yet
We're right in the middle of a deployment so we can't work on this issue
right away, but we'll have somthing definitive for you by next week