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)
4 dedicated event servers
Implementations using each transport for SIP messages:
TLS 38% server-auth, 24% mutual-auth
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):
6% sip/stun multiplexing
Support for various items in the proxies:
14% sip/stun multiplexing
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)
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:
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:
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)
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
* 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.
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.
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.