10 May
2012
10 May
'12
12:35 p.m.
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(a)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(a)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 Dunkley
Technical Director
Crocodile RCS Ltd
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(a)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 Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev @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(a)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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev