SIPit31 summary

SIPit 31 was hosted by ETSI in Nice, France
the week of Sep 29 - Oct 3 , 2014.

There were 47 attendees from 16 companies visiting from 9 countries.
We had 21 distinct implementations. 


The roles represented (some implementations act in more than one role)
 18 endpoints 
  3 proxy/registrars

Implementations using each transport for SIP messages:
   UDP   100% 
   TCP    86%
   TLS    81% (20% server-auth-only)
   SCTP   10%
   DTLS    5%

67% of the implementations present supported IPv6.

There were two RFC4474 Identity implementations present.

For DNS we had support for:
   Full RFC3263		: 71% 
   SRV only		: 10%
   A/AAAA records only	: 19%
   no DNS support	: 0%


Support for various items in the endpoints: 
  72% replaces
  50% 5389stun
  50% turn
  44% ice
  44% path
  39% 3489stun
  33% sip/stun multiplexing
  28% outbound 
  28% gruu
  17% diversion
  17% turn-tcp
  11% history-info (there were no implementations of 4244bis)
  11% join
   6% service-route

Support for various items in the proxy/registrars:
  67% diversion
  67% outbound
  67% path
  67% sip/stun multiplexing
  67% gruu
  67% history-info
   0% service-route

The endpoints and B2BUAs implemented these methods:
 100% INVITE, CANCEL, ACK, BYE 
  94% REGISTER
  94% NOTIFY
  94% OPTIONS
  83% REFER
  83% INFO 
  78% UPDATE
  67% PRACK 
  67% SUBSCRIBE
  50% PUBLISH 
  28% MESSAGE

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

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

72% of the endpoints present supported SRTP using sdes.
28% supported SRTP using dtls-srtp.

78% of the endpoints supported multipart/MIME.
There was one implementations present with S/MIME support. 

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

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

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

None of the implementations had explicitly updated to RFC 6665.

All of the proxies present implemented RFC5393's fork-loop-fix,
and two implemented max-breadth.

Multiparty tests
(Notes provided by Eoin Mcleod and Olle Johansson)

This was a UA heavy event - far fewer proxy/SBC implementations than usual.

We put up a simple bug counter application for attendees to increment the counter
whenever they found a bug in their implementations. At the end of the week, the counter
was around 150.

We put pressure on TLS, IPv6, and SRTP testing, including each of those in
every multiparty test. Participants were excited to exercise non-trivial tests
while running dual-stack. The suite of automated self tests for TLS, DNS, and
early media continues to expand and improve.

During forking tests, we found several UAs that did not deal well with multiple
200 OKs to an INVITE, essentially ignoring all but the first branch, leading to
retransmission and eventual timeout of the other branches for lack of an ACK.
Those UAs that dealt well with multiple 200 OKs did so by ACKing and sending an
immediate BYE to all but the dialog they chose to keep.

TLS focused testing showed that the use of 'transport=tls' in Route,
Record-Route, and Contact header fields is still pervasive, if not universal.
The arguments against it in RFC5630 (was draft-ietf-sip-sips) are not
compelling to implementers and deployers. Several participants pointed to the
inconsistency of those arguments with the tokens that appear in Via headers
registered at
<http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-transport>.
SIPCORE should consider whether to re-instate transport=tls or provide stronger
documentation for how to indicate TLS over TCP in those header fields when it
is necessary to do so. 

TCP connection reuse has become generally well implemented.

The participants chose to extend multiparty nat/firewall traversal testing
across multiple days. We constructed a wide variety of network boundaries (see
<https://www.sipit.net/images/d/da/800px-Sipit-evil-nat-design.001.png>). We had
one implementation that included ice-tcp and was able to place calls from all
positions in the networks. We encountered one b2bua that tried to change the
candidates while forwarding messages if ice was not listed as a media feature
tag in the corresponding registered contact, resulting in setup failure.
Several UAs were not making optimal c-line address selections when behind nats
and attempting to establish a session with a peer on a public IP that had no
ICE support. These UAs could have provided relay or reflexive addresses, but
offered their private address instead. A significant part of the sessions
focused on when media should start flowing. There are several implementations
doing something similar (but not conformant to) trickle-ICE, sending media
before ICE is completed. These will be moving to trickle ICE when it's clear
how to perform the signalling.

The average SDP body is continuing to grow in length, with ICE being a strong
contributor. A typical body captured during the multiparty tests was 4865 bytes long,
offered 5 m= lines, and had a total of 27 a=candidate lines.

When testing RFC3263 behavior, we configured DNS to return a very large number
of SRV records for a given request. Most clients got a truncated DNS response
over UDP, and didn't try DNS over tcp.  Many clients were handling DNS
configurations that included both IPv4 and IPv6 entries correctly. When a name
had multiple A or AAAA records, client used only one (per query). For SRV
record sets where multiple records had the same host, we had a discussion on
whether or not to compress the list and only try the same IP/port once. The
answer was NO - trust the DNS and test the same server/port multiple times.
Some clients' dns libraries effectively followed CNAME after looking up SRVs
instead of only searching A/AAAA (by paying too much attention to returned
additional data), which the SRV specifications say not to do. 

During the event, we began advertising several IPv6 ULA prefixes. This exposed
that some implementations had not differentiated address types when choosing
which source address to use for a given message. We also saw the addresses
included by several implementations when forming candidates in SDP.

As in previous events, we sent broadcast INVITEs, and messages with broadcast
addresses or loopback addresses in Contacts and Record-Route. As usual, there 
were a few implementations  that responded to the INVITEs, or sent to the 
inappropriate address provided in various URIs.