|
On Mon, Oct 03, 2005 at 12:51:19PM +0300, Julian Anastasov wrote:
>
> 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.
I do recall it wasn't a syntax issue, more an issue of
actually being able to identify packets for a call based on the Call-ID.
I really wish I could remember.
> > > 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
I would have thought you want to schedule packets based
on CIP:CPORT:Call-ID or perhaps just Call-ID
Isn't the aim to make sure packets with the same Call-ID
end up at the same real-server?
--
Horms
|
