[OpenSER-Users] [Serusers] FYI: [Fwd: [Sip] SIPit 21 summary]

Fri Nov 30 11:34:39 CET 2007

We can confirm too that we participated with SER and it was doing quite well.
Nils may possibly share few highlites.

-jiri

At 10:55 30/11/2007, Klaus Darilion wrote:

>-------- Original-Nachricht --------
>Betreff: [Sip] SIPit 21 summary
>Datum: Mon, 19 Nov 2007 14:55:53 -0600
>Von: Robert Sparks <rjsparks at nostrum.com>
>An: sip List <sip at ietf.org>
>
>SIPit 21 was hosted by the BII Group and the Beijing University of
>Posts and Telecommunications, November 5-9 in Beijing, China.
>
>The event was a little smaller than the most recent SIPits:
>There were 94 attendees from 38 companies visiting from 15 countries.
>There were 44 teams and around 70 distinct implementations.
>
>The majority of the testing I saw was focusing on advanced scenarios
>rather than basic registration and call setup.
>
>As with SIPit 20, the most common area of interoperability problems
>centered around offer/answer, particularly when attempting to
>negotiate alternate versions of streams or to explicitly state
>parameters to be used with a given stream.
>
>Forty of the attending teams completed the survey - from those answers:
>
>The roles represented (some implementations act in more than one role):
>21 endpoints
>10 proxy/registrars
>   3 standalone registrars
>   5 event servers
>   4 gateways
>   6 automaton UAs (voicemail, conference, appserver, etc)
>   8 b2bua/sbcs
>   4 UAs with signaling, but without media
>   1 test/monitoring tool
>
>Implementations using each transport for SIP messages:
>   UDP  100%
>   TCP  82%
>   TLS  49% (server auth only)
>   TLS    6% (mutual auth)
>   SCTP   3%
>   DTLS   0%
>
>36% of the implementations supported SIP over IPv6 (up from 25% at
>SIPit20)
>18% supported SIP over IPSec
>
>For DNS we had support for:
>    Full RFC3263                : 61%
>    SRV only            : 21%
>    A records only      :  9%
>    no DNS support      :  9%
>
>Support for various items:
>   61% rport
>   15% sigcomp
>   22% enum
>   21% sending multiplexing STUN and SIP
>   28% receiving multiplexed STUN and SIP
>   22% RFC4320 fixes
>   12% identity
>   70% session-timer
>
>There was one implementation of parts of the session-policy framework.
>There was one implementation of the sip-consent framework.
>There were two implementations of parts of the sip-config framework
>(I do not know yet if they worked together).
>There were three implementations of outbound and four of GRUU.
>There were two implementations of MSRP present.
>
>The endpoints implemented these methods:
>100% INVITE, CANCEL, ACK, BYE
>   87% REGISTER
>   87% OPTIONS
>   87% NOTIFY <- still a lot of unsolicted NOTIFYs
>   87% REFER
>   77% SUBSCRIBE
>   77% INFO
>   70% UPDATE
>   67% PRACK
>   47% MESSAGE
>   33% PUBLISH
>
>Support for various extensions in the endpoints:
>   43%  RFC3323 privacy
>   41%  RFC3327 path
>   13%   RFC3840 pref
>   13%  RFC3841 caller-prefs
>   59%   RFC3891 replaces
>   20%  RFC4488 norefersub
>    0%   RFC4538 target-dialog <- There were several folks starting
>to talk about supporting this
>
>Support for various things in the endpoints:
>   10%   ICE (but there was no interoperability - see below)
>    0%   ICE-TCP
>   13%  STUNbis
>   17%  TURN (again, there was no interoperability)
>   75%  symmetric RTP
>   25%  SRTP
>    0%  RTP over DTLS
>
>This is how the endpoints answered how they supported multipart/mime:
>
>   7%   I break if someone sends me multipart/mime
>30%    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
>17%     I try to do something useful with multipart/mime I receive, but I
>never send it
>   3%   I ignore multipart/mime I receive, but I try to send it to do
>something useful
>20%     I try to do something useful with multipart/mime I send and receive
>
>There were 4 endpoints that would send media over TCP - none of them
>supported RFC4145 comedia.
>One of those supported media over TLS.
>
>Implementation is all over the map for fork-loop-fix. However, only 3
>of the proxy/b2buas present were still vulnerable to the simple form
>of the attack described in the draft.
>
>There were no implementations present with support for location-
>conveyance or the geopriv common-policy framework.
>There was one implementation present with support for the RFC4967
>dial-string parameter, and one with support for the ecrit service-urn.
>
>Of the SIP-Events implementations, the following packages were
>supported:
>   62%  refer
>   48%  message-summary
>   38%  presence
>   29%  dialog
>   19%  reg
>   19%  conf
>
>There was one implementation of each of the following packages:
>   ua-profile
>   certificate/credentials
>   vx-rtcpxp (sipping-rtcp-summary)
>
>There was only one implementation of event-lists present.
>
>Only 20% of the SIP-Events implementations supported winfo.
>
>We had a multiparty sesssion for a full morning focusing on NAT
>traversal. Basic use of STUN with SIP is hightly interoperable.
>No two implementations of TURN could even start trying to talk to
>each other (each having implemented to different points in the recent
>torrent of changes). I don't think we'll get much implementation
>feedback until the spec stops making big changes so frequently. No
>two implementations of ICE worked together. The closest was between
>two implementations that have worked in the past, but failed during
>this session when the connectivity checks arrived before the SDP.
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.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
>_______________________________________________
>Serusers mailing list
>Serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/