[SR-Users] doubt about xflags

Daniel-Constantin Mierla miconda at gmail.com
Mon Apr 6 14:10:02 CEST 2020


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
> (<miconda at gmail.com <mailto:miconda at 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
>>     (<miconda at gmail.com <mailto:miconda at 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 at 1.1.18.171 <mailto:1-25549 at 1.1.18.171>: We activate
>>>         TEST_XFLAG!!!!!!!!!!!!!!!!!!!!!!
>>>          2(5231) INFO: Talos-Test Call 500000 / Call-ID
>>>         1-25549 at 1.1.18.171 <mailto:1-25549 at 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 at 2.2.2.26:5060
>>>         <http://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 at 1.1.14.173
>>>         <mailto:sip%3A%2B9934355692006294 at 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 at 1.1.14.173
>>>         <mailto:sip%3A%2B9934355692006294 at 1.1.14.173>;transport=udp;user=phone>
>>>         ], to tag []
>>>          2(5231) INFO: Talos-Test Call 500000 / Call-ID
>>>         1-25549 at 1.1.18.171 <mailto:1-25549 at 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
>>>         (<miconda at gmail.com <mailto:miconda at 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 List
>>>>             sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>>>             https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>             -- 
>>>             Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>>             www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>>             Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com <http://www.asipto.com>
>>>             Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com <http://www.kamailioworld.com>
>>>
>>         -- 
>>         Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>         www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>         Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com <http://www.asipto.com>
>>         Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com <http://www.kamailioworld.com>
>>
>     -- 
>     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com <http://www.asipto.com>
>     Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com <http://www.kamailioworld.com>
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200406/06b3f749/attachment.html>


More information about the sr-users mailing list