Hi, I believe the sample configuration file contains everything that is needed.
The t_continue() is in a route that runs as a separate process initiated by the rtimer module. Peter On Thu, 2012-05-10 at 12:00 +0530, Vineet Menon wrote: > 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 <[email protected]> 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 > <[email protected]> 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 > > <[email protected]> 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 > > > <[email protected]> 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 <[email protected]> > > > > 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 > > > > [email protected] > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > > > > > > > > > > > > _______________________________________________ > > > > sr-dev mailing list > > > > [email protected] > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > > > > > > > -- > > > Peter Dunkley > > > Technical Director > > > Crocodile RCS Ltd > > > > > > > _______________________________________________ > > > sr-dev mailing list > > > [email protected] > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > > > > > > > > > > _______________________________________________ > > > sr-dev mailing list > > > [email protected] > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > -- > > Peter Dunkley > > Technical Director > > Crocodile RCS Ltd > > > > _______________________________________________ > > sr-dev mailing list > > [email protected] > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > > > > > _______________________________________________ > > sr-dev mailing list > > [email protected] > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd > > > _______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > > > _______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
