[Kamailio-Devel] [Fwd: [Sip] SIPit23 Survey Notes]

Fri Oct 24 16:22:46 CEST 2008

FYI
klaus

-------- Original-Nachricht --------
Betreff: [Sip] SIPit23 Survey Notes
Datum: Thu, 23 Oct 2008 10:16:45 -0500
Von: Robert Sparks <rjsparks at nostrum.com>
An: SIP at ietf.org List <sip at ietf.org>

Also available at https://www.sipit.net/SIPit23_Summary :

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.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip