[SR-Users] CallControl and MediaProxy

Reda Aouad reda.aouad at gmail.com
Wed Apr 11 11:45:26 CEST 2012


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
<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> 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> 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> 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> 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120411/e7f195a9/attachment-0001.htm>


More information about the sr-users mailing list