SIPit24 Summary

SIPit 24 was hosted by JPNIC and NICT the week of May 18-22, 2009 in Akihabara, Tokyo, Japan.

Because of the recent global economic changes and the outbreak of flu, we had a smaller
event than usual.  There were 65 attendees from 28 companies visiting from 11 countries.
Despite the smaller number of participants we still had 43 distinct implementations. 

The mix of implementations was unusual. There were fewer proxies/b2buas/sbcs than normal.
We also had a higher mix of partial implementations focusing on enabling testing.

GRUU is being more widely implemented - there were 8 implementations present.

As at the last SIPit, there were no implementations of the sip-config, 
sip-consent, or session-policy frameworks. 

The roles represented (some implementations act in more than one role):
 25 endpoints
  6 proxy/registrars
  6 b2bua/sbcs
  4 test/monitoring tools

Implementations using each transport for SIP messages:
  UDP    100%
  TCP     81% 
  TLS     52% server-auth, 26% mutual-auth
  SCTP     7%
  DTLS     5%

57% of the implementations supported SIP over IPv6 (This is a big increase
over past events, and is related to where the event was held.)

For DNS we had support for:
   Full RFC3263		: 76% 
   SRV only		: 5%
   A records only	: 8%
   no DNS support	: 11%

Support for various items:
  71% rport
  20% sigcomp
  26% enum
  10% RFC4320 fixes 
  24% invfix
  69% session-timer
  20% IPSec
  12% outbound
  14% diversion


There was only 1 implementation claiming support for Identity. 2 for the
dial-string URI (RFC4967), and two for Service URNs (RFC5031). We asked
proxies to test processing an INVITE with a service URN in the Request-URI
and To: header field and a pair of SIP URIs in the route header. The majority
of reports back were that the message would be rejected (but they are changing
their code).

There were 4 MSRP and 3 XCAP implementations present. 

There was one implementation of location-conveyance.

The UAs implemented these methods:
  95% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence only)
  95% REGISTER
  88% NOTIFY 
  88% SUBSCRIBE
  83% PRACK 
  80% OPTIONS
  76% REFER
  71% UPDATE
  68% INFO
  61% MESSAGE
  56% PUBLISH 

Support for various extensions in the endpoints:
  82%   RFC3262 100rel 
  31%   RFC3323 privacy
  23%   RFC3327 path
   8%   RFC3840/RFC3841 pref/caller-prefs
  62%   RFC3891 replaces
  10%   RFC4488 norefersub
   3%   RFC4538 target-dialog 

50% of the implementations were RFC 3489 STUN capable. 21% were RFC 5389 STUN capable.

There were 2 full ICE implementations (appearing in several instances), an additional 
implementation of an older spec, and several implementations underway that were not quite
ready to test. There were no ICE-TCP implementations this time.
There were 7 TURN clients and 4 TURN server present.

70% of the UAs present both sent RTCP and paid attention to RTCP they recieved

39% of the endpoints present supported SRTP - a large uptick from the last event.
Only one had code based on the dtls-srtp. 

Support for multipart/mime continues to increase - 58% of the endpoints present
would handle it.  There were no implementations present testing S/MIME.

Of the SIP-Events implementations, the following packages were supported:
  65%	presence 
  65%	refer
  39%	message-summary 
  32%	reg
  16%	conf
  13%	dialog

23% of those implementations supported eventlist.

There were 6 SIP-Events implementations present supporting winfo.

Four of the proxies/b2buas present still rely only on max-forwards.
There were two implementations of fork-loop-fix, but no implementations of max-breadth.

Based on a query from James Polk, I asked endpoints how they reacted to receiving
a 300 class response to an initial invite. Of those who responded:
  25% would stop processing the call
  33% would follow the redirect if and only if there was only one contact
  17% would follow the first contact if one or more were present
  25% would follow all contacts (or give the user a choice of which to follow)