[Sip] SIPit 20 survey summary

[Robert Sparks <[e-mail]>]

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, I 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:
    100% INVITE, CANCEL, ACK, BYE
     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 0.0.0.0
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

I 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

Let me know if there are other questions you'd like to see asked next  
time.

RjS


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip