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 <mico...@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 <mico...@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 <mico...@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@A.B.C.D>\r\nContact: <sip:0987654321@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@A.B.C.D>\r\nContact: >>> <sip:0987654321@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 <mico...@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 > >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users