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:
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
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