Skip to main content

SIP Proxy service - Stateless vs Stateful

20 replies [Last post]
ivelin
Offline
Joined: 2003-07-13
Points: 0

After looking at the outstanding task for SIP Proxy and reading on the scenarios for stateful vs stateless proxy, I am beginning to think that we should focus on stateless for the time being (credit goes to Ranga).

Stateless proxy covers a lot of the proxy use cases, has a simple state machine, is easier to test and performs well.

Given that the top priority is to stabilize the SIP modules as soon as possible and release a full GA package of core JSLEE 1.0 + SIP 1.2, my vote is to stick to stateless SIP proxy for now.

Thoughts?

Ivelin

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mranga
Offline
Joined: 2003-06-06
Points: 0

> From a Mobicents implementation perspective, stateful
> is not more difficult to provide than stateless (all
> the hard work has already been done in JAIN SIP 1.2).
> Creating a transaction for each incoming request
> should be the default behavior. You can start by not
> exposing these transactions to the application layer
> if you wish.

I agree it is only slightly more difficult. (Response context, Timer C would be the two things to add ).

I dont see why the two are mutually exclusive however. Stateful proxy servers are more widely deployed because services are simply easier to build for them. However, if all you want is a simple proxy server with no intermediary services (or very simple ones for which routing errors on retransmissions are fine), then one can get away with a stateless proxy server.

Since Jeroen has more real-life experience with IMS than I have, if such are the needs of IMS. I think one should definitely have the option to configure a service for stateful proxying in that case.

>
> > From there we can start talking about the types of
> > applications people want to build on JSLEE and
> design
> > the services, be that proxies or some other type
> of
> > service enablers.
> >
> > Keeping an eye on IMS is good, but I am even more
> > interested in real world applications.
> >
>
> From my perspective, IMS is very much "real world".
> Guess it depends in which circles you hang out
>
> > jbemmel, if you have the time, please start a
> > separate thread on the calendar application
> > requirements. I am not sure how SIP is used as a
> > calendar update protocol.
> >
>
> The calendar based routing app is only one example. I
> did not mean to suggest that SIP would be used to
> update the calendar (I can imagine a Web Services
> call to read the calendar, but again, this is beside
> the point)

If the calendar changes when you are routing the call (i.e changes when you retransmit), then do you see a huge problem in this particular case.

I do agree that for many services such as call billing stateful proxing simplifies the application because all filtering of retransmissions and spurious responses etc. are taken care of by the SIP stack.

Again, this all boils down to what you want to build. I am starting to see the point with maybe going the stateful proxy server route. I think its just a matter of some additional implementation state that the proxy server has to keep around.

Ranga

>
> > The support aspect is important. Thanks for
> bringing
> > it up.
> >
> >
> > Ivelin

baranowb
Offline
Joined: 2006-01-09
Points: 0

Hey guys. So whats the final word? I dont have strong opinion on wheather we should create stateles or stateful proxy. not much to say about it.
Sipservices currenlty in repo need some tune up for new ra, thats all I think. I did it for examples - sip services there us sip ra 1.2.

Not sure right now but wouldnt it be useful to also include rewriting of route headers? Like in 16.12.1 secton of rfc 3261 - not sure at the moment if rewriting is job only for statefull proxy.

mranga
Offline
Joined: 2003-06-06
Points: 0

> Hey guys. So whats the final word?
When I replied to the mail notification of the new forum, I did not see it appear here. Well, anyways, here goes:

I think, the IMS requirement is a good argument to go the direction of a transaction stateful proxy.

People want to do location management ( registrar records ) using google database / jxta etc.

Thus it would make sense to make that a separate SBB.

I dont have strong
> opinion on wheather we should create stateles or
> stateful proxy. not much to say about it.
> Sipservices currenlty in repo need some tune up for
> new ra, thats all I think. I did it for examples -
> sip services there us sip ra 1.2.
>
> Not sure right now but wouldnt it be useful to also
> include rewriting of route headers? Like in 16.12.1
> secton of rfc 3261 - not sure at the moment if
> rewriting is job only for statefull proxy.

