Hi all, Jacques, Olivier (PD&E IT Test) wrote: > On my side, I don't think that a SIP stack is a good way to go. For > example, with SIPp we have the ability to do security testing (like > protos test suite) which would be difficult with a stack. This is why I mentioned a branch. Because a lot of people (including myself) are quite happy with SIPp now and would reject a change. But here we are talking about benchmarking mainly, which does not care too much about testing every corner of the protocol, but more about precision, replicability, measurements, and so on. However, as we all met here, it seems that we all recognize the value of SIPp and we would like to converge and re-use some of the concepts. In the end we might end up with 2 flavors of SIPp that might share parts of code - like transport, RTP, authentication and what not. > I would also think that it might be better with no SIP stack in terms > of performances. But CPUs are cheap those days :-) and memory is also cheap :). My idea was that doing a 1-pass parse could be better than n-times regular expression searching. > Also, how many SIP stack do support IPv4/IPv6, UDP, TCP, TLS, > mono/multi socket, -t ui transport, and all those other funny features... > On the other side, I do think that a SIP stack can have advantages > some times. Actually SIPp will more benefit of an RTP stack! true about the SIP stack. well, I did not meant a full-blown one. We did investigate for example whether we could use pjsip for example as it seems quite fast. But in the end it was too big, too complex to handle in the way that SIPp does. > What about implementing a transport option that will make use of a > SIP stack? sounds great. > For the release engineering with SVN, yes we will need some :) But I > think we have a good tool for that in our hands, SVN, and that it is > far better that massive patch we have been going through lately. > > Dragos, do you think you would benefit from having a "SIP stack" > branch in the SVN repo? I think that we all will - seeing Charles' or David's working new SIPp would be a great thing (ours is not ready yet as we took a bottom-up approach and considered a completely new scenario control system). But I think that first, as there seems to be a lot of interest and man-power already invested into it, maybe we could have some coordination discussions before we start working.
-Dragos > > Olivier. > > > ------------------------------------------------------------------------ > *From:* Charles P Wright [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, April 25, 2007 16:58 > *To:* Dragos Vingarzan > *Cc:* Verbeiren, David; Jacques, Olivier (PD&E IT Test); > [email protected] > *Subject:* Re: [Sipp-users] Changes for using SIPp in an > implementation of ETSI TISPAN IMS Benchmark > > > Dragos Vingarzan <[EMAIL PROTECTED]> wrote on 04/25/2007 > 03:00:46 AM: > > Hello Charles, David, Olivier, > > > > We at FOKUS, for a 3rd party :), just started about a month ago too, > > working on such tools for benchmarking. However, we took a different > > approach as we believe that there is a true value in having even a > > light-weight SIP stack in SIPp (regexp are great, but if you need to get > > a lot of info from messages, they might be less efficient, easy-to-use > > and safe than parsing one time). > There are others in my group (Erich in particular) who also agree that > a SIP stack might be the way to go. There is certainly more need for > SIP knowledge (e.g., the retransmission hash needs to be updated). It > will be interesting to see if parsing the message once does improve > performance, which I think there is a pretty good chance of happening; > at least for UAS-like scenarios which needs to extract many headers to > generate the message. I am a bit torn in that I think that one big > performance advantage of SIPp is that there is no SIP stack, and thus > it can generate quite a bit more load than if there were (e.g., if it > were to maintain full transaction state, etc.). > > > Also we were very interested in the > > transport layer and overcoming the limits in the number of different > > opened ports (something that you need if you want do simulate hundreds > > of thousands of clients). > > > > So we took a bottom-up approach with the target of having the state > > machines specified in the XML files. > Can you post a sample of your new XML format? > > > Also we were thinking about > > extending the XML files with more control and state options, things that > > probably David already did. > You might be interested in some of the changes I recently posted that > introduce the notion of numeric variables and conditional tests on > those variables into the XML file, thus allowing you to do simple > while loops. > > > Overall, I think that all these changes are too radical to be integrated > > just as that in the SIPp trunk. Charles, you did a great job of pushing > > patches so far. But I think that if David also starts doing the same, it > > will just be too much to handle. Plus that, at least some of our > > changes, will kill the simplicity and ease of usage of SIPp and many > > current users would be upset. And I haven't even considered the new bugs > > that will be introduced. > Yes, it is clear that a development branch or branches and some > release engineering is going to be required. > > Charles > -- > Dr. Charles P. Wright > Research Staff Member > Network Server Systems Software > IBM T.J. Watson Research Center -- ----------------------------------------- Dipl. Eng. Dragos Vingarzan FOKUS/NGNI Kaiserin-Augusta-Allee 31 10589 Berlin,Germany Phone +49 (0)30 - 3463 - 7385 Mobile +49 (0)163 - 159 - 5221 eMail [EMAIL PROTECTED] Web www.fokus.fraunhofer.de We could change the world if God would give us the source code... ----------------------------------------------------------------- ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
