(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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.