Subject: [Sip] SIPIT 16 summary

From: Robert Sparks <[email-masked]>
Date: Mon, 11 Apr 2005 12:34:16 -0500

SIPIT 16 was held April 3-8, 2005 at the Fairmont Banff Springs.

Jasomi Networks hosted the event and provided one of the most stable
testing environments the SIPIT has enjoyed to date.

We had 120 people in attendance from 15 countries. There was a much
higher ratio of first-time attendees than normal (I estimate about a 
third).
There were 57 teams present.

General interoperability continues to improve at each SIPIT. Even with 
the
large number of first time attendees, most of the peer-to-peer testing 
was progressing
well beyond basic call.  Lack of interoperability seemed to arise 
mostly from
differing interpretations of non-trivial SDP bodies.

------------
Implementation Statistics:

The list below is a summary of the number of implementations 
implementing
various features. These statistics are obtained through a verbal survey 
of each
team through the week - it's likely that some of these numbers are 
under-reported
by one or two teams.

SIP over TLS: 25
SIP over UDP only: 11
DNS SRV lookups (per 3263): 30
DNS NAPTR lookups (per 3263): 25
Lookup A records only: 7
Transfer using REFER: 29
REFER with Replaces: 22
PRACK: 24
Graceful handling of Multipart-Mime: 15
Session-Timer: 12
STUN: 4
ICE: 2
Privacy: 7
SIP Events
   presence : 16
   presence.winfo: 9
   dialog package: 5
   mwi package: 14
   eventlist: 4
IPv6: 5
SIGCOMP: 4
SRTP: 4
GRUU: 1

There were 10 teams with implementations doing various things to
keep NAT bindings alive (sending CRLFs, empty media packets,
etc). The remainder were not attempting to address the problem at
this time.

There was only one team present that was ready to test GRUUs. Several
others were beginning to work on them anticipating testing at SIPIT 17.
The majority of the attendees had not heard of them before.

Likewise, the attendees in general were not aware of ICE or the recent
work on SIP Identity.

There were 4 implementations of SRTP present, with varying degrees
of interoperability. Lack of interoperability was most often due to a 
lack
of common transforms.

42 of the attending teams agreed to anonymously self report how many 
bugs
they discovered in their implementation during the week. The results:
     # bugs       # teams
	2-5		  7
	6-10 	12
	11-20 	11
	21-50 	12

------------

The kind of arguments over what the specification says remains about 
the same.
There were two serious specification clarity/accuracy questions that 
arose:
   1) How does a proxy deal with a retransmitted INVITE when a 200 it 
forwarded
        upstream is lost (the spec's requirement to delete the server 
transaction at
        the proxy once a 200 is forwarded may have unintended 
consequences)
   2) What should a proxy/registrar do when someone registers sips: 
Contacts
        against a sip: URI.
  More detailed descriptions of each of those questions will be sent to 
the SIP list.
  Other arguments overheard (bugs will be entered for each of these):
    - New implementers still miss that CSeqs come from independent 
spaces on each
      side of a dialog
    - There was confusion on what a proxy that's holding onto a 6xx  
response while
      canceling legs should do if a 200 shows up.
    - There was confusion around what endpoints can/should do to keep 
proxies from
      bailing out of an INVITE transaction before they are ready.
    - There were several implementations reusing the same branch tag 
from an
      INVITE in an ACK-200.
    - There were still arguments about the case-sensitivity of tags, the 
branch parameter
       value, and the value of the Content-Type header field.
    - There were arguments over what "reason" to provide in a final 
NOTIFY when an
       unSUBSCRIBE happens (more than one implementation used 
"deactivated" instead
       of "timeout").
    - The REFER spec doesn't allow for empty body NOTIFY requests (for 
things like an
       immediate NOTIFY or a pending Event: refer subscription). Similar 
questions arose
      for the mwi package.

------------

The multiparty tests continue to be the most effective bug-exposing 
tools at the event.
One of the most effective at this event was a multiparty REFER/Replaces 
test constructed
by Dan Petrie. The scenario forces each of the three INVITEs in a 
consultative transfer
to be forked to every participant, stressing admissions policy and 
dialog identification logic
very effectively. I'll get a detailed description of this test up on 
sipit.net soon.

RjS

_______________________________________________
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