Yes I think it would be the job of a statefull proxy.

Message was edited by: mranga

ivelin
Offline
Joined: 2003-07-13
Points: 0

> From a Mobicents implementation perspective, stateful
> is not more difficult to provide than stateless (all
> the hard work has already been done in JAIN SIP 1.2).
> Creating a transaction for each incoming request
> should be the default behavior. You can start by not
> exposing these transactions to the application layer
> if you wish.

Isn't this how the current proxy works, though? Is it just a matter of updating it for the 1.2 APIs?

> From my perspective, IMS is very much "real world".
> Guess it depends in which circles you hang out

That is interesting. In my corner of the world, IMS is a big-fat wet dream that is too far fetched in its entirety. People tend to cherry pick pieces of it that make sense for them.

mranga
Offline
Joined: 2003-06-06
Points: 0

> > From a Mobicents implementation perspective,
> stateful
> > is not more difficult to provide than stateless
> (all
> > the hard work has already been done in JAIN SIP
> 1.2).
> > Creating a transaction for each incoming request
> > should be the default behavior. You can start by
> not
> > exposing these transactions to the application
> layer
> > if you wish.
>
> Isn't this how the current proxy works, though? Is it
> just a matter of updating it for the 1.2 APIs?

It is already updated for 1.2 APIs I recall I started that work with an "early implementation" of 1.2.

What is missing I believe is

1. Support for forking.
2. Support for configurable call routing rules.
3. Support for Timer C.

All good things to add and to work on.

>
> > From my perspective, IMS is very much "real
> world".
> > Guess it depends in which circles you hang out
>
> That is interesting. In my corner of the world, IMS
> is a big-fat wet dream that

:-) hmm... I pity your corner of the world if such is the stuff of their wet dreams.

is too far fetched in its
> entirety. People tend to cherry pick pieces of it
> that make sense for them.

ivelin
Offline
Joined: 2003-07-13
Points: 0

> > Isn't this how the current proxy works, though? Is
> it
> > just a matter of updating it for the 1.2 APIs?
>
> It is already updated for 1.2 APIs I recall I started
> that work with an "early implementation" of 1.2.
>
> What is missing I believe is
>
> 1. Support for forking.
> 2. Support for configurable call routing rules.
> 3. Support for Timer C.
>
> All good things to add and to work on.
>

Bartek will have to comment on the status of what's in the mobicents CVS. What repo are you applying the updates to?

> :-) hmm... I pity your corner of the world if such is
> the stuff of their wet dreams.

lol

mranga
Offline
Joined: 2003-06-06
Points: 0

The proxy server that Francesco, you and I demonstrated was one that was based upon something that Open Cloud donated and that I made an early release of JSIP 1.2 for. Is this your current version. Are you asking "what branch am I applying the updates to?" I dont have any updates to apply and I would be referring to CVS HEAD.

Ranga

ivelin
Offline
Joined: 2003-07-13
Points: 0

Bartek will be moving this sip services code from the main mobicents cvs repo to the sip ra svn. Please sync up with him before committing enhancements.

mranga
Offline
Joined: 2003-06-06
Points: 0

> After looking at the outstanding task for SIP Proxy
> and reading on the scenarios for stateful vs
> stateless proxy, I am beginning to think that we
> should focus on stateless for the time being (credit
> goes to Ranga).
>
> Stateless proxy covers a lot of the proxy use cases,
> has a simple state machine, is easier to test and
> performs well.
>
> Given that the top priority is to stabilize the SIP
> modules as soon as possible and release a full GA
> package of core JSLEE 1.0 + SIP 1.2, my vote is to
> stick to stateless SIP proxy for now.
>
> Thoughts?

We need to enhance the JSIP RA to support stateless operation. There should be a new activity defined for messages that do not belong to any Transaction ( the stack will pass a null transaction ID to the application ).
>
> Ivelin

