SIPit28 summary

SIPit 28 was hosted by Digium in Huntsville, Alabama, USA
the week of Arpil 11-15, 2010.

There were 54 attendees from 19 companies visiting from 10 countries.
We had 40 distinct implementations. 

The roles represented (some implementations act in more than one role)
 34 endpoints
  6 proxy/registrars/b2bua/sbcs
  1 dedicated event server

Implementations using each transport for SIP messages:
   UDP   98% 
   TCP   95%
   TLS   68% server-auth, 50% mutual-auth
   SCTP  10%
   DTLS   0%

68% of the implementations present supported IPv6.

There was one RFC4474 Identity implementation present.

For DNS we had support for:
   Full RFC3263		: 53% 
   SRV only		: 33%
   A records only	: 15%
   no DNS support	: 0%

Support for various items in the endpoints: 
  76% replaces
  38% 5389stun
  26% turn
  24% 3489stun
  24% ice
  21% sip/stun multiplexing
  21% outbound 
  21% gruu
  18% path
  18% join
  18% diversion
   6% history-info (there were no implementations of 4244bis)
   3% service-route
   3% sigcomp

Support for various items in the proxy/registrars:
  50% path
  50% outbound
  33% sip/stun multiplexing
  20% diversion
  18% gruu
  17% history-info
  17% service-route

The endpoints and B2BUAs implemented these methods:
 100% INVITE, CANCEL, ACK, BYE 
  94% REGISTER
  91% OPTIONS
  91% REFER
  82% NOTIFY 
  82% INFO
  79% UPDATE
  71% SUBSCRIBE
  68% PRACK 
  47% PUBLISH 
  29% MESSAGE

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

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

56% of the endpoints present supported SRTP using sdes.
There was one dtls-srtp implementations at this SIPit.

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

48% of the implementations present followed RFC6026 (corrections to the INVITE transaction)
68% followed RFC4320 (corrections to the non-INVITE transaction)

There were 5 SIP Event Server implementations (not counting endpoints that support events only for refer).
There were 9 SIP Event Client implementations (not counting endpoints that support events only for refer).

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

These packages were supported with the eventlist extension:
  Server   Client
    1        0        presence

Five of the proxies present still rely only on max-forwards. 
There was one implementation of fork-loop-fix, but no implementations of max-breadth.

Multiparty tests 

(Thanks to Eoin McLeod for contributing notes for several tests)

The Forking test was very well attended. We had the majority of the participants
at the multiparty table. Many teams took away good new information from watching
their implementation react to multiple merges and to Via stacks with transports
switching between IPv4 and IPv6. Forcing multiple 200 Oks was more difficult than
usual given the network equipment at hand. We've created a set of standing automated
tests that will allow endpoints and proxies to test that scenario at their leisure.

The TLS multiparty leveraged DNS to reduce configuration churn. We ensured a full
mesh of connections between participating elements. There were some issues uncovered
with the values used in Route/Record-Route not matching the configured certificates
at an element. We brainstormed a configuration for the next event that will efficiently
expose whether elements are correctly opening a new connection (rather than reusing an
existing connection) when a new request with a resource belonging to an authority not
matching what had been authenticated on the existing connection arrived.

The SRTP tests showed a high level of interoperability (all with SDES keying),
including hold/resume and transfer scenarios. There was a successful test of a
call with media running long enough to increment the ROC, followed by a
hold/resume. Several participants were trying variants of
"best-effort/opportunistic" encryption with lower levels of success.  These
elements tested providing offers with both RTP/AVP and RTP/SAVP media-lines
describing the same logical media channel, and with multiple RTP/AVP media
lines decorated with different crypto attributes.

The STUN/TURN/ICE tests had very high levels of interoperability. The test
scenario involved elements in two natted networks sharing the same address space
and elements in the public address space (including a separate TURN server for each
of the private network islands). We had a mix of elements that supported relay 
allocation and elements that presented only host/reflexive candidates.
A few elements assumed that all of the m-lines in an offer had to present ICE 
candidates. SDP with a mix of ICE enabled m-lines and m-lines without candidates
caused ICE failures.

The Outbound test showed several successful flows being created and maintained.
A mesh of edge-proxies and proxy/registrars were set up and endpoints established
flows through several combinations. There was good UA support for the Flow-Timer,
but there were implementations present that didn't randomize the keepalive value.
There was not much testing of recovery from failed flows at this event - we'll
focus on that at SIPit 29.

We held a long multiparty session focusing on exchanging video with constrained
bandwidth or impaired (latent or lossy) networks. There was a high level of
basic interoperability and reasonable reaction to mid-call shifts in network
conditions, but all parties involved came away with changes they wanted to make
in their implementations.

The Spiral test presented requests to the participating UAs containing a mix of
UDP, TCP, and TLS over IPv4 and IPv6 values in large Via and Record-Route stacks.
Correct operation of subsequent in-dialog requests in both directions was tested,
discovering a few implementation problems, and some invalid assumptions about how
dialog-stateful proxies might need to behave, but most scenarios worked well. We
followed the usual Spiral test with a "fuzz-ball" test utilizing DNS SRV to randomly
distribute the propagation of messages through all of the proxies present, hopping
off to the UAs with a low probability, resulting in an easy-to-configure test that
exercised a full-mesh of connections between proxies and presented the UAs with
very diverse (and large) Via and Record-Route header field values.

We exercised the RFC5393 proxy-doom scenario, again leveraging the SRV load-leveling
capabilities to simplify configuration. We had messages popping out to the UAs from 
each level of the tree, giving them a very large-scale merge test.