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 >> [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 >> [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 >> [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