jbemmel
Offline
Joined: 2005-03-01
Points: 0

In IMS all proxies except the I-CSCF are transaction stateful (and often call stateful too). All but the most trivial proxies are stateful, and in particular when you want to "do stuff" with received SIP requests (e.g. call into other systems), doing things statelessly will simply not work. You'll have loads of retransmissions

Regards,
Jeroen

mranga
Offline
Joined: 2003-06-06
Points: 0

You will see retransmissions that is true but you would pass them through. Of course, if you wanted to do something "interesting" in the signaling path that turns messy because one of the very important things that the stack does is to automatically handle retransmissions. If you want "exactly once" semantics for invocation of services, then this is problematic with a stateless proxy.

Which brings up the question - what is the purpose of the proxy server that is being contemplated? If it is for an IP/PBX then a simple dialog stateful proxy (b2bua such as Asterisk ) is fine. Maybe 30 CAPS is all you can do but who cares.

jbemmel
Offline
Joined: 2005-03-01
Points: 0

I expect that a lot of applications people will want to build will fall in the category of "X-based call routing", where X can be anything from calendars to presence to property files / databases. Those simply work better if you use stateful proxying

Another reason for doing things statefully, and actually recommending that, is to reduce the length and complexity of Ethereal traces people will post on the support forums

mranga
Offline
Joined: 2003-06-06
Points: 0

> I expect that a lot of applications people will want
> to build will fall in the category of "X-based call
> routing", where X can be anything from calendars to
> presence to property files / databases. Those simply
> work better if you use stateful proxying

Depends on the consistency you want to support. If the data is static then presumably it does not matter. Say you are consulting a calendar, then you could wind up forwarding a message to the wrong location if you get a retransmitted request and the calendar changed from under you I suppose.

>
> Another reason for doing things statefully, and
> actually recommending that, is to reduce the length
> and complexity of Ethereal traces people will post on
> the support forums

That one is hilarious :-) Yes I completely agree with this one. Let the stack builders worry about ethereal traces. Let application builders worry about application level traces.

ivelin
Offline
Joined: 2003-07-13
Points: 0

Since there is a range of proxies from stateless to B2BUA, I am thinking that we should start simple and build more on demand. How about we start with the stateless as something that is easiest to implement, understand and debug. It will take us fastest to a stable JSLEE SIP 1.2 base. At a minimum it would allow SIP users to register and connect with each other via the server.

From there we can start talking about the types of applications people want to build on JSLEE and design the services, be that proxies or some other type of service enablers.

Keeping an eye on IMS is good, but I am even more interested in real world applications.

jbemmel, if you have the time, please start a separate thread on the calendar application requirements. I am not sure how SIP is used as a calendar update protocol.

The support aspect is important. Thanks for bringing it up.

Ivelin

jbemmel
Offline
Joined: 2005-03-01
Points: 0

> Since there is a range of proxies from stateless to
> B2BUA, I am thinking that we should start simple and
> build more on demand. How about we start with the
> stateless as something that is easiest to implement,
> understand and debug. It will take us fastest to a
> stable JSLEE SIP 1.2 base. At a minimum it would
> allow SIP users to register and connect with each
> other via the server.
>

From a Mobicents implementation perspective, stateful is not more difficult to provide than stateless (all the hard work has already been done in JAIN SIP 1.2). Creating a transaction for each incoming request should be the default behavior. You can start by not exposing these transactions to the application layer if you wish.

> From there we can start talking about the types of
> applications people want to build on JSLEE and design
> the services, be that proxies or some other type of
> service enablers.
>
> Keeping an eye on IMS is good, but I am even more
> interested in real world applications.
>

From my perspective, IMS is very much "real world". Guess it depends in which circles you hang out

> jbemmel, if you have the time, please start a
> separate thread on the calendar application
> requirements. I am not sure how SIP is used as a
> calendar update protocol.
>

