[OpenSIPS-Users] SEAS connector for external AS

[Thomas]

Thanks Stefan, see below 

Le 22 sept. 2010 à 15:07, Stefan Sayer a écrit :

> Hello,
> 
> Thomas wrote:
>> 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.
> so, if I understand correctly, you would like to move the virtual IP 
> in front of the proxy, then having master/slave setup of the proxy 
> only, and the app servers using normal internal IPs which can 
> disappear with the box.

Yes exactly. 

> 
> I would be interested in whether what you are asking is possible to do 
> with SIP/UDP. The proxy would have to be able to monitor (or being 
> told about) the state of AS instances, and in case of failover, fix 
> IPs in signaling (like in NAT traversal). This could actually be done 
> on stateless lb proxy.

Yes, IPs in signaling would be an issue then. I am not sure either that it is possible or even a good design option. The idea I had with a SEAS-like connector is to terminate the transport layer at OpenSIPS so that IP fixing is done the other way around i.e. by the application server (IP of OpenSIPS is used for Contact ... instead of internal IP). This would be similar to a SIP IPVS configuration I think. But as far as I understand now SEAS was not designed for this purpose and I would need to develop another OpenSIPS module, if it is possible to use OpenSIPS only for the transport layer.

> 
> What is also possible is to replicate dialog information including 
> route set and do re-Invite from the backup AS instance, thus 
> essentially taking over the call (you can even take over the session 
> if you're handling RTP).
> 

Well from an AS standpoint, it has to be completely generic and transparent to the end-user since. I am afraid than unfortunately re-INVITE may be an option then.


> Stefan
> 
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
> 
> 
> -- 
> Stefan Sayer
> VoIP Services Consulting and Development
> 
> Warschauer Str. 24
> 10243 Berlin
> 
> tel:+491621366449
> sip:sayer at iptel.org
> email/xmpp:stefan.sayer at gmail.com
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users