Hi all, > >> One important thing to consider here is that we did not > take care so > >> far of other protocols/transports than UDP (we think our > design will > >> allow an easy integration of the others, but we did not 'port' the > >> TCP and TLS implementations over just yet). So a > combination of our > >> efforts will hopefully be very beneficial. > [...]
> Multiple IP addresses or ports with TCP is quite complex and > you definitely need a structure/class to represent each open > TCP call. Correct SIP protocol requires that responses use > the same call as the corresponding request (if still open) > but for requests you have to find or open a call to the > address/port given in the last contact. (Simple calls are > fine - it is things like OPTIONS and re-INVITE by the called > party that get messy.) That means remembering which TCP call > a request arrived on and on sending requests scanning all the > TCP calls in use to find if there is one already open that > you can use or opening one. I also found TCP open taking up > to 30 seconds (usually due to socket reuse timeouts) so you > cannot just freeze SIPP till a call opens, you have to keep > state and poll. Just a remark on SIP and TCP: My personal believe (based on experience that we have with commercial deployment of SIP at some of our project partners) is that in the long term and especially in commercial environments UDP is not acceptable as signaling transport for SIP, so TCP/TLS and/or SCTP will be the only viable alternatives. Fortunately software architecture and programming paradigms have evolved significantly since the authors of RFC 3261 have added their work-arounds regarding MTU and UDP (e.g., 7.3.3, 18.1.1). These statements imho indicate that the authors of the RFC did not anticipate the complexity (and message size) that SIP and its extensions must be able to handle - I consider the use of UDP as SIP transport at the same level of long-term-vision as "8+3 characters max for a filename are sufficient", "640KByte of main memory is more than enough", "worldwide market for maybe 5 computers" etc. ;) So, if SIPp is intended to be a state-of-the-art traffic generator I see the need to focus on TCP and TLS as SIP transport. It's true that high-performance TCP is more complex to implement than UDP but I think that it's worth spending an effort on this. The second item that I see as high-priority task in the context of IMS and equipment testing is the prepost stuff to handle registration and calls correctly from one single scenario, including a way to account for the 1:n relation between registration and calls, including re-registration etc. Unfortunately we were not able to provide more than a prototype for this part and currently we do not have the resources to merge our changes with the latest trunk. Of course, if someone is seriously considering to integrate the changes we are happy to provide the sources. Just my 2c on this... best regards Joachim ------------------------------------------------------------------------- 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
