[sr-dev] module development

Vineet Menon mvineetmenon at gmail.com
Thu May 10 08:30:16 CEST 2012


Hi Peter,

How do you know when to resume the processing of message from queue? I mean
you con conveniently place t_suspend() at the beginning of cfg file, but
what about t_continue()?

I get the point that t_continue() would precede mq_fetch(), but then how do
you know that the previous message has been serviced completely?

Can you give me a pseudo code or better a sample cfg file?

Thanks in advance...

Regards,

Vineet Menon




On 1 May 2012 15:40, Vineet Menon <mvineetmenon at gmail.com> wrote:

> Hi Peter,
>
> Wow, that simplified things a lot....and yes, it should solve my problem...
>
> thanks for mentioning this here...
>
> Regards,
>
> Vineet Menon
>
>
>
>
>
> On 1 May 2012 15:35, Peter Dunkley <peter.dunkley at crocodile-rcs.com>wrote:
>
>> **
>> Hi,
>>
>> All that mqueue does is queue a string.
>>
>> When the request arrives I suspend it with t_suspend().  I then queue the
>> index and label returned from the suspend operation with mqueue.
>>
>> When I pull an item off the mqueue I get the index and label of a
>> previously suspended transaction.  I can use t_continue() to resume
>> processing of that SIP request.
>>
>> So by having multiple queues, distributing across those queues according
>> to priority, and then pulling stuff off the queues in the right order you
>> can:
>> 1) Receive requests on Kamailio in the order they arrive
>> 2) But do any complex processing of them in an order based on whatever
>> (arbitrary) priorities you choose
>>
>> Regards,
>>
>> Peter
>>
>>
>> On Tue, 2012-05-01 at 15:30 +0530, Vineet Menon wrote:
>>
>> Peter,
>> You are telling about this module mqueue module, right....
>> if yes, then I understood the module incorrectly.
>>
>> I will get back after I understand it sufficiently....btw any other place
>> to look for the info apart from the sources??
>>
>>
>> Regards,
>>
>> Vineet Menon
>>
>>
>>
>>
>>  On 1 May 2012 15:21, Peter Dunkley <peter.dunkley at crocodile-rcs.com>
>> wrote:
>>
>>  As soon as messages are pulled from the receive buffer they are
>> suspended and queued.  So it is the minimum processing required to pull
>> them into Kamailio.  The let us say you have three queues.  Priority 1
>> messages are queued with queue 1, priority 2 in queue 2, priority 3 in
>> queue 3.  Instead of dequeuing the queues in separate processes (as I do)
>> you dequeue them in one process.  You empty queue 1 first, then queue 2,
>> then queue 3.
>>
>> Won't that do what you want?
>>
>>
>>
>> On Tue, 2012-05-01 at 14:55 +0530, Vineet Menon wrote:
>>
>> @peter,
>> I don't get it?? Your module mqueue seems to be doing IPC. What I want to
>> do is prioratize messages that come to the server according to their
>> behaviour...
>> What I want is to have n queue :
>>
>>
>> _______________________________________________________
>>                         |                                       Prio
>> 1                                                 |
>>
>> |_______________________________________________________|
>>                         |                                       Prio
>> 2                                                 |
>>
>> |_______________________________________________________|
>> _______
>> ______             |                                       Prio
>> 3                                                 |               |   OUT  \
>> |   IN    \
>> |_______________________________________________________|
>> |______ /
>> |______/                                                      / /
>>                                                                  \ \
>>                                                                  / /
>>                         |                                       Prio
>> n                                                 |
>>
>> |_______________________________________________________|
>>
>> IN would come from the OS (messages which has been identified as SIP
>> messages)
>> OUT would go to the kamailio processing part. i.e. it would now be
>> actually reach the kamailio core.
>>
>> Regards,
>>
>> Vineet Menon
>>
>>
>>
>>
>> On 1 May 2012 14:23, Peter Dunkley <peter.dunkley at crocodile-rcs.com>
>> wrote:
>>
>> Hi,
>>
>> I have been using a configuration file based system to share certain SIP
>> requests across different queues for handling by different processes.  Such
>> a scheme could be adapted for prioritisation.
>>
>> I have posted several configuration fragments for this on the list so you
>> should find them if you look in the archives.  My email from 28 March (at
>> around 14:44) is probably the closest to what you are wanting.
>>
>> Regards,
>>
>> Peter
>>
>>
>> On Tue, 2012-05-01 at 13:59 +0530, Vineet Menon wrote:
>>
>> Hi Olle,
>>
>> What I want to do is test a "hypothesis" for congestion control using
>> prioritized scheduling of messages....
>> But thx for that input regarding the newer message queue module....i'll
>> look into it...
>>
>>
>> Regards,
>>
>> Vineet Menon
>>
>>
>>
>>
>> On 1 May 2012 13:18, Olle E. Johansson <oej at edvina.net> wrote:
>>
>>
>> 1 maj 2012 kl. 09:39 skrev Vineet Menon:
>>
>> > Hi,
>> >
>> > I am new to kamailio module devel...
>> > I want to test a new scheduling for SIP messages... Can i do that with
>> kamailio modules? or I should go for something else? probably kamailio
>> core??
>>
>>
>> Can you elaborate a bit more? What do you mean with scheduling for SIP
>> messages?
>>
>> We have a few new modules where you can queue messages for later
>> processing and time their transmission. Check those first.
>>
>> /O
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>> _______________________________________________
>> sr-dev mailing listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>>
>>   --
>> Peter Dunkley
>> Technical Director
>> Crocodile RCS Ltd
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>> _______________________________________________
>> sr-dev mailing listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>>   --
>> Peter Dunkley
>> Technical Director
>> Crocodile RCS Ltd
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>> _______________________________________________
>> sr-dev mailing listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>>   --
>> Peter Dunkley
>> Technical Director
>> Crocodile RCS Ltd
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120510/57b67cca/attachment.htm>


More information about the sr-dev mailing list