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 <miconda@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.aouad@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.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda