Cloud Communications Alliance
HomeNews & EventsSIP Forum NewsUncategorizedSIPit 20: another success

SIPit 20: another success

SIPit 20 was hosted by Alcatel-Lucent in Antwerp, Belgium from April 16 to April 20, 2007. Many thanks to Alcatel-Lucent, in particular Ben Bonnaerens and Nadine Staelens for a well-planned and effective event in a very nice venue.

There were 145 attendees from 59 companies visiting from 19 countries present.

There were 67 teams and around 90 distinct implementations.

A higher than usual percentage of the attendees (my guess is around 60%) were attending SIPit for the first time.

The most common thread in interoperability problems centered on interpreting SDP at this event. Most of these were implementation issues, but more people are running into issues as they try to exchange more than the most basic of offers and answers. These ranged from issues with multiple m-lines to trying to specify different packetization times for codecs on the same m-line to problems with the “delayed” offer-answer exchange in INVITE/200/ACK (where the INVITE has no body).

More implementations are supporting TLS, and several implementations had issues around correctly handling mutual authentications and reusing connections.

There was a lot of (understandable) confusion about what to do with sips:. Most implementations that could handle TLS are not yet trying to handle sips:. The few that did try to do something sane with sips: are watching the discussion on the SIP mailing list. In any case, there was not a set of implementors present who felt sips was sufficiently specified and would be unhappy if the definition changed. I also didn’t find anyone who felt an existing deployment would suffer from any change to the definition.

We used a web-based survey tool for collecting implementation statistics for the second time. As noted in the report for SIPit19, this has an impact on the accuracy of the information (since someone will inevitably not understand one or more questions, or won’t know the answer). Only 59 of the 67 teams completed the survey. We plan to use a slightly different mechanism at the next event to improve the accuracy and completeness of the results.

With the understanding that there is some sampling error here is what those 59 teams reported.

The roles represented (some implementations act in more than one role):

  29 endpoints
  19 proxy/registrars
   5 standalone proxies
   5 redirect servers
   7 gateways
   9 automaton UAs (voicemail, conference, etc.)
  17 b2bua/sbcs
   5 UAs with signaling but no media
   4 test/monitoring tools

Implementations using each transport for SIP messages:

  UDP 100%
  TCP  82%
  TLS  46% (server auth only)
  TLS  24% (server or mutual auth)
  SCTP  7%
  DTLS  0%

71% of the implementations claimed they would correctly reassemble fragmented UDP (10% of the remaining were not sure).

At SIPit19, Robert Sparks asked for the size of the largest datagram an implementation would accept. The answers indicated that most folks didn’t understand the question, so I was not able to produce a useful summary from that event. We repeated the question at SIPit 20, and while there’s still confusion, there are enough answers to start getting a picture. Remember again that these are self-reported numbers:

   1500 bytes or less: 18% (the smallest was 1300)
   1500 to 4K        : 10%
   64K               : 24% 
   didn't know       : 25%

25% of the implementations present supported SIP over IPv6.

For DNS we had support for:

   Full RFC3263    : 54%
   SRV only        : 14%
   A records only  : 14%
   no DNS support  : 12%
   other           : 6% (includes those that didn't know or didn't reply)

Support for various items:

   31% ENUM
   68% rport
   27% multiplexing SIP/STUN on the same port
   14% SIGCOMP
   15% RFC4320 fixes 
   16% Identity

There were no implementations present of any significant part of the session-policy framework.

There were no implementations of the hilt-sipping-*-overload drafts or anything else meeting the requirements in ietf-sipping-overload-reqs.

There were two server implementations of sip-outbound, but no clients to test against.

There were 4 implementations of GRUU present (at different draft levels). We did have one successful test where a UA obtained and used a GRUU.

The endpoints implemented these methods:

    94% REGISTER
    92% OPTIONS
    79% SUBSCRIBE <- Notice the difference here...
    96% NOTIFY    <- unsolicited notifies were prevalent
    68% PRACK
    58% MESSAGE
    79% INFO
    64% UPDATE
    87% REFER
    38% PUBLISH

The endpoints implemented these extensions:

  77% RFC3891: replaces
  60% RFC4028: session-timer
  21% RFC3327: path
   6% RFC3840: pref
   2% RFC3841: caller-prefs
  30% RFC3323: privacy
   0% RFC4538: target-dialog
   6% RFC4488: norefersub
  68% RFC3262: 100rel
  11% RFC3994: indication of message composition

57% of the endpoints implemented sipping-cc-transfer