The calendar based routing app is only one example. I did not mean to suggest that SIP would be used to update the calendar (I can imagine a Web Services call to read the calendar, but again, this is beside the point)

> The support aspect is important. Thanks for bringing
> it up.
>
>
> Ivelin

jbemmel
Offline
Joined: 2005-03-01
Points: 0

Ivelin,

Another argument for doing stateful, is that the new SIP Servlet specification JSR-289 (for which you are a member/contributor I believe) is deprecating stateless proxy behavior. There is a reason for that (as I have said before): once you start developing and deploying serious applications, you find that stateless is usually inadequate

Regards,
Jeroen

ivelin
Offline
Joined: 2003-07-13
Points: 0

do you have a pointer to the reasons why stateless was deprecated?

do you recommend us adopting the proxy behavior of 289?
a more general question, should we try to implement the entire 289 api on top of jslee or just pieces of it?
Its obviously not designed for jslee environment, so the proper question is probably what parts of it you consider relevant and applicable for the jslee user base.

> Ivelin,
>
> Another argument for doing stateful, is that the new
> SIP Servlet specification JSR-289 (for which you are
> a member/contributor I believe) is deprecating
> stateless proxy behavior. There is a reason for that
> (as I have said before): once you start developing
> and deploying serious applications, you find that
> stateless is usually inadequate
>
> Regards,
> Jeroen

jbemmel
Offline
Joined: 2005-03-01
Points: 0

> do you have a pointer to the reasons why stateless
> was deprecated?
>

No, unfortunately I do not have that. What I wrote was my best educated guess

> do you recommend us adopting the proxy behavior of
> 289?

Yes, at least as the default behavior. You can then say that stateless is a differentiator / optimization feature compared to JSR-289

> a more general question, should we try to implement
> the entire 289 api on top of jslee or just pieces of
> it?

To me that would be the way to go for the mid term. That's where I see SIP-based application servers heading

Technology wise, SIP servlet appears to be better adopted than JAIN SIP, on grounds of being "more simple". How ironic that in v1.2 some features mimmicking the JAIN SIP API (e.g. Address interface) are being introduced, guess they found out that simple does not always equal useful

> Its obviously not designed for jslee environment, so
> the proper question is probably what parts of it you
> consider relevant and applicable for the jslee user
> base.
>

Like I said, API wise I sense a preference for SIP servlet over JAIN SIP. People seem to prefer building SIP headers using Strings, rather than constructing objects. In SIP servlet, things like Contacts, Via headers etc. are managed by the container, which is indeed easier and makes much sense.

fram
Offline
Joined: 2004-05-13
Points: 0

"Like I said, API wise I sense a preference for SIP servlet over JAIN SIP. People seem to prefer building SIP headers using Strings, rather than constructing objects. In SIP servlet, things like Contacts, Via headers etc. are managed by the container, which is indeed easier and makes much sense."

When you need to write non-trivial application leave the container the complete control over contacts, via headers could be a double hedged sword.

SIP is a tricking protocol and depending on the service you're implmenting you need different access level to the stack. I think that one of the good thing of JSLEE is the separation between container and API in this way you could have different SIP APIs (jsr289 like, JAIN SIP like, etc...) and use the same programming model and concurrency control behaviour.

Regarding the JSIP 1.2 resource adaptor I think that is better to go for a transaction stateful proxy service, looks to me like the best fit.

It would be good also to have a RA with a more simple interface in this way we could have the best of both world:
- a simple interface like Sip Servlet
- and a solid container that provides a well defined and standard concurrency control model and failure handling.

Francesco

jbemmel
Offline
Joined: 2005-03-01
Points: 0

> When you need to write non-trivial application leave
> the container the complete control over contacts, via
> headers could be a double hedged sword.
>

Agreed, and the model isn't so black-and-white either. For example, even with SIP servlet you can add specific parameters to the contact header. And for Via headers, I know some applications like to add transaction-specific state information in proprietary parameters - that too could be accomodated in the API