Hi Daniel, Just to make sure, did you backport it? Will it be released in 3.2.3?
Thanks Reda On Mon, Mar 12, 2012 at 11:42, Daniel-Constantin Mierla <mico...@gmail.com>wrote: > Hello, > > I will patch and backport during next days -- I was mostly out of the > office during past weeks. > > Cheers, > Daniel > > > On 3/12/12 11:30 AM, Reda Aouad wrote: > > Hi Daniel, > > Any plans to backport this to 3.2 ? > I could still do the changes manually before compilation if you don't have > time to do it. > > Thank you again > Reda > > > > On Wed, Feb 29, 2012 at 10:19, Reda Aouad <reda.ao...@gmail.com> wrote: > >> Daniel, It works with flag 28. >> Can you confirm that flag 28 isn't used by another module? >> If so, can you patch it? When is the next release scheduled for? >> >> The following are the changes I made: >> >> modules_k/call_control.c: flag changed to 28 >> ------------------------------------------- >> #define FL_USE_CALL_CONTROL (1<<28) // use call control for a dialog >> >> parser/msg_parser.h: warning added >> ------------------------------------------- >> /* WARNING: Value (1 << 28) is temporarily reserved for use in kamailio >> call_control >> * module (flag FL_USE_CALL_CONTROL )! */ >> >> >> Thank you :) >> Reda >> >> >> >> On Wed, Feb 29, 2012 at 09:58, Reda Aouad <reda.ao...@gmail.com> wrote: >> >>> A quick grep on flags FL_* in the sources shows the following : >>> Flag 29 is used by acc module, 31 by nat_traversal, 0 to 12 in the >>> parser. >>> Thus I assume that it is safe to test using flag 28. >>> I'll keep you posted on the test result. >>> >>> You'll also find below warnings in msg_parser.h for the used >>> flags. Since flag 30 is declared for mediaproxy in msg_parser.h, I'll >>> change the flag of callcontrol to 28. >>> >>> ----------------------------------------------------------------- >>> /* WARNING: Value (1 << 29) is temporarily reserved for use in >>> kamailio acc >>> * module (flag FL_REQ_UPSTREAM)! */ >>> >>> /* WARNING: Value (1 << 30) is temporarily reserved for use in kamailio >>> * media proxy module (flag FL_USE_MEDIA_PROXY)! */ >>> >>> /* WARNING: Value (1 << 31) is temporarily reserved for use in kamailio >>> * nat_traversal module (flag FL_DO_KEEPALIVE)! */ >>> ----------------------------------------------------------------- >>> >>> $ grep -R 'define FL.* (1' src/kamailio/kamailio-3.2.0 >>> >>> modules_k/call_control/call_control.c:#define FL_USE_CALL_CONTROL >>> (1<<30) // use call control for a dialog >>> modules_k/nat_traversal/nat_traversal.c:#define FL_DO_KEEPALIVE (1<<31) >>> modules_k/acc/acc.h:#define FL_REQ_UPSTREAM (1<<29) >>> parser/msg_parser.h:#define FL_FORCE_RPORT (1 << 0) /*!< force rport >>> */ >>> parser/msg_parser.h:#define FL_FORCE_ACTIVE (1 << 1) /*!< force active >>> SDP */ >>> parser/msg_parser.h:#define FL_SDP_IP_AFS (1 << 2) /*!< SDP IP >>> rewritten */ >>> parser/msg_parser.h:#define FL_SDP_PORT_AFS (1 << 3) /*!< SDP port >>> rewritten */ >>> parser/msg_parser.h:#define FL_SHM_CLONE (1 << 4) /*!< msg cloned in >>> SHM as a single chunk */ >>> parser/msg_parser.h:#define FL_TIMEOUT (1 << 5) /*!< message >>> belongs to an "expired" branch >>> parser/msg_parser.h:#define FL_REPLIED (1 << 6) /*!< message >>> branch received at least one reply >>> parser/msg_parser.h:#define FL_HASH_INDEX (1 << 7) /*!< >>> msg->hash_index contains a valid value (tm use)*/ >>> parser/msg_parser.h:#define FL_MTU_TCP_FB (1 << 8) >>> parser/msg_parser.h:#define FL_MTU_TLS_FB (1 << 9) >>> parser/msg_parser.h:#define FL_MTU_SCTP_FB (1 << 10) >>> parser/msg_parser.h:#define FL_ADD_LOCAL_RPORT (1 << 11) /*!< add >>> 'rport' to local via hdr */ >>> parser/msg_parser.h:#define FL_SDP_BODY (1 << 12) /*!< msg has SDP >>> in body */ >>> modules/mediaproxy/mediaproxy.c:#define FL_USE_MEDIA_PROXY (1<<30) >>> >>> ----------------------------------------------------------------- >>> >>> >>> Reda >>> >>> >>> >>> On Wed, Feb 29, 2012 at 00:18, Daniel-Constantin Mierla < >>> mico...@gmail.com> wrote: >>> >>>> That should be. Try changing one of them to (1<<29) and see if all >>>> works fine. >>>> >>>> On another hand, defining and using core msg flags in a module is a >>>> risk, a different solution has to be done, a simple one is to move the >>>> definition of these flags in the core, so there will be no overlap in the >>>> future. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 2/27/12 9:32 PM, Reda Aouad wrote: >>>> >>>> I looked into mediaproxy.c and found the following : >>>> >>>> ------------------------------------------------------- >>>> #define FL_USE_MEDIA_PROXY (1<<30) >>>> >>>> ... >>>> >>>> # dialog callback >>>> >>>> __dialog_created (...) { >>>> .... >>>> if ((request->msg_flags & FL_USE_MEDIA_PROXY) == 0) >>>> return; >>>> .... >>>> use_media_proxy (...); >>>> } >>>> ------------------------------------------------------- >>>> >>>> >>>> I also found this in call_control.c >>>> ------------------------------------------------------- >>>> #define FL_USE_CALL_CONTROL (1<<30) >>>> >>>> # Public API >>>> CallControl (...) { >>>> ... >>>> msg->msg_flags |= FL_USE_CALL_CONTROL; >>>> ... >>>> } >>>> ------------------------------------------------------- >>>> >>>> So I suspect that since the call_control module uses the same flag as >>>> the mediaproxy module, call_control function is used, flag 30 is set, and >>>> the following condition in the __dialog_created callback function above is >>>> never met >>>> >>>> (request->msg_flags & FL_USE_MEDIA_PROXY) == 0 >>>> >>>> so the callback function continues until executing its last line : >>>> use_media_proxy (...) >>>> which is called on every call to call_control ( ) function.. >>>> >>>> Reda >>>> >>>> >>>> >>>> On Mon, Feb 27, 2012 at 18:39, Reda Aouad <reda.ao...@gmail.com> wrote: >>>> >>>>> Ok thanks Daniel. >>>>> >>>>> I'll do what you suggested and we'll see how to proceed. >>>>> >>>>> Thanks again >>>>> Reda >>>>> >>>> >>>> >>>> -- >>>> Daniel-Constantin Mierla -- >>>> http://www.asipto.comhttp://linkedin.com/in/miconda -- >>>> http://twitter.com/miconda >>>> >>>> >>> >> > > -- > Daniel-Constantin Mierla > Kamailio Advanced Training, April 23-26, 2012, Berlin, > Germanyhttp://www.asipto.com/index.php/kamailio-advanced-training/ > >
_______________________________________________ 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