Looked again over it, the situation seem to happen when you try to get $T_rpl($ci) in a failure route -- that's the call-id for the reply, while being in a failure route where associated request is handled. Is this something you have in your config?
Just as a side note, the $ci should be the same in the failure route.
One thing I noticed, the INVITE has a very long URI, like over 1500chars -- lots of srcip parameters, same value:
INVITE sip:12283280382@199.91.66.172:5060;srcip=199.91.66.172;srcip=199.91.66.172;....
Cheers, Daniel
On 27/08/15 16:00, Alex Balashov wrote:
On 08/27/2015 09:48 AM, Daniel-Constantin Mierla wrote:
No, it is triggered by getting the $ci, but it doesn't get further than parsing the headers for searching the Call-ID.
I wonder; could it be caused by a malformed header or header value immediately preceding the Call-ID in the msg buffer?
I just pushed a patch in master branch with some safety operations in this particular case. Still not clear why it happened, this patch is just trying to recover, rather than crash. Ultimately, it can still crash if the memory is completely corrupted -- not the case of your report where the mem chunk structure is ok.
Thank you for that! Anything helps. It's really appreciated.