SIPit32 summary

SIPit 32 was hosted by the University of New Hampshire Interoperability Laboratory
the week of Sep 12-16, 2016.

We had 19 distinct implementations. (Please keep this lower number in mind
when comparing this summary to those from previous events)

The roles represented (some implementations act in more than one role)
 13 SIP endpoints
  6 proxy/registrars
  1 media proxy
  2 4474bis Authorizer/Verifier

Implementations using each transport for SIP messages:
   UDP   100%
   TCP    65%
   TLS    62% (46% mutual-auth)
   SCTP   10%
   DTLS    0%

52% of the implementations present supported IPv6.

There were two RFC 4474bis and two RFC4474 Identity implementations present.

For DNS we had support for:
   Full RFC3263        : 36%
   SRV only            : 32%
   A/AAAA records only : 32%
   no DNS support      : 0%

Support for various items in the endpoints:
  77% replaces
  46% diversion
  38% path
  36% turn
  36% ice
  29% 5389stun
  23% service-route
  21% 3489stun
  15% sip/stun multiplexing
  15% outbound
  15% join
  15% gruu
   8% history-info (there were no implementations of 4244bis)
   7% turn-tcp

Support for various items in the proxy/registrars:
  50% path
  33% gruu
  33% 4474bis (both authorizers and verifiers)
  17% 4474 Identity
  17% diversion
  17% outbound
  17% sip/stun multiplexing
   0% history-info
   0% service-route

The endpoints and B2BUAs implemented these methods:
  100% INVITE, CANCEL, ACK, BYE
  100% REGISTER
  100% OPTIONS
   94%  NOTIFY
   85%  REFER
   85%  UPDATE
   77%  INFO
   77%  SUBSCRIBE
   62%  PRACK
   62%  MESSAGE
   46%  PUBLISH

86% of the implementations sent RTP from the port advertised for reception
(symmetric-rtp).  
No implementations required the other party to use symmetric-rtp.

71% of the UAs present both sent RTCP and paid attention to RTCP they received.

87% of the endpoints present supported SRTP using sdes.
29% supported SRTP using dtls-srtp.

53% of the endpoints supported multipart/MIME.
There were no implementations present with S/MIME support.

The survey results were confused on support for the corrections to the
transaction state machines or for the corrections to loop detection at proxies
(RFCs 4320, 5393, and 6026.) Rather than quote percentages, we observe that the
support seems consistent with previous events.

Not counting implementations that support events only for REFER:
  There were 7 SIP Event Server implementations
  There were 5 SIP Event Client implementations

These event packages were supported:
  Server   Client
    5        4        presence
    2        0        presence.winfo
    4        3        message-summary
    3        0        dialog
    2        0        reg
    1        1        conference
    0        0        kpml

None of the implementations had explicitly updated to RFC 6665.

This SIPit's multiparty tests had a strong focus on automation to make the
tests more useful between events. We also improved the infrastructure for
several existing tests, including generating certs (thanks to Russ Housley)
that use elliptic-curves for use with TLS and STIR testing.

The SRTP multiparty demonstrated interoperability between endpoints using
DTLS-SRTP, and successful establishement opportunistic SRTP using SDES.

The STIR multiparty tests showed strong interoperability. We successfully
demonstrated calls where the signatures validated, and where they should have
and did fail to validate. We tested certificates using elliptic curves. The
participants suggested several clarifications to the specifications to the STIR
working group.  A couple of important changes to syntax were also suggested.
The flexibility for an authorization service to choose to encode numbers as tn
or uri was exposed as an interoperability issue. Ordering of keys withing the
passport objects turned out to be problematic for implementations using json
libaries that didn't know they needed to care about ordering.