(also available at www.sipit.net)
SIPit 25 was hosted by the University of New Hampshire
Interoperability Laboratory the week of September 14-18, 2009.
There were 66 attendees from 28 companies visiting from 13 countries.
We had 42 distinct implementations reported in the survey responses.
The roles represented (some implementations act in more than one role)
25 endpoints
7 proxy/registrars
6 b2bua/sbcs
4 dedicated event servers
Implementations using each transport for SIP messages:
UDP 98%
TCP 83%
TLS 38% server-auth, 24% mutual-auth
SCTP 7%
DTLS 2%
36% of the implementations supported IPv6.
There were 6 endpoint and 2 proxy implementations of History-Info
There were 3 outbound client and 1 outbound server implementations
There was only one Identity implementation present
For DNS we had support for:
Full RFC3263 : 75%
SRV only : 15%
A records only : 8%
no DNS support : 2%
Support for various items in the endpoints (including the b2buas):
58% replaces
30% 3489stun
30% diversion
26% path
23% join
19% gruu
19% service-route
19% ipsec
13% 5389stun
10% sigcomp
6% ice
6% sip/stun multiplexing
3% turn
Support for various items in the proxies:
57% path
28% service-route
14% sigcomp
14% ipsec
14% gruu
14% sip/stun multiplexing
14% diversion
There were 4 MSRP and 3 XCAP implementations present.
The endpoints and B2BUAs implemented these methods:
100% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence
only)
94% REGISTER
87% OPTIONS
75% PRACK
74% NOTIFY
77% UPDATE
71% REFER
71% INFO
62% SUBSCRIBE
42% MESSAGE
29% PUBLISH
62% of the UAs present both sent RTCP and paid attention to RTCP
they received
32% of the endpoints present supported SRTP.
There were no dtls-srtp implementations at this SIPit.
Multipart/mime support was down to 32% (from 58% at SIPit 24).
There were no implementations present testing S/MIME.
There were 9 SIP Event Server implementations (4 dedicated, the rest
in
endpoints - not counting endpoints that support events only for
refer).
There were 9 SIP Event Client implementations (again, not counting
endpoints that only support events for refer).
These event packages were supported:
Server Client
3 6 message-summary
2 3 reg
0 1 ua-profile
3 4 dialog
1 0 reg-gruu
6 3 presence
2 1 presence.winfo
1 1 xcap-diff
These packages were supported with the eventlist extension:
Server Client
1 2 dialog
0 1 presence
1 1 reg
There were 4 implementations that would send unsolicted NOTIFYs
Five of the proxies present still rely only on max-forwards.
There were two implementations of fork-loop-fix, but no
implementations of max-breadth.
Multiparty tests (Reports contributed by Ole Johansson and Byron
Campen)
==========
* TLS/SRTP
The TLS multiparty test made a lot of progress compared with earlier
events.
Olle Johansson coordinated the development of a new set of automated
self-tests
that were available througout the week and used during the
multiparty tests.
The tests included various certificate errors and testing of support
of
subjAltName X.509 extensions. Many implementations succeeded in the
available
tests, but several happily accepted invalid certificates and started
a SIP
transaction. During the test we had four implementations of SRTP, all
supporting SDES. There were a few successful call setups, but not in
every
possible direction.
* Early media
The Early media tests where mostly run with automatic self-tests put
together
by the participants. Results varied, and discussion continues on
what is
reasonable to do when a UA receives multiple 183 Session Progress
with media
streams from multiple servers. The participating implementations
reacted iv
various ways, from not at all to mixing all streams into one.
* Spiral
During the spiral test, an issue with Record-route headers and TLS
was encountered.
If the recorded route is only an IP address, there's nothing to
match with the
subject of the TLS certificate in the host contacted as a result of
the route header,
unless there's a FQDN in the route header instead of an IP address.
* Outbound
The Outbound implementations worked very well together. This
multiparty
test exercised these scenarios:
o Client registers with proxy/registrar esablishing a TCP flow.
Both inbound and outbound calls work.
o Client registers with registrar through edge proxy establishing a
TCP flow.
Both inbound and outbound calls work.
o Client sets up two TCP flows through a pair of edge proxies,
inbound and
outbound calls work. Failover (an edge proxy goes down) did not
work as
expected due to a client keepalive implementation issue.
_______________________________________________
RAI mailing list
RAI at ietf.org
https://www.ietf.org/mailman/listinfo/rai