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):
4 test/monitoring tools
Implementations using each transport for SIP messages:
TLS 52% server-auth, 26% mutual-auth
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:
10% RFC4320 fixes
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
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)
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:
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)