[sr-dev] module development
Peter Dunkley
peter.dunkley at crocodile-rcs.com
Thu May 10 11:35:56 CEST 2012
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 <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 list
> > > > sr-dev at lists.sip-router.org
> > > > http://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 list
> > > sr-dev at lists.sip-router.org
> > > http://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 list
> > sr-dev at lists.sip-router.org
> > http://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 list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120510/ae137c1d/attachment-0001.htm>
More information about the sr-dev
mailing list