[SR-Users] CallControl and MediaProxy
Daniel-Constantin Mierla
miconda at gmail.com
Wed Apr 18 10:00:38 CEST 2012
Hello,
On 4/11/12 11:45 AM, Reda Aouad wrote:
> Hi Daniel,
>
> Just to make sure, did you backport it? Will it be released in 3.2.3?
yes, it will be in 3.2.3 -- now is backpprted in git branch 3.2.3.
Cheers,
Daniel
>
> Thanks
> Reda
>
>
>
> On Mon, Mar 12, 2012 at 11:42, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at 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.aouad at gmail.com
>> <mailto:reda.aouad at 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.aouad at gmail.com <mailto:reda.aouad at 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
>> <miconda at gmail.com <mailto:miconda at 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 at gmail.com <mailto:reda.aouad at 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
>>
>>
>>
>>
>
> --
> Daniel-Constantin Mierla
> Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
> http://www.asipto.com/index.php/kamailio-advanced-training/
>
>
--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.php/kamailio-advanced-training/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120418/e8a50eb9/attachment-0001.htm>
More information about the sr-users
mailing list