SIPit23 Summary

SIPit 23 was hosted by ETSI with technical support from Orange 
the week of October 13-17, 2008 in Lannion, France

There were 97 attendees from 37 companies visiting from 19 countries.

I manually surveyed the teams at this event to avoid some of the sampling error
we've seen with the use of an automated survey tool at the last few SIPits.
Please take care to remember this change in the measurement tool when trying to
read trends comparing this report to previous events. In particular, I was
careful to avoid counting two products that were essentially the same
implementation as different. With that in mind:

We had over 50 distinct implementations. 

There were a higher than usual proportion of implementations attending SIPit
for the first time at this SIPit. As a result, there was more testing of basic
interoperability than we've seen for the last several events. There were still
several advanced teams demonstrating interoperability of more complicated
scenarios.

62% of the UAs present both sent RTCP and paid attention to RTCP they recieved
    this is the first sipit where this has been true for the majority of the UAs.

This event saw a (mostly) successful test of ICE between three implementations
at the multiparty tests. 

There were no implementations of the sip-config, sip-consent, or session-policy
frameworks. The only people in the room who had even read the sip-config
framework documents are regular IETF participants. Even fewer had read
sip-consent or session-policy. There is currently a huge gap between
specification and implementation for these concepts. (Note - there have been
sip-config implemantations at previous events, but the teams that brought them
were not able to attend this time).

The roles represented (some implementations act in more than one role):
 29 endpoints
 13 proxy/registrars
  8 event servers
  7 gateways
  2 automaton UAs (voicemail, conference, appserver, etc)
 14 b2bua/sbcs
  3 UAs with signaling, but without media
  5 test/monitoring tool

The set of things considered UAs below (the union of the 
endpoints/b2buas/gateways/etc) consisted of 42 implementations.

Implementations using each transport for SIP messages:
  UDP    100%
  TCP     93%
  TLS     48% server-auth, 28% mutual-auth
  SCTP    11%
  DTLS   none

30% of the implementations supported SIP over IPv6 (This was significantly down
from the last few events - I think it is mostly due to the number of very young
implementations present.)

19% supported SIP over IPSec

For DNS we had support for:
   Full RFC3263		: 65% (continuing to climb)
   SRV only		: 15%
   A records only	: 13%
   no DNS support	:  7%

Support for various items:
  72% rport
  15% sigcomp
  36% enum
  13% RFC4320 fixes 
  13% invfix
  63% session-timer
  9% outbound (various versions)
  9% gruu-15 

There were only 2 implementations claiming support for Identity. 2 for the
dial-string URI (RFC4967), and none for Service URNs (RFC5031). These are all
lower than what was reported at previous events - a result of the opportunity
to double-check answers during the manual survey.

Many teams expressed intent to implement outbound and gruu once something was
published as an RFC, and a strong unwillingness to even try until that happens.


36% of the implementations indicated support for anonymous calling.

24% reported using the Diversion header field.

76% of the implementations made some use of SIP Events.
There was a huge upswing in support for the message-summary event.

The UAs implemented these methods:
  95% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence only)
  93% REGISTER
  95% NOTIFY <- still a lot of unsolicted NOTIFYs
  95% SUBSCRIBE
  86% OPTIONS
  83% PRACK 
  77% INFO
  72% REFER
  72% UPDATE
  64% MESSAGE
  43% PUBLISH (Note that several of these are b2buas 
               that are not really processing the PUBLISH 
               - the next survey will split those out)

Support for various extensions in the endpoints:
  98%   RFC3262 100rel 
  50%   RFC3323 privacy
  36%   RFC3327 path
   7%   RFC3840/RFC3841 pref/caller-prefs
  79%   RFC3891 replaces
   9%   RFC4488 norefersub
   7%   RFC4538 target-dialog 

There were 6 ICE implementations (and 1 ICE-TCP implementation)
There were 6 TURN clients and one TURN server present
There were 19 STUN clients (6 were stun-bis)

88% of the UAs supported symmetric RTP
16% supported SRTP - only one had code based on the dtls-srtp work

Support for multipart/mime increased (38% of the UAs would do something with it
on receipt). There were no implementations present testing S/MIME.

Of the SIP-Events implementations, the following packages were supported:
  82%	message-summary
  72%	refer
  59%	presence
   8%	reg
  16%	dialog
  12%	conf

There were two RLS servers and 6 clients supporting 
the event-lists extension present. There were two xcap servers present.

There were 8 SIP-Events implementations present supporting winfo.

7 of the proxies present implemented some form of loop detection (only 3 have
implemented the loop-detection part of fork-loop fix)

There were 5 MSRP clients and one MSRP relay present.  All of the clients
supported file transfer (3 used file-transfer-mech).  Several clients were able
to exchange files.  Two of the clients were able to exchange instant messages.
(Only one had been created with the intent to send instant messages - the rest
were file transfer centric.) The embedded-device implementers noted that the
decision to not allow a negotiated maximum chunk size (not maximum message
size) is causing them significant difficulty.

The multiparty STUN/TURN/ICE test saw successful calls using ICE after
correcting some implementation issues around authenticating a binding and
becoming less strict on parsing SDP (specifically the rtcp attribute).
There was some argument over what inputs to use for candidate pairs when
one stream (of many) in an offer was rejected in the answer.

I asked where people were taking bits from messages to display as caller-id.
There were many different kinds of answers, including
 P-Asserted-Identity if present, then From
 From display name
 username part of From uri
 P-Asserted-Identity only
 Contact uri
 Remote IP address
 P-Asserted-Identity, then Remote-Party-ID, then From
 From, then Remote-Party-ID, then P-Asserted-Identity
 Remote-Party-ID then From
 From then P-Assertid-Identity
 P-Asserted-Identity, then Reply-To, then From
 entire From URI
Of these, using the From display name occurred most frequently, 
but not much more than any of the other responses

After removing some minor rough edges, the presence multiparty test 
exercised xcap successfully, modifying resource lists and presence rules. 
There are still many questions around how to discover the xcap root uri.

The TLS multiparty test had several new participants and did not go as smoothly
as it has in past events. Most of the issues were with configuration of individual
implementations, but there was quite a bit of confusion around the use of sips:
and transport=tls. We will hold a longer and more rigourous multiparty session
focusing on TLS at the next SIPit.