hello Daniel sorry i was quite lost, but it's ok and actually i already have the fix on most of the live systems since they have a March 2nd commit of 5.3 version, which already includes it and it works fine
thanks a lot david El lun., 6 abr. 2020 a las 14:10, Daniel-Constantin Mierla (< mico...@gmail.com>) escribió: > Hello, > > that change was pushed to 5.3 at that moment, as I wrote in the email. If > you still get the issue with branch 5.3, let me know. > > Cheers, > Daniel > On 06.04.20 10:48, David Escartin wrote: > > Dear Daniel > > hope everything is ok. > Sorry if i missed something, but this was changed already backported from > master to 5.3 yet? > > thanks alot and regards > david > > El vie., 21 feb. 2020 a las 11:20, Daniel-Constantin Mierla (< > mico...@gmail.com>) escribió: > >> Hello, >> >> ok, good to know works fine now! Thanks for troubleshooting and testing. >> >> Cheers, >> Daniel >> On 21.02.20 10:11, David Escartin wrote: >> >> hello Daniel >> >> I made a try on the latest master branch commit and seems ok now >> thanks a lot! >> >> david >> >> >> El vie., 21 feb. 2020 a las 8:45, Daniel-Constantin Mierla (< >> mico...@gmail.com>) escribió: >> >>> Hello, >>> >>> good catch, I pushed a patch to propagate xflags on msg_apply_changes() >>> in master and backported to 5.3 and 5.2. Give it a try with any of the >>> branches and let me know if works fine now. >>> >>> Cheers, >>> Daniel >>> On 21.02.20 08:29, David Escartin wrote: >>> >>> Hello Daniel >>> >>> i made some more tests and i could see that it's after >>> executing msg_apply_changes function that the xflag is lost. The original >>> message transaction flags remain activated after msg_apply_changes. >>> >>> i did an execution on debug but i saw no information more than >>> >>> 2(5231) INFO: Talos-Test Call 500000 / Call-ID 1-25549@1.1.18.171: We >>> activate TEST_XFLAG!!!!!!!!!!!!!!!!!!!!!! >>> 2(5231) INFO: Talos-Test Call 500000 / Call-ID 1-25549@1.1.18.171: >>> TEST_XFLAG TRUE!!!! >>> 2(5231) DEBUG: <core> [core/msg_translator.c:3262]: >>> sip_msg_update_buffer(): SIP message content updated - reparsing >>> 2(5231) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): SIP >>> Request: >>> 2(5231) DEBUG: <core> [core/parser/msg_parser.c:612]: parse_msg(): >>> method: <INVITE> >>> 2(5231) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): >>> uri: <sip:7777777@2.2.2.26:5060> >>> 2(5231) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): >>> version: <SIP/2.0> >>> 2(5231) DEBUG: <core> [core/parser/parse_via.c:1303]: >>> parse_via_param(): Found param type 235, <rport> = <n/a>; state=6 >>> 2(5231) DEBUG: <core> [core/parser/parse_via.c:1303]: >>> parse_via_param(): Found param type 232, <branch> = >>> <z9hG4bK-5aaf0472f30d11e68aeff8bc1239f520>; state=6 >>> 2(5231) DEBUG: <core> [core/parser/parse_via.c:1303]: >>> parse_via_param(): Found param type 253, <sig> = <74e198e2>; state=16 >>> 2(5231) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end >>> of header reached, state=5 >>> 2(5231) DEBUG: <core> [core/parser/msg_parser.c:498]: parse_headers(): >>> Via found, flags=2 >>> 2(5231) DEBUG: <core> [core/parser/msg_parser.c:500]: parse_headers(): >>> this is the first via >>> 2(5231) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: >>> parse_addr_spec(): end of header reached, state=10 >>> 2(5231) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): >>> <To> [83]; uri=[sip:+9934355692006294@1.1.14.173 >>> ;transport=udp;user=phone] >>> 2(5231) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): >>> to body ["+0034355692006294"<sip:+9934355692006294@1.1.14.173 >>> ;transport=udp;user=phone> >>> ], to tag [] >>> 2(5231) INFO: Talos-Test Call 500000 / Call-ID 1-25549@1.1.18.171: >>> TEST_XFLAG after msg_apply_changes FALSE!!!! >>> >>> >>> best regards >>> david >>> >>> El jue., 20 feb. 2020 a las 20:45, Daniel-Constantin Mierla (< >>> mico...@gmail.com>) escribió: >>> >>>> Hello, >>>> >>>> have you set the flags before creating the transaction? Can you test if >>>> you set a normal flag and an xflag at the same place in request route, is >>>> the first visible in onreply route and the xflag not? >>>> >>>> Cheers, >>>> Daniel >>>> On 20.02.20 18:05, David Escartin wrote: >>>> >>>> Dear all >>>> >>>> one quick question, reading the module corex doc, seems that xflag are >>>> message(transaction) flags. But I made a test and seems for some reason the >>>> flag is not seeing activated at the onreply_route, when it's activated on >>>> the request route. Seemed more like a script flag behaviour. Maybe I'm >>>> missing something? >>>> >>>> thanks a lot and regards >>>> david >>>> >>>> _______________________________________________ >>>> Kamailio (SER) - Users Mailing >>>> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> -- >>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- >>>> www.linkedin.com/in/miconda >>>> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com >>>> Kamailio World Conference - April 27-29, 2020, in Berlin -- >>>> www.kamailioworld.com >>>> >>>> -- >>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- >>> www.linkedin.com/in/miconda >>> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com >>> Kamailio World Conference - April 27-29, 2020, in Berlin -- >>> www.kamailioworld.com >>> >>> -- >> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- >> www.linkedin.com/in/miconda >> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com >> Kamailio World Conference - April 27-29, 2020, in Berlin -- >> www.kamailioworld.com >> >> -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > >
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users