SIPit23 Summary
Revision as of 15:16, 23 October 2008 by RjS-legacy (talk | contribs)
SIPit 23 was hosted by ETSI with technical support from Orange
the week of October 13-17, 2008 in Lannion, France
There were 97 attendees from 37 companies visiting from 19 countries.
I manually surveyed the teams at this event to avoid some of the sampling error
we've seen with the use of an automated survey tool at the last few SIPits.
Please take care to remember this change in the measurement tool when trying to
read trends comparing this report to previous events. In particular, I was
careful to avoid counting two products that were essentially the same
implementation as different. With that in mind:
We had over 50 distinct implementations.
There were a higher than usual proportion of implementations attending SIPit
for the first time at this SIPit. As a result, there was more testing of basic
interoperability than we've seen for the last several events. There were still
several advanced teams demonstrating interoperability of more complicated
scenarios.
62% of the UAs present both sent RTCP and paid attention to RTCP they recieved
this is the first sipit where this has been true for the majority of the UAs.
This event saw a (mostly) successful test of ICE between three implementations
at the multiparty tests.
There were no implementations of the sip-config, sip-consent, or session-policy
frameworks. The only people in the room who had even read the sip-config
framework documents are regular IETF participants. Even fewer had read
sip-consent or session-policy. There is currently a huge gap between
specification and implementation for these concepts. (Note - there have been
sip-config implemantations at previous events, but the teams that brought them
were not able to attend this time).
The roles represented (some implementations act in more than one role):
29 endpoints
13 proxy/registrars
8 event servers
7 gateways
2 automaton UAs (voicemail, conference, appserver, etc)
14 b2bua/sbcs
3 UAs with signaling, but without media
5 test/monitoring tool
The set of things considered UAs below (the union of the
endpoints/b2buas/gateways/etc) consisted of 42 implementations.
Implementations using each transport for SIP messages:
UDP 100%
TCP 93%
TLS 48% server-auth, 28% mutual-auth
SCTP 11%
DTLS none
30% of the implementations supported SIP over IPv6 (This was significantly down
from the last few events - I think it is mostly due to the number of very young
implementations present.)
19% supported SIP over IPSec
For DNS we had support for:
Full RFC3263 : 65% (continuing to climb)
SRV only : 15%
A records only : 13%
no DNS support : 7%
Support for various items:
72% rport
15% sigcomp
36% enum
13% RFC4320 fixes
13% invfix
63% session-timer
9% outbound (various versions)
9% gruu-15
There were only 2 implementations claiming support for Identity. 2 for the
dial-string URI (RFC4967), and none for Service URNs (RFC5031). These are all
lower than what was reported at previous events - a result of the opportunity
to double-check answers during the manual survey.
Many teams expressed intent to implement outbound and gruu once something was
published as an RFC, and a strong unwillingness to even try until that happens.
36% of the implementations indicated support for anonymous calling.
24% reported using the Diversion header field.
76% of the implementations made some use of SIP Events.
There was a huge upswing in support for the message-summary event.
The UAs implemented these methods:
95% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence only)
93% REGISTER
95% NOTIFY <- still a lot of unsolicted NOTIFYs
95% SUBSCRIBE
86% OPTIONS
83% PRACK
77% INFO
72% REFER
72% UPDATE
64% MESSAGE
43% PUBLISH (Note that several of these are b2buas
that are not really processing the PUBLISH
- the next survey will split those out)
Support for various extensions in the endpoints:
98% RFC3262 100rel
50% RFC3323 privacy
36% RFC3327 path
7% RFC3840/RFC3841 pref/caller-prefs
79% RFC3891 replaces
9% RFC4488 norefersub
7% RFC4538 target-dialog
There were 6 ICE implementations (and 1 ICE-TCP implementation)
There were 6 TURN clients and one TURN server present
There were 19 STUN clients (6 were stun-bis)
88% of the UAs supported symmetric RTP
16% supported SRTP - only one had code based on the dtls-srtp work
Support for multipart/mime increased (38% of the UAs would do something with it
on receipt). There were no implementations present testing S/MIME.
Of the SIP-Events implementations, the following packages were supported:
82% message-summary
72% refer
59% presence
8% reg
16% dialog
12% conf
There were two RLS servers and 6 clients supporting
the event-lists extension present. There were two xcap servers present.
There were 8 SIP-Events implementations present supporting winfo.
7 of the proxies present implemented some form of loop detection (only 3 have
implemented the loop-detection part of fork-loop fix)
There were 5 MSRP clients and one MSRP relay present. All of the clients
supported file transfer (3 used file-transfer-mech). Several clients were able
to exchange files. Two of the clients were able to exchange instant messages.
(Only one had been created with the intent to send instant messages - the rest
were file transfer centric.) The embedded-device implementers noted that the
decision to not allow a negotiated maximum chunk size (not maximum message
size) is causing them significant difficulty.
The multiparty STUN/TURN/ICE test saw successful calls using ICE after
correcting some implementation issues around authenticating a binding and
becoming less strict on parsing SDP (specifically the rtcp attribute).
There was some argument over what inputs to use for candidate pairs when
one stream (of many) in an offer was rejected in the answer.
I asked where people were taking bits from messages to display as caller-id.
There were many different kinds of answers, including
P-Asserted-Identity if present, then From
From display name
username part of From uri
P-Asserted-Identity only
Contact uri
Remote IP address
P-Asserted-Identity, then Remote-Party-ID, then From
From, then Remote-Party-ID, then P-Asserted-Identity
Remote-Party-ID then From
From then P-Assertid-Identity
P-Asserted-Identity, then Reply-To, then From
entire From URI
Of these, using the From display name occurred most frequently,
but not much more than any of the other responses
After removing some minor rough edges, the presence multiparty test
exercised xcap successfully, modifying resource lists and presence rules.
There are still many questions around how to discover the xcap root uri.
The TLS multiparty test had several new participants and did not go as smoothly
as it has in past events. Most of the issues were with configuration of individual
implementations, but there was quite a bit of confusion around the use of sips:
and transport=tls. We will hold a longer and more rigourous multiparty session
focusing on TLS at the next SIPit.