[OpenSER-Users] [Serusers] FYI: [Fwd: [Sip] SIPit 21 summary]
Jiri Kuthan
jiri at iptel.org
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/
More information about the Users
mailing list