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. I would also
think that it might be better with no SIP stack in terms of
performances. But CPUs are cheap those days :-) 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!
What about implementing a transport option that will make use of a SIP
stack?
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?
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);
sipp-users@lists.sourceforge.net
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
-------------------------------------------------------------------------
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
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
