[SR-Users] Crash Kamailio 4.1.3

[Igor Potjevlesch]

Hello,

we didn't set the early media parameter . its '0' by default, isn't it?

regards,

Igor




2014-06-12 17:03 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:

>  Hello,
>
> if you get a record for 180 response, then you have also the early_media
> parameter set for acc module, isn't it?
>
> In the morning I pushed a patch that should fix this issue. Use latest
> release 4.1.4 and see if works fine. Report the results to know that it is
> gone or not.
>
> Cheers,
> Daniel
>
>
> On 12/06/14 16:55, Igor Potjevlesch wrote:
>
>  Hello,
>
>  We don't use $ai in xlog nor in other process. only in ACC.
>
>  parameters for ACC are :
> modparam("acc", "db_flag", FLT_ACC)
> modparam("acc", "db_missed_flag", 3)
> modparam("acc", "db_url", DBURLWO)
> modparam("acc", "db_extra",
>         "src_user=$fU;username=$Au;src_domain=$fd;src_ip=$si;src_pai=$ai;"
>         "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd")
>
>  For the 3781-4b1-572014182635-OGNAJ-1-A.B.C.D there is  a code 180
> ringing in the INVITE in ACC table.
>
>  regards,
>
>  Igor
>
>
> 2014-06-11 23:01 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>
>>  Few more things...
>>
>> Are you recording 1xx events? Can you check to see if there is another
>> record in acc table for the same call? You can search by call-id
>> 3781-4b1-572014182635-OGNAJ-1-A.B.C.D
>>
>> Eventually, send also the parameters you set for acc module.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 11/06/14 19:25, Daniel-Constantin Mierla wrote:
>>
>> Hello,
>>
>> so you don't print $ai in xlog() statements nor use it in any assignments
>> or other functions besides acc parameter?
>>
>> Cheers,
>> Daniel
>>
>> On 11/06/14 19:19, Igor Potjevlesch wrote:
>>
>>  Hello,
>>
>>  We do not access to the P-asserted-identity in our configuration but
>> we added the field PAI in the db base ACC ( for INVITE, ACK and BYE) .
>> I dont know if it's in request_route, failure_route or branch_route .
>>
>>  This is the print :
>>
>>  (gdb) p mem_block
>> $3 = (struct qm_block *) 0x7f6a6bef1010
>> (gdb) p shm_block
>> $4 = (struct qm_block *) 0x7f6a5666a000
>>
>>  Regards,
>>
>>  Igor
>>
>>
>> 2014-06-11 18:02 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>
>>>  Hello,
>>>
>>> cloning to shm for tm seems ok. Can you tell where you access
>>> P-Asserted-Identity header, via variables? Does it happen in request_route,
>>> failure_route or branch_route?
>>>
>>> Can you print from gdb, any frame:
>>>
>>> p mem_block
>>> p shm_block
>>>
>>> I want to see if parsed filed point to shm or pkg memory.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 11/06/14 17:37, Daniel-Constantin Mierla wrote:
>>>
>>> Hello,
>>>
>>> at least I narrowed it down a bit. It is empty also in the clone stored
>>> in transaction, so it happens either during cloning or before. I will have
>>> to check these parts.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 11/06/14 17:00, Igor Potjevlesch wrote:
>>>
>>>  Hello,
>>>
>>>  This is the result, always for frame 5 :
>>>
>>>  (gdb) p *t->uas.request->pai
>>> $1 = {type = HDR_PAI_T, name = {
>>>     s = 0x7f6a60cd34b8 "P-Asserted-Identity: \"0987654321\"
>>> <sip:0987654321 at A.B.C.D>\r\nContact: <sip:0987654321 at A.B.C.D:5060>\r\nAllow:
>>> INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, INFO,
>>> REFER, UPD"..., len = 19}, body = {
>>>     s = 0x7f6a60cd34cd "\"0987654321\"<sip:0987654321 at A.B.C.D>\r\nContact:
>>> <sip:0987654321 at A.B.C.D:5060>\r\nAllow: INVITE, BYE, REGISTER, ACK,
>>> OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE\r\nSupported:
>>> path,"..., len = 43}, len = 66, parsed = 0x7f6a6d81da88, next =
>>> 0x7f6a60cd3f10}
>>>
>>> (gdb) p *((p_id_body_t*)(t->uas.request->pai->parsed))
>>> $2 = {id = 0x0, num_ids = 0, next = 0x0}
>>>
>>>  *Did *you find one thing in common between the 2 occurrences? Do you
>>> have any ideas about what is the cause of this pai reset?
>>>
>>>  Regards,
>>>
>>>  Igor
>>>
>>>
>>>
>>>
>>> 2014-06-11 16:09 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>>
>>>>  Hello,
>>>>
>>>> in the same frame 5, can yo get:
>>>>
>>>> p *t->uas.request->pai
>>>> p *((p_id_body_t*)(t->uas.request->pai->parsed))
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 10/06/14 18:35, Igor Potjevlesch wrote:
>>>>
>>>>  Hello,
>>>>
>>>>  Here is the results :
>>>>
>>>>  (gdb) frame 5
>>>> #5  0x00007f6a687e9b43 in acc_onreply (t=0x7f6a60d16ff8,
>>>> req=0x7f6a60cd2c10, reply=0x7f6a6c119aa8, code=200) at acc_logic.c:471
>>>> 471                     acc_db_request(req);
>>>>
>>>>
>>>>
>>>>  --
>>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>
>>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140612/e7499fe9/attachment.html>