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
