[OpenSIPS-Users] SEAS connector for external AS

[Thomas]

Hello Stefan, 

Thanks for the feedback, I agree with you. Sticking with standard SIP mechanisms is nice for all the reasons you mentioned and it is the setup we currently use: OpenSIPS as stateless lb proxy in front of several app servers. Performance in Java is not an issue for our applications (we reach more than 1000 CAPS on a cheap 1U, don't know if it's good or bad but it is enough for our applications) and it is good to maintain a tight coupling between the different SIP layers. 
What I have in mind was related to call failover. At the moment, we use virtual IP in a master/slave configuration with a replicated cache to store dialog data. We have been thinking now of a cluster of active servers behind a front-end which make services of the real servers appear as a virtual service with a single IP address and were wondering whether SEAS could allow to have the transport layer only on OpenSIPS (to achieve higher performance on the frontend) and the other layers on the AS side. However, it seems anyway that SEAS is based on transaction layer within OpenSIPS, which is not suited to our usecase... I guess that we'd better stick with an OpenSIPS front-end as a record-routing proxy in order to hide application servers.

Thanks 

Thomas

Le 22 sept. 2010 à 13:53, Stefan Sayer a écrit :

> Hello,
> 
> Thomas wrote:
>> Hello all, 
>> 
>> I am the main developer of Cipango (http://www.cipango.org), an Open Source SIP-Servlets Application Server (with HTTP and Diameter support). We have been using OpenSIPS together with Cipango in a couple of projects using plain vanilla SIP proxying from OpenSIPS to Cipango. 
>> We have found out the SEAS connector which allows for a direct connection between SIPS and an external SIP AS. Since we are also adding HA features to Cipango, we were wondering whether this feature could be useful to have a front-end OpenSIPS distributing SIP messages to several SIP AS. 
> 
> if SIP processing in java is not prohibitively slow, I would recommend 
> to stick to a native SIP stack (or somehow embed a C/C++ stack). 
> Mainly for historical reasons, we had used SER as SIP stack for SEMS, 
> another SIP media/app server, but it turned out that a native SIP 
> stack and using SIP between proxy and app server has many advantages:
> 
> - performance is much better (even with optimized binary RPC, and only 
> passing relevant info from SIP messages to app server - afaik SEAS 
> sends the whole messages)
> 
> - standard SIP methods for load distribution, failover, overload 
> handling etc can be used, they are all very well implemented in *ser/s-r
> 
> - configuration and system administration is much easier
> 
> - usually (in bigger setups), you have a lb proxy in front of the app 
> server anyway
> 
> etc.
> 
> especially high load and overload situations are handled better using 
> traditional SIP methods, which are known and by now also quite well 
> engineered.
> 
> just my 2c (not having much experience with SEAS).
> Stefan
> 
>> 
>> As a starting point, we had a look at the SEAS documentation (http://www.opensips.org/html/docs/modules/devel/seas.html). Since it has a few broken links, we were wondering whether this module is still maintained and if it is intended to a be a generic one or mainly intended to weSIP ? 
>> 
>> Regards, 
>> 
>> Thomas
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users