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-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
