Greetings all: SIPIT 12 was held in Stockholm, Sweden Feb 24-28. Hotsip hosted the event and did a phenomenal job. We had global attendance. There were over 100 attendees from over 40 organizations. I estimate there were nearly 100 discrete implementations represented.
We used the new domain "sipit.net" for the first time at this event, serving primary DNS from Hotsip provided servers at the event. Each team had its own subdomain and was able to edit its own zone file directly. Teams were much more willing and able to test SIP using domain names instead of numeric IP addresses. Several teams were making frequent adjustments to their SRV records, testing proper resolution and routing. We will continue to provide this infrustructure component at future events. The common theme that emerged at this event was one of working towards richer content and features. Testers were attempting more intricate media constructions (both multimedia and alternative codecs on single streams), richer presence state, and better security features. There was a sharp increase in the number of implementations supporting TLS and SIPS. Startup stuttered as folks wrestled with setting up trust relationships. Most implementations had been testing with self-signed certificates and required prior knowledge of peer's certificates before accepting connections based on them. There was some confusion around which fields to use inside a certificate for an identifying key. We were able to work past those and get a large spiral to function using hop-by-hop TLS indicated by SRV. We identified a concern with respect to record-routing when using TLS, similar to the old question about record-routing when using non-default transports. How can you be sure that the record-routing elements on either side of you will accept each other's credentials? This will require some list discussion. For now, the safe answer is to always record-route if you are using TLS. A smaller set of implementations supported the sips: URI scheme. Most handled the extra requirements it imposed correctly. A few couldn't be prevented from stepping down to sip:. We had two implementations of S/MIME that successfully exchanged S/MIME encrypted messages. They also exercised the 493 response correctly during initial testing. It's possible that every implementation of sigcomp on the planet was represented at the event. These teams tested extensively, finding a few specification clarifications in the process. Simple testing showed strong interoperability of the sip-events infrastructure, but reinforced the need for all implementations to adopt the baseline pidf document format and follow the guidelines therein for extending it. Several teams were attempting to provide richer functionality through non-interworking extensions. On the floor, the most frequent issues I heard being discussed revolved around non-trivial use of SDP (things like specifying different ptimes for each codec listed on a given m line). I asked at the event for feedback on whether the twice per year format was working or if the participants would prefer to return to more frequent events. I only got one response, in favor of twice a year. I had several people ask that the multiparty tests not be separated from the main testfloor (they were held in a separate room in Stockholm). I also would prefer they be in the same room at future events. I didn't receive many specification interpretations this time, and I suspect its partly because it was inconvenient to bring the questions to me. If you attended the event, and have comments about what was effective and what wasn't, please send them to this list or directly to me. The next event will be hosted by Mitel in Canada in August. RjS _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
