SIPit 25 was hosted by the University of New Hampshire Interoperability Laboratory the week of September 14-18, 2009. There were 66 attendees from 28 companies visiting from 13 countries. We had 42 distinct implementations reported in the survey responses. The roles represented (some implementations act in more than one role) 25 endpoints 7 proxy/registrars 6 b2bua/sbcs 4 dedicated event servers Implementations using each transport for SIP messages: UDP 98% TCP 83% TLS 38% server-auth, 24% mutual-auth SCTP 7% DTLS 2% 36% of the implementations supported IPv6. There were 6 endpoint and 2 proxy implementations of History-Info There were 3 outbound client and 1 outbound server implementations There was only one Identity implementation present For DNS we had support for: Full RFC3263 : 75% SRV only : 15% A records only : 8% no DNS support : 2% Support for various items in the endpoints (including the b2buas): 58% replaces 30% 3489stun 30% diversion 26% path 23% join 19% gruu 19% service-route 19% ipsec 13% 5389stun 10% sigcomp 6% ice 6% sip/stun multiplexing 3% turn Support for various items in the proxies: 57% path 28% service-route 14% sigcomp 14% ipsec 14% gruu 14% sip/stun multiplexing 14% diversion There were 4 MSRP and 3 XCAP implementations present. The endpoints and B2BUAs implemented these methods: 100% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence only) 94% REGISTER 87% OPTIONS 75% PRACK 74% NOTIFY 77% UPDATE 71% REFER 71% INFO 62% SUBSCRIBE 42% MESSAGE 29% PUBLISH 62% of the UAs present both sent RTCP and paid attention to RTCP they received 32% of the endpoints present supported SRTP. There were no dtls-srtp implementations at this SIPit. Multipart/mime support was down to 32% (from 58% at SIPit 24). There were no implementations present testing S/MIME. There were 9 SIP Event Server implementations (4 dedicated, the rest in endpoints - not counting endpoints that support events only for refer). There were 9 SIP Event Client implementations (again, not counting endpoints that only support events for refer). These event packages were supported: Server Client 3 6 message-summary 2 3 reg 0 1 ua-profile 3 4 dialog 1 0 reg-gruu 6 3 presence 2 1 presence.winfo 1 1 xcap-diff These packages were supported with the eventlist extension: Server Client 1 2 dialog 0 1 presence 1 1 reg There were 4 implementations that would send unsolicted NOTIFYs Five of the proxies present still rely only on max-forwards. There were two implementations of fork-loop-fix, but no implementations of max-breadth. Multiparty tests (Reports contributed by Ole Johansson and Byron Campen) ========== * TLS/SRTP The TLS multiparty test made a lot of progress compared with earlier events. Olle Johansson coordinated the development of a new set of automated self-tests that were available througout the week and used during the multiparty tests. The tests included various certificate errors and testing of support of subjAltName X.509 extensions. Many implementations succeeded in the available tests, but several happily accepted invalid certificates and started a SIP transaction. During the test we had four implementations of SRTP, all supporting SDES. There were a few successful call setups, but not in every possible direction. * Early media The Early media tests where mostly run with automatic self-tests put together by the participants. Results varied, and discussion continues on what is reasonable to do when a UA receives multiple 183 Session Progress with media streams from multiple servers. The participating implementations reacted iv various ways, from not at all to mixing all streams into one. * Spiral During the spiral test, an issue with Record-route headers and TLS was encountered. If the recorded route is only an IP address, there's nothing to match with the subject of the TLS certificate in the host contacted as a result of the route header, unless there's a FQDN in the route header instead of an IP address. * Outbound The Outbound implementations worked very well together. This multiparty test exercised these scenarios: o Client registers with proxy/registrar esablishing a TCP flow. Both inbound and outbound calls work. o Client registers with registrar through edge proxy establishing a TCP flow. Both inbound and outbound calls work. o Client sets up two TCP flows through a pair of edge proxies, inbound and outbound calls work. Failover (an edge proxy goes down) did not work as expected due to a client keepalive implementation issue.