|
Hello,
On Mon, 3 Oct 2005, Horms wrote:
> I made some code for a customer that used the Call-ID as the key for
> scheduling. Unfortunately the code was canned and I don't have a copy to
> offer, but it was fairly easy to implement. I also seem to recall that
> the system didn't work all that well because of the way some SIP
> implementations use Call-ID, but I don't recall exactly why.
Call-ID has simple syntax but i can't guess what can be the
problem, may be SIP gurus can comment.
> > May be there can be service flag that requests per-packet
> > scheduling but with reduced number of connections. The SIP scheduler
> > can request the same. This flag should be somehow propagated to
> > existing connections returned from _in_get to cause scheduling and
> > second conn lookup (may be out_get) that avoids duplicated connections
> > between CIP:CPORT and RS - little slower but avoids creating extra
> > connections.
>
> I'm not sure why you would get duplicated connections. Perhaps I need to
> look at your code more carefully. But in my mind, single-packet
> scheduling just creates connections with a really short timeout. If
> they happen to exist in the table when the next packet comes in, they
> they get reused, but in the more likely case that they have already
> expired, then an new connection is created, using a scheduling algorithm
> that consistently allocates the same Call-ID to the same real-server.
while ops does not hash connections, pps hashes connections,
SIP will do it on Call-ID scheduling request. If SIP relies on existing
connections to select RS then this is not Call-ID based scheduling
and there is no need SIP scheduler to exist. SIP requierments are:
- schedule packets according to Call-ID even if cp already exists
- same CIP:CPORT can create many connections to different RS but to
reduce their number they must be unique for RS->CIP:CPORT
Regards
--
Julian Anastasov <ja@xxxxxx>
|
