SIPit22 Summary

From GlobalSIPit
Jump to: navigation, search
SIPit 22 was hosted by the University of New Hampshire Interoberability
Laboratory April 14-18, 2008.

There were 117 attendees from 46 companies visiting from 14 countries.
We had around 80 distinct implementations.

Testing continues to focus on more advanced scenarios with only a few teams
focusing on basic call.

There was a significant amount of successful SRTP interop at this event,
including tests that exercised rollover in both directions. Most of the tests
established the session using sdes. 

Most of the teams completed the survey. As has been the case for the last
couple of surveys, there is quite likely some sampling error here based on
participants not understanding the question and similar issues. This will be
the last SIPit that uses this particular survey tool - I'm going to go find
something less error-prone or go back to only manual interviews.

From the responses:

The roles represented (some implementations act in more than one role):
 20 endpoints
 19 proxy/registrars
  8 standalone registrars
  8 event servers
  6 gateways
  7 automaton UAs (voicemail, conference, appserver, etc)
 17 b2bua/sbcs
  4 UAs with signaling, but without media
  3 test/monitoring tool

Implementations using each transport for SIP messages:
  UDP	100%
  TCP	 87%
  TLS	 63% (of which only about half were server auth only)
  SCTP	  9%
  DTLS	  4%

42% of the implementations supported SIP over IPv6 
20% supported SIP over IPSec

For DNS we had support for:
   Full RFC3263		: 59%
   SRV only		: 20%
   A records only	: 17%
   no DNS support	:  4%

Support for various items:
  65% rport
  15% sigcomp
  39% enum
  26% sending multiplexing STUN and SIP
  28% receiving multiplexed STUN and SIP
  13% RFC4320 fixes (but nearly 30% of the responders said "uncertain" for this)
  16% identity (But there were no Identity servers at the event)
  67% session-timer
  13% dialstring-URI (RFC4967)
   7% Service URNs (RFC5031)
  15% outbound-13 (and an additional 9% at earlier versions)
  13% gruu-15 
   6% invfix-01

There is still very little reported implementation of the session-policy,
sip-consent, and sip-config frameworks. 

There was one implementation with support for sip-location-conveyance, and two
with support for the geopriv-common-policy.

We had 5 MSRP implementations reported (but I didn't find out about this in
time to set up a multiparty test - we'll do one of those at SIPit23).

13% of the implementations indicated support for anonymous calling.

30% reported using the Diversion header field.

A surprising 87% of the implementations made some use of SIP Events.

The endpoints implemented these methods:
 100% INVITE, CANCEL, ACK, BYE
  95% REGISTER
  93% NOTIFY <- still a lot of unsolicted NOTIFYs
  90% SUBSCRIBE
  88% REFER
  87% OPTIONS
  70% UPDATE
  68% INFO
  68% PRACK 
  45% MESSAGE
  48% PUBLISH

Support for various extensions in the endpoints:
  66%   RFC3262 100rel
  32%	RFC3323 privacy
  36%	RFC3327 path
  16%   RFC3840 pref
  09%	RFC3841 caller-prefs
  64%   RFC3891 replaces
  20%	RFC4488 norefersub
   5%   RFC4538 target-dialog 


Support for various things in the endpoints:
  16%   ICE  (I find these first three survey results suspect - 
             see the multiparty discussion below)
   5%   ICE-TCP
  14%	TURN 
  16%	STUNbis
  80%	symmetric RTP
  40%	SRTP
   5%	comedia

This is how the endpoints answered how they supported multipart/mime:

 11%	I break if someone sends me multipart/mime
 20%    I pretend multipart mime doesn't exist if someone sends it to me
 20%	I ignore multipart/mime, but will proxy it or hand it to my application if it shows up
 14%	I try to do something useful with multipart/mime I receive, but I never send it
  4%	I ignore multipart/mime I receive, but I try to send it to do something useful
 18%	I try to do something useful with multipart/mime I send and receive
 13%    uncertain

More of the endpoints are starting to issue (and pay attention to ) RTCP, but it's still not the majority.

Of the SIP-Events implementations, the following packages were supported:
  56%	refer
  49%	presence
  47%	message-summary
  30%	reg
  28%	dialog
  12%	conf
   7%   ua-profile
   5%   kpml
   5%   regg

There was one RLS server and 5 clients supporting the event-lists extension present.
There were 5 SIP-Events implementations present supporting winfo.

We had a multiparty session focused on STUN/TURN/ICE and Outbound that was well
attended.  We had successful interop of outbound involving two different
clients and one proxy/registrar. STUN interoperability is very high.  TURN
interoperability, on the other hand, is nearly non-existant - several teams
didn't bring their TURN implementations because they felt there was no chance
of having implemented a compabible version of the turn specification. We did
see one instance of interoperable TURN using the current specification. Despite
the relatively high number of implementations claiming support for ICE in the
survey (see the statistics above), we were only able to get a couple of ICE
implementations into this test. We only saw connectivity checks succeed in one
direction - the other direction failed integrity-checks. We will repeat this
session at the next SIPit - hopefully TURN will have been stable long enough
that there will be implementations to test.