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:[email protected]: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. > -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
