RE: [reSIProcate] Stateless proxy support
Knowing whether my application "requires" stateless handling depends on
the performance benefits of going stateless. But I cannot measure that
until I implement a stateless proxy.
My application is a glorified load balancer with features specific to my
network architecture. My requirement (if you can call it that) is to
squeeze every last CPU cycle out of each SIP message so as to reduce the
number of load balancer's needed. Although we are running on COTS
servers, they still are not free. Also, moving from a pair of load
balancers to 3 or more requires more sophisticated redundancy coding
than I want to put in at this time. I am shooting to handle spikes of
up to 1600 call setups per second running on a pair of 3GHz quad-CPU
servers.
In any case, this information you provided will keep me from spending
hours looking at how to do something resip does not support! My next
alternative was to bypass SipStack altogether: I can use my own UDP
transport class, construct a SipMessage from the packet and then just
use the message parsing features of resip. What do you think? Is there
a middle ground between that and fully stateful?
-----Original Message-----
From: Fischl jason [mailto:jason.fischl@xxxxxxxxx]
Sent: Friday, August 05, 2005 4:22 AM
To: Dennis Dupont
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Stateless proxy support
It looks like somebody removed the support from SipStack for stateless
handling from SipStack.cxx quite a while ago.
We should probably have some discussion on the list about the
requirement for stateless handling before adding support back in since
it will be a fair amount of work to get it working again. Connecting
things together will not be much work - but ensuring it works correctly
will require substantial testing.
I would recommend that we completely remove this support from the stack.
Does your application really require a stateless proxy? If you are
looking for a proxy, take a look at repro - it is transaction stateful
and may do what you want better anyways.
Jason
On 8/4/05, Dennis Dupont <ddupont@xxxxxxxxxxxxxxx> wrote:
>
> I have been looking at the stateless-proxy example and the SipStack
> use of the stateless ctor parameter. It doesn't seem to me that the
> stateless parameter is
> even used by the ctor at all.
>
> So how does SipStack support a stateless proxy? It seems to me that
> there is
> *always* a transaction created. But from 3261, 16.11:
>
> "A stateless proxy does not have any notion of a transaction, or of
> the response context used to describe stateful proxy behavior.
> Instead, the stateless proxy takes messages, both requests and
> responses, directly from the transport layer (See section 18). As
a
> result, stateless proxies do not retransmit messages on their own."
>
> and
>
> "A stateless proxy determines where to forward the request as
> described for stateful proxies in Section 16.6 Item 10. The
> request is sent directly to the transport layer instead of
> through a client transaction."
>
> So how would I code a stateless proxy in order to bypass the
> transaction layer?
>
>
> Thanks,
>
>
>
> Dennis Dupont
> Intelemedia Communications, Inc.
>
>
>
> _______________________________________________
> resiprocate-devel mailing list resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>