<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello Elias, <div><br></div><div>Thanks for the detailed answer. When you say that SEAS can be used in transaction stateless mode, does it mean that I should be able to have OpenSIPS/SEAS and the SIP AS exchange parsed SIP messages along with transport information so that the transport layer as defined in SIP is implemented in OpenSIPS/SEAS ?</div><div><br></div><div>Regards, </div><div><br></div><div>Thomas</div><div><br><div><div>Le 23 sept. 2010 à 10:17, Elias Baixas a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta charset="utf-8"><span class="Apple-style-span" style="font-family: Times; font-size: medium; "><pre>Hello Thomas,</pre><pre>at the moment I am refactoring the SEAS module to work with current sip-router, still haven't poked into current OpenSIPS to see how difficult the port will be, but expect to update it in the following months (after rework for sip-router is done).</pre>
<pre>well, SEAS is mainly composed of 2 parts: </pre><pre>*binary encoding of SIP messages so that application-server doesn't need to parse. The encoding contains a fast-lookup table for the main headers, and pointer-length-bytes for each part of each header, so you dont need to parse in the AS, you directly access the header at its pointer with it's lenght. (this also applies to URIs, parameters, headers, etc). There is code for encoding and decoding of this format in modules/seas directory.</pre>
<pre>*networking and transactional layer emulation: Since the transaction module is so much optimized, and will continue to be enhanced, we thought that a good option would be to let this layer (TL) in SER/OpenSER/OpenSIPs whatever and offer a TL API on the AS.</pre>
<pre><br></pre><pre>yes this has its pros and cons as someone said, but it simplifies things for us, and also offers some performance gains at the AS (less SIP hops, less IPs).</pre><pre>You can use SEAS in transaction stateful or stateless as well, but we don't use stateless very much with WeSIP, so this hasn't been as much tested against real work.</pre>
<pre><br></pre><pre>-It is intended to be generic, but since the only "backend" developed has been wesip, this is the main scenario that we have tested.</pre><pre>I would be very glad if more AS backends were developd (ruby, python, etc ), so you'd had my complete disposition to help ;)</pre>
<pre>anything else, don't hesitate to ask !</pre><pre>Elias</pre><pre>>Hello all,
>I am the main developer of Cipango (<a href="http://www.cipango.org/">http://www.cipango.org</a>), an Open Source SIP-Servlets Application Server (with HTTP and Diameter support). We hav>e 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.
>As a starting point, we had a look at the SEAS documentation (<a href="http://www.opensips.org/html/docs/modules/devel/seas.html">http://www.opensips.org/html/docs/modules/devel/seas.html</a>). 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
</pre><div><br></div></span>
_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>http://lists.opensips.org/cgi-bin/mailman/listinfo/users<br></blockquote></div><br></div></body></html>