[SR-Users] Crash Kamailio 4.1.3

Daniel-Constantin Mierla miconda at gmail.com
Thu Jun 12 17:03:24 CEST 2014


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 
> <mailto: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 <mailto: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 <mailto: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.com
>>>>>             http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>>>>>
>>>>>
>>>>
>>>>         -- 
>>>>         Daniel-Constantin Mierla -http://www.asipto.com
>>>>         http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>>>
>>>         -- 
>>>         Daniel-Constantin Mierla -http://www.asipto.com
>>>         http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>>>
>>>
>>
>>     -- 
>>     Daniel-Constantin Mierla -http://www.asipto.com
>>     http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>
>     -- 
>     Daniel-Constantin Mierla -http://www.asipto.com
>     http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://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/c46537ed/attachment.html>


More information about the sr-users mailing list