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
1 media proxy
2 4474bis Authorizer/Verifier
Implementations using each transport for SIP messages:
TLS 62% (46% mutual-auth)
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:
15% sip/stun multiplexing
8% history-info (there were no implementations of 4244bis)
Support for various items in the proxy/registrars:
33% 4474bis (both authorizers and verifiers)
17% 4474 Identity
17% sip/stun multiplexing
The endpoints and B2BUAs implemented these methods:
100% INVITE, CANCEL, ACK, BYE
86% of the implementations sent RTP from the port advertised for reception
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:
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.