SIPit 22 was hosted by the University of New Hampshire Interoberability Laboratory April 14-18, 2008. There were 117 attendees from 46 companies visiting from 14 countries. We had around 80 distinct implementations. Testing continues to focus on more advanced scenarios with only a few teams focusing on basic call. There was a significant amount of successful SRTP interop at this event, including tests that exercised rollover in both directions. Most of the tests established the session using sdes. Most of the teams completed the survey. As has been the case for the last couple of surveys, there is quite likely some sampling error here based on participants not understanding the question and similar issues. This will be the last SIPit that uses this particular survey tool - I'm going to go find something less error-prone or go back to only manual interviews. From the responses: The roles represented (some implementations act in more than one role): 20 endpoints 19 proxy/registrars 8 standalone registrars 8 event servers 6 gateways 7 automaton UAs (voicemail, conference, appserver, etc) 17 b2bua/sbcs 4 UAs with signaling, but without media 3 test/monitoring tool Implementations using each transport for SIP messages: UDP 100% TCP 87% TLS 63% (of which only about half were server auth only) SCTP 9% DTLS 4% 42% of the implementations supported SIP over IPv6 20% supported SIP over IPSec For DNS we had support for: Full RFC3263 : 59% SRV only : 20% A records only : 17% no DNS support : 4% Support for various items: 65% rport 15% sigcomp 39% enum 26% sending multiplexing STUN and SIP 28% receiving multiplexed STUN and SIP 13% RFC4320 fixes (but nearly 30% of the responders said "uncertain" for this) 16% identity (But there were no Identity servers at the event) 67% session-timer 13% dialstring-URI (RFC4967) 7% Service URNs (RFC5031) 15% outbound-13 (and an additional 9% at earlier versions) 13% gruu-15 6% invfix-01 There is still very little reported implementation of the session-policy, sip-consent, and sip-config frameworks. There was one implementation with support for sip-location-conveyance, and two with support for the geopriv-common-policy. We had 5 MSRP implementations reported (but I didn't find out about this in time to set up a multiparty test - we'll do one of those at SIPit23). 13% of the implementations indicated support for anonymous calling. 30% reported using the Diversion header field. A surprising 87% of the implementations made some use of SIP Events. The endpoints implemented these methods: 100% INVITE, CANCEL, ACK, BYE 95% REGISTER 93% NOTIFY <- still a lot of unsolicted NOTIFYs 90% SUBSCRIBE 88% REFER 87% OPTIONS 70% UPDATE 68% INFO 68% PRACK 45% MESSAGE 48% PUBLISH Support for various extensions in the endpoints: 66% RFC3262 100rel 32% RFC3323 privacy 36% RFC3327 path 16% RFC3840 pref 09% RFC3841 caller-prefs 64% RFC3891 replaces 20% RFC4488 norefersub 5% RFC4538 target-dialog Support for various things in the endpoints: 16% ICE (I find these first three survey results suspect - see the multiparty discussion below) 5% ICE-TCP 14% TURN 16% STUNbis 80% symmetric RTP 40% SRTP 5% comedia This is how the endpoints answered how they supported multipart/mime: 11% I break if someone sends me multipart/mime 20% I pretend multipart mime doesn't exist if someone sends it to me 20% I ignore multipart/mime, but will proxy it or hand it to my application if it shows up 14% I try to do something useful with multipart/mime I receive, but I never send it 4% I ignore multipart/mime I receive, but I try to send it to do something useful 18% I try to do something useful with multipart/mime I send and receive 13% uncertain More of the endpoints are starting to issue (and pay attention to ) RTCP, but it's still not the majority. Of the SIP-Events implementations, the following packages were supported: 56% refer 49% presence 47% message-summary 30% reg 28% dialog 12% conf 7% ua-profile 5% kpml 5% regg There was one RLS server and 5 clients supporting the event-lists extension present. There were 5 SIP-Events implementations present supporting winfo. We had a multiparty session focused on STUN/TURN/ICE and Outbound that was well attended. We had successful interop of outbound involving two different clients and one proxy/registrar. STUN interoperability is very high. TURN interoperability, on the other hand, is nearly non-existant - several teams didn't bring their TURN implementations because they felt there was no chance of having implemented a compabible version of the turn specification. We did see one instance of interoperable TURN using the current specification. Despite the relatively high number of implementations claiming support for ICE in the survey (see the statistics above), we were only able to get a couple of ICE implementations into this test. We only saw connectivity checks succeed in one direction - the other direction failed integrity-checks. We will repeat this session at the next SIPit - hopefully TURN will have been stable long enough that there will be implementations to test.