Jump to navigation Jump to search
Revision as of 18:01, 4 October 2016 by Rjs (Created page with "<pre> 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 lo...")
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.