SIPit27 Summary

SIPit 27 was hosted by ETSI in cooperation with ITRI in Taiwan, Taipei
the week of November 15-19, 2010.

There were 54 attendees from 22 companies visiting from 10 countries.
We had 34 distinct implementations. 

We had several first-time attendees at this event, many bringing 
engineering prototypes. 

The largest change from the previous SIPit was in the level of support
for RFC5626 (Outbound). Nearly a quarter of the implemenations present
included an outbound implementation. Interestingly, about half of those
supported using outbound only with TCP. Multiparty testing uncovered
a potential problem with that specification (see the notes below).

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

Implementations using each transport for SIP messages:
   UDP   100% 
   TCP   86%
   TLS   74% server-auth, 62% mutual-auth
   SCTP  15%
   DTLS   0%

53% the implementations present supported IPv6.

There were no Identity implementations present.

For DNS we had support for:
   Full RFC3263		: 68% 
   SRV only		: 21%
   A records only	: 11%
   no DNS support	: 0%

Support for various items in the endpoints 
  64% replaces
  32% 3489stun
  24% outbound 
  24% turn
  24% path
  20% ice
  20% gruu
  20% diversion
  16% service-route
  16% 5389stun
  16% history-info (there were no implementations of 4244bis)
  12% sip/stun multiplexing
  12% sigcomp
  12% join

Support for various items in the proxies:
  57% path
  29% service-route
  29% sigcomp
  29% diversion
  14% gruu
  14% sip/stun multiplexing
  14% history-info

The endpoints and B2BUAs implemented these methods:
 100% INVITE, CANCEL, ACK, BYE 
  96% REGISTER
  96% OPTIONS
  92% REFER
  92% NOTIFY 
  88% SUBSCRIBE
  80% UPDATE
  80% INFO
  76% PRACK 
  52% MESSAGE
  48% PUBLISH 

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

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

60% of the endpoints present supported SRTP using sdes.
There was one SRTP-mikey implementation present, and two ZRTP implementations.
There were no dtls-srtp implementations at this SIPit.

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

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

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

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

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

There was one implementation of event-rate-control, and two implementations of subnot-etags present.

There was one Info-Packages implementations present using an unregistered payload type.

Four 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 (notes contributed by Eoin McLeod and Byron Campen)

The spiral and forking tests continue to be helpful, uncovering bugs in new endpoint 
implementations, particularly when there are multiple early-media legs or 200 OKs from
multiple branches. The more notable interoperability problems this time were
related to Route/Record-Route, especially when making a transition from IPv4 to IPv6
across a proxy. Most of those problems were resolved when the implementations involved
followed the double record-routing recommendations in RFC5658. That said, when there
were many IPv6 hops contributing to the route-set, we began running into maximum 
message-size assumptions in the endpoints. The team working on this multiparty
created a clever self-testing tool allowing an endpoint to request a number of v6
and v4 hops by using the dialed digits (e.g. 664664446@).

The end of the forking test focused on TLS. We constructed a configuration exercised
a TLS connection between each of the partipating elements with a single SIP request
(see <https://www.sipit.net/files/Forking_tls---digraph%20topology2.png>). The majority
of the elements involved correctly validated the certificates when establishing 
connections. There were some issues with Record-Route values being created that did
not match the certificate contents for the proxy.

We exercised the proxy-doom (see RFC5393) test scenario utilizing a larger number
of participating AoRs. Even with the loop detection mechanisms in that specification,
the number of messages induced utilizing 30 AoRs flooded the participants in this test,
pointing to the need for implementation of Max-Breadth.

The STUN/TURN/ICE multiparty saw successful negotiation of the use of reflexive candidates
at each endpoint. We exercised successful calls between endpoints supporting Outbound and
those that didn't (but both supporting ICE). We induced a successful call with media 
traversing a TURN trapezoid by putting two endpoints behind different NATS, configuring 
them to not advertise reflexive candidates, and using firewalls to prevent each endpoint 
from seeing the other endpoint's TURN server directly.

We had a significant number of Outbound implementations present, and exercised correct
interaction between multiple edge-proxy and registrar implementations. A few of the UAs
participating could only establish one flow. The participants discovered a potential
problem in RFC5626 - the conditions under which an authoritative proxy/register is allowed
to try a second (or subsequent) flow when receiving an error on the active flow may be
incorrect. Currently, section 7 of RFC5626 restricts this to when the proxy has received
a 430, a 408, or a transport failure. It does not allow quick failover if the proxy receives
a 503, or a 480 that may have resulted form a 503 at some proxy between the edge proxy and
the authoritative proxy/registrar. The characterization of all responses other than 430 or
408 meaning "The targeted instance has already provided its response." may be incorrect.
The next SIPit's Outbound multiparty will focus on Flow-Timer behavior.

The SRTP multiparty test continues to expose issues with how different implementations
currently achieve "best-effort" security using SDES. Some implement RTP/SAVP, others 
implement RTP/AVP with crypto attributes. We encountered some issues with secure RTCP -
even if 32-bit keys are negotiated for RTP, the RTCP still needs to use 80-bit keys.
One implementation confused the flag indicating unencrypted SRTCP with meaning RTCP
(hence leaving out the authentication hash).

We spent some time late in the event introducing torture tests, and unusual messages 
into the network (for example, sending an unsolicted 200 OK to an INVITE to the broadcast 
address, which stimulated BYEs from a few implementations). In general, the implementations
at the event handled (or ignored) these messages correctly, but enough didn't that we will
continue to try these at the next several events.