https://www.sipit.net/index.php?title=SIPit19_Summary&feed=atom&action=historySIPit19 Summary - Revision history2024-03-29T14:19:49ZRevision history for this page on the wikiMediaWiki 1.35.2https://www.sipit.net/index.php?title=SIPit19_Summary&diff=1340&oldid=prevRjS-legacy: New page: <pre> SIPit 19 took place Oct 16-20, 2006 at the University of New Hampshire InterOperability Laboratory (www.iol.unh.edu). There were 140 attendees from 73 companies visiting from 16 cou...2007-08-24T21:48:45Z<p>New page: <pre> SIPit 19 took place Oct 16-20, 2006 at the University of New Hampshire InterOperability Laboratory (www.iol.unh.edu). There were 140 attendees from 73 companies visiting from 16 cou...</p>
<p><b>New page</b></p><div><pre><br />
SIPit 19 took place Oct 16-20, 2006 at the University of New Hampshire InterOperability Laboratory (www.iol.unh.edu).<br />
<br />
There were 140 attendees from 73 companies visiting from 16 countries present.<br />
There were 79 teams and 90 distinct implementations.<br />
<br />
The Interoperability Laboratory did a spectacular job of providing a rock-solid network for us to test on.<br />
(For those who haven't been to a SIPit, it is a particularly intense network torturing environment).<br />
<br />
The majority of the spec-arguments during testing centered around how to handle early media and early dialogs.<br />
There was also a non-trivial subset of the implementers that were confused about whether REGISTER and PUBLISH<br />
create dialogs (much of this confusion seems to come from the presence of to-tags in the 200 OK responses to<br />
REGISTER in the examples in 3261). There were a number of interesting questions about edge cases that I will<br />
send to the appropriate IETF lists separately.<br />
<br />
We tried something different for collecting data for this report at this SIPit. We utilized a web-based<br />
automated survey tool. As a result, we collected information on more questions than we usually do, so this<br />
report is a bit long. A side-effect is that the accuracy of the information is probably a little lower. Almost<br />
all of what's below is self-reported, and its unavoidable that for any given question an implementer or two<br />
didn't understand, or didn't know the answer. So, with an appropriate level of respect for errors in sampling, here's<br />
what we found:<br />
<br />
The roles represented (some implementations act in more than one role):<br />
36 endpoint<br />
19 proxy/registrar<br />
8 standalone proxy<br />
4 redirect server<br />
4 gateway <br />
15 automaton UA (voicemail, conference, etc.)<br />
17 b2bua/sbc<br />
6 ua w/ signalling but no media<br />
8 test/monitoring tool<br />
<br />
Implementations using each transport for SIP messages:<br />
UDP 100%<br />
TCP 82%<br />
TLS 45% (server auth only)<br />
TLS 36% (server or mutual auth)<br />
SCTP 6%<br />
DTLS 0%<br />
<br />
10% of the implementations supported SIP over multicast.<br />
30% supported SIP over IPv6.<br />
<br />
70% of the implementations correctly reassembled fragmented UDP.<br />
<br />
Proper use of DNS for SIP continues to rise:<br />
Full RFC3263 use of DNS 59%<br />
SRV only 14%<br />
A records only 15%<br />
no DNS support 12%<br />
<br />
Support for various items:<br />
32% ENUM<br />
65% rport<br />
30% multiplexing SIP/STUN<br />
14% SIGCOMP<br />
25% RFC4320 fixes<br />
14% Identity<br />
30% connect-reuse<br />
<br />
<br />
14 of the implementations claimed support for outbound. Interoperability around this draft was fairly low, but the implementers are aggressively improving it.<br />
<br />
15 implementations claimed support for some version of GRUU. Nothing worked together before code changes at the event. By the end a few teams were getting scenarios to work.<br />
<br />
Only 3 implementations were attempting to support the consent framework.<br />
<br />
The endpoints implemented these methods:<br />
100% INVITE and ACK<br />
100% CANCEL<br />
100% BYE<br />
96% REGISTER<br />
81% OPTIONS<br />
76% SUBSCRIBE<br />
80% NOTIFY<br />
56% PRACK<br />
52% MESSAGE<br />
74% INFO<br />
63% UPDATE<br />
80% REFER<br />
41% PUBLISH<br />
<br />
The endpoints implemented these extensions:<br />
67% RFC3891: replaces<br />
63% RFC4028: session-timer<br />
17% RFC3327: path<br />
11% RFC3840: pref<br />
4% RFC3841: caller-prefs<br />
26% RFC3323: privacy<br />
6% RFC4538: target-dialog<br />
7% RFC4488: norefersub<br />
56% RFC3262: 100rel<br />
3% RFC3994: indication of message composition<br />
<br />
44% of the endpoints implemented sipping-cc-transfer<br />
<br />
When asked about STUN support, the client implementations replied:<br />
6% I implement all the client requirements of draft-ietf-behave-rfc3489bis<br />
6% I implement some, but not all, of the client requirements of draft-ietf-behave-rfc3498bis<br />
13% I implement all of the client requirements of RFC3489<br />
7% I implement some, but not all, of the client requirements of RFC3489<br />
59% I do not implement STUN as a client<br />
9% Other<br />
<br />
There are still a large number of endpoints (25%) that do not use symmetric RTP.<br />
<br />
There were only a couple of TURN client implementations. We had several STUN servers and 2 TURN servers. There were only 3 ICE implementations, and only one of those was at the current version. Interoperability was reasonably high, but not seamless. The issues with interoperability were all implementation problems.<br />
<br />
I asked the endpoint implementations to characterize their handling of S/MIME:<br />
15% I break if someone sends me S/MIME<br />
22% I pretend S/MIME doesn't exist if it shows up<br />
35% I don't pay attention to S/MIME, but will proxy it or hand it to my application<br />
7% I pay attention to S/MIME I receive, but don't send any<br />
2% I don't pay attention to S/MIME I receive, but I do send some<br />
4% I try to do something useful with S/MIME I receive and send<br />
15% Other<br />
<br />
I asked the same question about multipart mime support:<br />
7% I break if someone sends me multipart/mime<br />
20% I pretend multipart/mime doesn't exist if someone sends it to me<br />
19% I ignore multipart/mime but will proxy it or hand it to my application if it shows up<br />
15% I try to do something useful with multipart/mime I receive, but I never send it<br />
4% I ignore multipart/mime that I receive, but I try to do something useful with multipart/mime I send<br />
22% I try to do something useful with multipart/mime I send and receive<br />
13% Other<br />
<br />
48% of the endpoint implementations claimed to correctly handle merged requests.<br />
<br />
Here is how the endpoints said they handled receiving 200 OKs from more than one branch of a forked INVITE:<br />
54% I send BYEs to all but one branch<br />
6% I use all of them (perhaps mixing the different media streams locally)<br />
16% I don't handle this case gracefully<br />
11% Other<br />
<br />
Here is a sample of how endpoint implementors replied when asked how they handled early media from more than one leg:<br />
* We allow multiple RTP streams with an affinity to the last one.<br />
* First Media received is played until 200.<br />
* The first 183 will be honored in case of the UAC. The rest will be dropped.<br />
* Allow media from only negotiated address. Ignore media until negotiated (offer-answer exchanged).<br />
* Listen to most recently started stream.<br />
* all early media will passed on to the UA.<br />
* pick the one who most recently sent me a criticial threshold of media.<br />
* Play only one media stream and ignore others.<br />
* The last sdp received override previous one.<br />
* First 18x message goes through, rest dropped.<br />
* Open voice only with the first one, but answer all of the 18x<br />
* We will use the first recieved<br />
* I ignore early media<br />
* All get relayed - (all rendered leave final choice to recipient UA)<br />
* Last early media replaces previous<br />
* We update media as the 18x's come in. 200OK media will be the confirmed media channel.<br />
* Take the first<br />
<br />
Interestingly, 15% of the endpoints supported DHCP option 120.<br />
<br />
This is how the endpoints (that actually handled media) described their use of RTCP:<br />
38% I fully implement RTCP and use the RTCP from my peers<br />
20% I send some RTCP, and open a port to receive RTCP, but I ignore any packets I receive<br />
18% I never send RTCP, but I do open a port for receiving (and ignoring) it<br />
24% I don't even open a port for RTCP<br />
<br />
There were 12 (roughly 25%) endpoints testing SRTP support. Keying was predominantly sdes.<br />
Interoperability is not yet high, but more pairs got something working than at SIPit 18.<br />
<br />
There were only 4 endpoints supporting comedia.<br />
<br />
There were 22 proxies present.<br />
<br />
The proxy implementers characterized their handling of infinite loop prevention this way:<br />
0% I implement loop detection as per the sip-loop-fix draft<br />
45% I perform RFC3261 loop detection<br />
45% I don't loop detect, but do pay attention to max-forwards<br />
10% I don't loop detect or look at max-forwards<br />
<br />
I asked proxies "Will you proxy a request with a RURI containing an unknown scheme<br />
(such as splork:) when there is a Route header field whose first value is a SIP URI<br />
you can resolve?" and got these responses:<br />
32% Yes<br />
68% No<br />
<br />
Half of the proxies in attendence actively participated in session-timer.<br />
<br />
There were 9 implementations (41%) that categorized themselves as proxies that would not forward an unknown method.<br />
<br />
Two-thirds of the proxies claimed to properly handle SIPS.<br />
<br />
None of the proxies made use of 3840 or 3841 information (capabilities and caller-prefs)<br />
<br />
There were 19 registrars.<br />
<br />
7 of the registrars (37%) accepted non-sip or sips Contacts in a registration<br />
11 (58%) would accept a REGISTER request that had a multipart-mime body (almost all ignored it)<br />
1 would accept an S/MIME signed or encrypted register<br />
<br />
Half of the border-elements (B2BUA/SBC-like implementations) could be configured to forward unknown methods.<br />
75% could be configured to forward unknown SDP lines<br />
<br />
There were 41 SIP Events implementations present<br />
15 (37%) of them would send unsolicted notifies (there were 2 more things that ONLY sent unsolicited notifies).<br />
<br />
They supported these event packages:<br />
29 refer<br />
23 message-summary<br />
14 presence<br />
12 dialog<br />
5 reg<br />
4 ua-profile (sipping-config-framework)<br />
4 conference<br />
2 reg gruu extension (sipping-gruu-reg-event)<br />
2 certificate/credentials (sip-certs)<br />
1 session-spec-policy (sipping-policy)<br />
1 kpml<br />
0 vx-rtcpxr (sipping-rtcp-summary)<br />
<br />
Only 4 (10%) supported winfo<br />
<br />
4 supported event-list<br />
<br />
37% of the implementation supporting SIP Events supported PUBLISH<br />
<br />
Of the 14 implementations supporting event presence, there was support for the following document formats:<br />
12 base PIDF only<br />
2 RPID<br />
0 CIPID<br />
0 timed presence<br />
0 PIDF-LO<br />
0 prescaps-ext<br />
<br />
5 implementations supported XCAP<br />
7 supported pres-rules<br />
<br />
I asked all the implementations present which P- headers they actively supported:<br />
(I suspect many of the respondents who passively let the headers pass or ignore them answered yes, so these<br />
numbers, more than any others of the above are probably inflated)<br />
28 P-Asserted-Identity<br />
21 P-Preferred-Identity<br />
10 P-Called-Party-ID<br />
9 P-Associated-URI<br />
9 P-Access-Network-Info<br />
8 P-Charging-Vector<br />
6 P-Visited-Network-ID<br />
5 P-Charging-Function-Address<br />
4 P-User-Database<br />
4 P-DCS-* (any of the P-DCS headers)<br />
3 P-Media-Authorization<br />
<br />
</pre></div>RjS-legacy