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
Sip-implementors cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
|
