Subject: [Sip] SIPit 21 summary

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Nov 2007 14:55:53 -0600

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Nov 2007 23:05:25 +0100

Hi Robert,

> 18% supported SIP over IPSec
What does it mean when someone supports SIP over IPsec?
 IPsec is independent of SIP. Is this referring to the 3GPP IPsec 
security between the UA and the P-CSCF?

>   28% receiving multiplexed STUN and SIP
What type of SIP Identity support is this?
Is this support at the proxy for creating the SIP Identity header?
Is this support at the end host for creating the SIP Identity header?
Is this support at proxies that verify SIP identity?
Is this support by UAs verifying SIP identity?

>   17%    TURN (again, there was no interoperability)
RTP over DTLS was an idea in an old draft for media security. The 
document was dumped. Hence, the 0% is not surprising.

Ciao
Hannes

---

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Nov 2007 02:33:48 -0600

> security between the UA and the P-CSCF?

TLS and SCTP are independent of SIP too.
Most of the implementations supporting IPSec were doing it to support  
the 3GPP call flows, yes.
Some were there were embedded products that could just be set up to  
use IPSec. Take that for what it is.

> Is this support at the proxy for creating the SIP Identity header?
This is most of what was there.
> Is this support at the end host for creating the SIP Identity header?
I didn't see anyone doing this at SIPit 21.
> Is this support at proxies that verify SIP identity?
Not at SIPit 21, but two proxies plan to have it at SIPit 22
> Is this support by UAs verifying SIP identity?
I didn't see any of this yet.