4 Sep
2015
4 Sep
'15
1:56 p.m.
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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
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.