When asked about STUN support, the client implementations replied:

   8% I implement all the client requirements of draft-ietf-behave-rfc3489bis
   6% I implement some, but not all, of the client requirements of draft-ietf-behave-rfc3498bis
   4% I implement all of the client requirements of RFC3489
  14% I implement some, but not all, of the client requirements of RFC3489
  60% I do not implement STUN as a client
   8% Other

There were several STUN servers and at least two TURN servers. We had more TURN clients this time, and successfully exercised TURN. Three implementations claimed support for ICE, but no interoperability was reported (I suspect there were versioning issues that couldn’t be overcome in the time-scale of the event). There was one ice-tcp implementation present.

This is how the endpoints characterized their handling of S/MIME:

   6% I break if someone sends me S/MIME
  34% I pretend S/MIME doesn't exist if it shows up
  38% I don't pay attention to S/MIME, but will proxy it or hand it to my application
   4% I pay attention to S/MIME I receive, but don't send any
   0% I don't pay attention to S/MIME I receive, but I do send some
   6% I try to do something useful with S/MIME I receive and send
  12% Other

This is how they answered for multipart/mime:

   2% I break if someone sends me multipart/mime
  24% I pretend multipart/mime doesn't exist if someone sends it to me
  24% I ignore multipart/mime but will proxy it or hand it to my application if it shows up
  10% I try to do something useful with multipart/mime I receive, but I never send it
   4% I ignore multipart/mime that I receive, but I try to do something useful with multipart/mime I send
  24% I try to do something useful with multipart/mime I send and receive
  12% Other

Here is how the endpoints claimed to handle receiving 200 OKs from more than one branch of a forked INVITE:

  36% I send BYEs to all but one branch
  10% I use all of them (perhaps mixing the different media streams locally)
  42% I don't handle this case gracefully
  12% Other

27% of the endpoints did not use symmetric RTP

This is how the endpoints (that actually handled media) described their use of RTCP:

  33% I fully implement RTCP and use the RTCP from my peers
  27% I send some RTCP, and open a port to receive RTCP, but I ignore any packets I receive
   6% I never send RTCP, but I do open a port for receiving (and ignoring) it
  34% I don't even open a port for RTCP

There were 9 SRTP endpoints (down from 12 at the last event). Only 4 of those used sdes.
Interoperability after key exchange was lower than at SIPit 19.

There was only one RTP over DTLS implementation present.

One endpoint claimed support for comedia (but 10 claimed they would send media over TCP).

For hold, the endpoints claimed:

  8%  I don't support hold
  4%  I set the m-line port to 0
 10%  I set the c-line to
 27%  I use the sendonly/recvonly/sendrecv attributes
 15%  I use the s/r/sr attributes,
      but only if I see them in SDP from the other party first,
      otherwise I set the m-line port to zero
 17%  I use the s/r/sr attributes AND set the m-line port to 0
 19%  I don't do any of those things

25% of the endpoints would offer SDP with more than one m-line.
57% would only play one audio stream if they received multiple.

Most proxies are now doing either 3261 or fork-loop-fix loop detection.

Only 30% of the proxies claimed they would forward a request with an unknown RURI scheme when there was a Route header field whose first value is a SIP URI.

25% of the proxies actively participate in session timer.

5 of the 19 proxies present would upgrade from sip: to sips: while forwarding. 6 would downgrade.

6 of the registrars would allow non-sip or sips schemes in contacts.
6 of the registrars claimed to accept an S/MIME signed or encrypted REGISTER request.

Less than half of the b2bua/sbc-like elements could be configured to forward unknown methods. Most could be configured to forward unknown SDP lines.

There were 46 SIP-Events implementations. These were the supported event packages:

 30 refer
 20 message-summary
 14 presence
 14 dialog
  9 reg
  6 conference
  2 ua-profile
  2 gruu-reg-event
  2 kpml

5 supported winfo

4 supported event-list

15 would issue an unsolicited NOTIFY.
27 would respond to an unsolicited NOTIFY with a 200-OK

There were 2 partial-publish/partial-notify implementations

4 implementations supported presence-rules

We repeated the question about which P-headers each implementation actively supported:

  34 P-Asserted-Identity
  21 P-Preferred-Identity
  12 P-Associated-URI
  12 P-Called-Party-ID
  10 P-Access-Network-Info
   8 P-Charging-Vector
   7 P-Visited-Network-ID
   7 P-Charging-Function-Address
   5 P-Media-Authorization
   4 P-User-Database
   4 P-DCS-* (andy of the P-DCS headers)
   1 P-Answer-State