Subject: [Sip] Summary of observations from SIPIT 14

From: Robert Sparks <[email-masked]>
Date: Wed, 18 Feb 2004 17:10:13 -0600

SIPIT 14 took place Feb 9 to 13, 2004 in Mandelieu, France.
The event was hosted by ETSI Plugtests. 

If you aren't familiar with SIPITs, please review the
information at http://www.sipit.net . 

This is a summary of what I observed:

There were roughly 128 attendees from 55 organizations.
Participants came from the US, Canada, Israel, Japan, 
Taiwan, France, Germany, Belgium, UK, Turkey, India, Sweden,
Finland, and Norway. Roughly 1/5 of the implementations had
not been to a previous SIPIT.

Startup at this event was more stressful than normal - we had a 
shipment of switches go awry and there was a good deal of last minute
creative network engineering, leading to a good deal of support
work on Monday. We resolved that by Monday night and had a solid
network for the remainder of the event. Still - the infrastructure
volunteers were up ridiculous hours the whole week. I have plans
to improve that. We started training a "loading crew" to help
with future events, and we are refining our kit and our requirements
on the host. If you're a regular SIPIT attendee and are willing
to help, please send me a note.

Overall, the state of interoperability at the event continues to
improve. The biggest strides between this event and the last were
around correct support for TLS. The biggest weakness continues
to be proper construction of offers and answers. Folks know
where to put their SDP, but can't agree what to put in it.
The offer-answer-examples draft is helping, but we may need
to do more.

We found a few places to work on clarifying the specification:

 - The merge detection language covers initial requests, but
   not in-dialog requests. We don't expect in-dialog requests
   to diverge and merge, but there are edge cases where it
   can happen (such as through NAPTR/SRV failover). This became
   particularly important when elements "optimized" failover,
   shorting over to the next SRV record after 4 seconds of no
   response instead of waiting for a full transaction timeout.

 - We inherit HEXDIG from 2234 (I think, this isn't super clear).
   That RFC allows only uppercase letters for hex digits. We 
   defined LHEX to deal with that for digest challenges (where
   we allow only lower case in the syntax). But - ipv6 addresses
   can realistically take either case. We need something new.

 - There were several UAs that puked on Call-IDs that had an
   @ sign in them where the stuff after the @ sign was a
   quoted ([]) IPv6 address (which happened when a request went
   through a v6tov4 gateway). We really should deprecate the
   '@' form from the BNF, replacing the whole header field
   value with an opaque bitstring.

 - It was not clear to all implementors that an in-dialog
   REFER was a target refresh request (hence MUST have a
   single Contact HFV. Bug 750 captures this.

 - An optimization question came up: If you parallel fork
   over UDP to n legs, leg 1 answers, leg 2-n have not yet 
   responded (at all, so you can't send a CANCEL). Do you 
   still have to continue retransmitting the request on
   legs 2-n, or can you squelch them? (You would have to
   keep the transaction around to deal with a response if
   it came, of course).

 - Empty reason phrases broke lots of people - we will add
   these to the torture-test draft. Note that the BNF still
   requires a space after the Status-Code even if the phrase
   is empty.

 - We had another example of Table 2 causing more confusion
   than not - a new registrar decided it was ok not to include
   the current bindings in REGISTER responses since table 2
   listed Contact as optional in that context.

I was able to interview 46 of the 55 organizations. Here are
some observations from those notes - treat all the numbers
as approximations.

- 20 did not support TLS, but 5 of those plan to by the next
  event. (So we're running at about half the implementations
  supporting TLS.) All but one implementation was built on top
  of openssl. Only 6 implementations supported sips:

- We had two implementations of event-lists (and they interoperated)

- Only four implementations did not support loose-routing.

- around 10 implementations supported IPv6. 

- Only 9 implementations understood UPDATE

- I noted 12 implementations supported NAPTR+SRV, 4 SRV only, 8 do 
  A lookups only, and 4 did no DNS at all. My notes only captured this
  information for roughly half the teams, but I think the proportions
  are representative.

- 7 implementations supported S/MIME

- 18 implementations supported PRACK

- UA implementations (including proxies and b2buas) outnumbered 
  proxy/registrar implementations around 4 to 1.

- There were fewer SIMPLE implementations (and most of the ones 
  present were presence server only). Many teams left their SIMPLE
  work at home, waiting for a SIMPLEt.

The multiparty tests at this event were similar to those of
the past. The spiral test continues to have the highest 
participation and yields the most implementation bugs. We
refined the test scenario for REFER, setting up a star topology
that lets us configure once and run many scenarios. We ran a
NAPTR/SRV failover test that was intricate. Several implementations
performed correctly when it became necessary to fail-over. We
exposed one that was only taking the first returned record of
a given type, and others that got their weighting algorithms
backwards. We didn't have many STUN implementations, but those
that were there worked together. We only had one SIGCOMP 
implementation show up this time.

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