SIPit25 Summary

 

SIPit 25 was hosted by the University of New Hampshire 
Interoperability Laboratory the week of September 14-18, 2009.

There were 66 attendees from 28 companies visiting from 13 countries.
We had 42 distinct implementations reported in the survey responses. 

The roles represented (some implementations act in more than one role)
 25 endpoints
  7 proxy/registrars
  6 b2bua/sbcs
  4 dedicated event servers

Implementations using each transport for SIP messages:
   UDP   98% 
   TCP   83%
   TLS   38% server-auth, 24% mutual-auth
   SCTP   7%
   DTLS   2%

36% of the implementations supported IPv6.

There were 6 endpoint and 2 proxy implementations of History-Info
There were 3 outbound client and 1 outbound server implementations

There was only one Identity implementation present

For DNS we had support for:
   Full RFC3263		: 75% 
   SRV only		: 15%
   A records only	: 8%
   no DNS support	: 2%

Support for various items in the endpoints (including the b2buas):
  58% replaces
  30% 3489stun
  30% diversion
  26% path
  23% join
  19% gruu
  19% service-route
  19% ipsec
  13% 5389stun
  10% sigcomp
   6% ice
   6% sip/stun multiplexing
   3% turn
   
Support for various items in the proxies:
  57% path
  28% service-route
  14% sigcomp
  14% ipsec
  14% gruu
  14% sip/stun multiplexing
  14% diversion

There were 4 MSRP and 3 XCAP implementations present. 

The endpoints and B2BUAs implemented these methods:
 100% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence only)
  94% REGISTER
  87% OPTIONS
  75% PRACK 
  74% NOTIFY 
  77% UPDATE
  71% REFER
  71% INFO
  62% SUBSCRIBE
  42% MESSAGE
  29% PUBLISH 

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

32% of the endpoints present supported SRTP. 
There were no dtls-srtp implementations at this SIPit.

Multipart/mime support was down to 32% (from 58% at SIPit 24).
There were no implementations present testing S/MIME.

There were 9 SIP Event Server implementations (4 dedicated, the rest in
endpoints - not counting endpoints that support events only for refer).
There were 9 SIP Event Client implementations (again, not counting
endpoints that only support events for refer).

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

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

There were 4 implementations that would send unsolicted NOTIFYs

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

Multiparty tests (Reports contributed by Ole Johansson and Byron Campen)
==========

* TLS/SRTP

The TLS multiparty test made a lot of progress compared with earlier events. 
Olle Johansson coordinated the development of a new set of automated self-tests 
that were available througout the week and used during the multiparty tests.
The tests included various certificate errors and testing of support of
subjAltName X.509 extensions. Many implementations succeeded in the available
tests, but several happily accepted invalid certificates and started a SIP
transaction.  During the test we had four implementations of SRTP, all
supporting SDES. There were a few successful call setups, but not in every
possible direction. 

* Early media

The Early media tests where mostly run with automatic self-tests put together
by the participants.  Results varied, and discussion continues on what is
reasonable to do when a UA receives multiple 183 Session Progress with media
streams from multiple servers. The participating implementations reacted iv
various ways, from not at all to mixing all streams into one.

* Spiral

During the spiral test, an issue with Record-route headers and TLS was encountered.
If the recorded  route is only an IP address, there's nothing to match with the 
subject of the TLS certificate in the  host contacted as a result of the route header, 
unless there's a FQDN in the route header instead of an IP address. 

* Outbound

The Outbound implementations worked very well together. This multiparty
test exercised these scenarios:

  o Client registers with proxy/registrar esablishing a TCP flow.
    Both inbound and outbound calls work.
    
  o Client registers with registrar through edge proxy establishing a TCP flow.
    Both inbound and outbound calls work.
    
  o Client sets up two TCP flows through a pair of edge proxies, inbound and
    outbound calls work. Failover (an edge proxy goes down) did not work as
    expected due to a client keepalive implementation issue.