Difference between revisions of "SIPit23 Summary"
Jump to navigation
Jump to search
RjS-legacy (talk | contribs) |
RjS-legacy (talk | contribs) |
||
Line 8: | Line 8: | ||
There were 97 attendees from 37 companies visiting from 19 countries. | There were 97 attendees from 37 companies visiting from 19 countries. | ||
− | I manually surveyed the teams at this event to avoid some of the sampling error we've seen with the use of an automated survey tool at the last few SIPits. Please take care to remember this change in the measurement tool when trying to read trends comparing this report to previous events. In particular, I was careful to avoid counting two products that were essentially the same implementation as different. With that in mind: | + | I manually surveyed the teams at this event to avoid some of the sampling error |
+ | we've seen with the use of an automated survey tool at the last few SIPits. | ||
+ | Please take care to remember this change in the measurement tool when trying to | ||
+ | read trends comparing this report to previous events. In particular, I was | ||
+ | careful to avoid counting two products that were essentially the same | ||
+ | implementation as different. With that in mind: | ||
We had over 50 distinct implementations. | We had over 50 distinct implementations. | ||
− | There were a higher than usual proportion of implementations attending SIPit for the first time at this SIPit. As a result, there was more testing of basic interoperability than we've seen for the last several events. There were still several advanced teams demonstrating interoperability of more complicated scenarios. | + | There were a higher than usual proportion of implementations attending SIPit |
+ | for the first time at this SIPit. As a result, there was more testing of basic | ||
+ | interoperability than we've seen for the last several events. There were still | ||
+ | several advanced teams demonstrating interoperability of more complicated | ||
+ | scenarios. | ||
− | 62% of the UAs present both sent RTCP and paid attention to RTCP they recieved | + | 62% of the UAs present both sent RTCP and paid attention to RTCP they recieved |
+ | this is the first sipit where this has been true for the majority of the UAs. | ||
− | This event saw a (mostly) successful test of ICE between three implementations at the multiparty tests. | + | This event saw a (mostly) successful test of ICE between three implementations |
+ | at the multiparty tests. | ||
− | There were no implementations of the sip-config, sip-consent, or session-policy frameworks. The only people in the room who had even read the sip-config framework documents are regular IETF participants. Even fewer had read sip-consent or session-policy. There is currently a huge gap between specification and implementation for these concepts. (Note - there have been sip-config implemantations at previous events, but the teams that brought them were not able to attend this time). | + | There were no implementations of the sip-config, sip-consent, or session-policy |
+ | frameworks. The only people in the room who had even read the sip-config | ||
+ | framework documents are regular IETF participants. Even fewer had read | ||
+ | sip-consent or session-policy. There is currently a huge gap between | ||
+ | specification and implementation for these concepts. (Note - there have been | ||
+ | sip-config implemantations at previous events, but the teams that brought them | ||
+ | were not able to attend this time). | ||
The roles represented (some implementations act in more than one role): | The roles represented (some implementations act in more than one role): | ||
Line 40: | Line 57: | ||
DTLS none | DTLS none | ||
− | 30% of the implementations supported SIP over IPv6 | + | 30% of the implementations supported SIP over IPv6 (This was significantly down |
− | (This was significantly down from the last few events - I think it is mostly due to the number of very young implementations present.) | + | from the last few events - I think it is mostly due to the number of very young |
+ | implementations present.) | ||
19% supported SIP over IPSec | 19% supported SIP over IPSec | ||
Line 61: | Line 79: | ||
9% gruu-15 | 9% gruu-15 | ||
− | There were only 2 implementations claiming support for Identity. 2 for the dial-string URI (RFC4967), and none for Service URNs (RFC5031). These are all lower than what was reported at previous events - a result of the opportunity to double-check answers during the manual survey. | + | There were only 2 implementations claiming support for Identity. 2 for the |
+ | dial-string URI (RFC4967), and none for Service URNs (RFC5031). These are all | ||
+ | lower than what was reported at previous events - a result of the opportunity | ||
+ | to double-check answers during the manual survey. | ||
− | Many teams expressed intent to implement outbound and gruu once something was published as an RFC, and a strong unwillingness to even try until that happens. | + | Many teams expressed intent to implement outbound and gruu once something was |
+ | published as an RFC, and a strong unwillingness to even try until that happens. | ||
Line 90: | Line 112: | ||
Support for various extensions in the endpoints: | Support for various extensions in the endpoints: | ||
98% RFC3262 100rel | 98% RFC3262 100rel | ||
− | 50% RFC3323 privacy | + | 50% RFC3323 privacy |
− | 36% RFC3327 path | + | 36% RFC3327 path |
7% RFC3840/RFC3841 pref/caller-prefs | 7% RFC3840/RFC3841 pref/caller-prefs | ||
79% RFC3891 replaces | 79% RFC3891 replaces | ||
− | 9% RFC4488 norefersub | + | 9% RFC4488 norefersub |
7% RFC4538 target-dialog | 7% RFC4538 target-dialog | ||
Line 104: | Line 126: | ||
16% supported SRTP - only one had code based on the dtls-srtp work | 16% supported SRTP - only one had code based on the dtls-srtp work | ||
− | Support for multipart/mime increased (38% of the UAs would do something with it on receipt). There were no implementations present testing S/MIME. | + | Support for multipart/mime increased (38% of the UAs would do something with it |
+ | on receipt). There were no implementations present testing S/MIME. | ||
Of the SIP-Events implementations, the following packages were supported: | Of the SIP-Events implementations, the following packages were supported: | ||
Line 119: | Line 142: | ||
There were 8 SIP-Events implementations present supporting winfo. | There were 8 SIP-Events implementations present supporting winfo. | ||
− | 7 of the proxies present implemented some form of loop detection (only 3 have implemented the loop-detection part of fork-loop fix) | + | 7 of the proxies present implemented some form of loop detection (only 3 have |
+ | implemented the loop-detection part of fork-loop fix) | ||
− | There were 5 MSRP clients and one MSRP relay present. All of the clients supported file transfer (3 used file-transfer-mech). Several clients were able to exchange files. Two of the clients were able to exchange instant messages. (Only one had been created with the intent to send instant messages - the rest were file transfer centric.) The embedded-device implementers noted that the decision to not allow a negotiated maximum chunk size (not maximum message size) is causing them significant difficulty. | + | There were 5 MSRP clients and one MSRP relay present. All of the clients |
+ | supported file transfer (3 used file-transfer-mech). Several clients were able | ||
+ | to exchange files. Two of the clients were able to exchange instant messages. | ||
+ | (Only one had been created with the intent to send instant messages - the rest | ||
+ | were file transfer centric.) The embedded-device implementers noted that the | ||
+ | decision to not allow a negotiated maximum chunk size (not maximum message | ||
+ | size) is causing them significant difficulty. | ||
The multiparty STUN/TURN/ICE test saw successful calls using ICE after | The multiparty STUN/TURN/ICE test saw successful calls using ICE after | ||
Line 155: | Line 185: | ||
and transport=tls. We will hold a longer and more rigourous multiparty session | and transport=tls. We will hold a longer and more rigourous multiparty session | ||
focusing on TLS at the next SIPit. | focusing on TLS at the next SIPit. | ||
+ | |||
</pre> | </pre> |
Revision as of 15:15, 23 October 2008
This is an early draft of the summary from SIPit 23. What's below may change in the next few days as I get review and go over the tallies again.
SIPit 23 was hosted by ETSI with technical support from Orange the week of October 13-17, 2008 in Lannion, France There were 97 attendees from 37 companies visiting from 19 countries. I manually surveyed the teams at this event to avoid some of the sampling error we've seen with the use of an automated survey tool at the last few SIPits. Please take care to remember this change in the measurement tool when trying to read trends comparing this report to previous events. In particular, I was careful to avoid counting two products that were essentially the same implementation as different. With that in mind: We had over 50 distinct implementations. There were a higher than usual proportion of implementations attending SIPit for the first time at this SIPit. As a result, there was more testing of basic interoperability than we've seen for the last several events. There were still several advanced teams demonstrating interoperability of more complicated scenarios. 62% of the UAs present both sent RTCP and paid attention to RTCP they recieved this is the first sipit where this has been true for the majority of the UAs. This event saw a (mostly) successful test of ICE between three implementations at the multiparty tests. There were no implementations of the sip-config, sip-consent, or session-policy frameworks. The only people in the room who had even read the sip-config framework documents are regular IETF participants. Even fewer had read sip-consent or session-policy. There is currently a huge gap between specification and implementation for these concepts. (Note - there have been sip-config implemantations at previous events, but the teams that brought them were not able to attend this time). The roles represented (some implementations act in more than one role): 29 endpoints 13 proxy/registrars 8 event servers 7 gateways 2 automaton UAs (voicemail, conference, appserver, etc) 14 b2bua/sbcs 3 UAs with signaling, but without media 5 test/monitoring tool The set of things considered UAs below (the union of the endpoints/b2buas/gateways/etc) consisted of 42 implementations. Implementations using each transport for SIP messages: UDP 100% TCP 93% TLS 48% server-auth, 28% mutual-auth SCTP 11% DTLS none 30% of the implementations supported SIP over IPv6 (This was significantly down from the last few events - I think it is mostly due to the number of very young implementations present.) 19% supported SIP over IPSec For DNS we had support for: Full RFC3263 : 65% (continuing to climb) SRV only : 15% A records only : 13% no DNS support : 7% Support for various items: 72% rport 15% sigcomp 36% enum 13% RFC4320 fixes 13% invfix 63% session-timer 9% outbound (various versions) 9% gruu-15 There were only 2 implementations claiming support for Identity. 2 for the dial-string URI (RFC4967), and none for Service URNs (RFC5031). These are all lower than what was reported at previous events - a result of the opportunity to double-check answers during the manual survey. Many teams expressed intent to implement outbound and gruu once something was published as an RFC, and a strong unwillingness to even try until that happens. 36% of the implementations indicated support for anonymous calling. 24% reported using the Diversion header field. 76% of the implementations made some use of SIP Events. There was a huge upswing in support for the message-summary event. The UAs implemented these methods: 95% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence only) 93% REGISTER 95% NOTIFY <- still a lot of unsolicted NOTIFYs 95% SUBSCRIBE 86% OPTIONS 83% PRACK 77% INFO 72% REFER 72% UPDATE 64% MESSAGE 43% PUBLISH (Note that several of these are b2buas that are not really processing the PUBLISH - the next survey will split those out) Support for various extensions in the endpoints: 98% RFC3262 100rel 50% RFC3323 privacy 36% RFC3327 path 7% RFC3840/RFC3841 pref/caller-prefs 79% RFC3891 replaces 9% RFC4488 norefersub 7% RFC4538 target-dialog There were 6 ICE implementations (and 1 ICE-TCP implementation) There were 6 TURN clients and one TURN server present There were 19 STUN clients (6 were stun-bis) 88% of the UAs supported symmetric RTP 16% supported SRTP - only one had code based on the dtls-srtp work Support for multipart/mime increased (38% of the UAs would do something with it on receipt). There were no implementations present testing S/MIME. Of the SIP-Events implementations, the following packages were supported: 82% message-summary 72% refer 59% presence 8% reg 16% dialog 12% conf There were two RLS servers and 6 clients supporting the event-lists extension present. There were two xcap servers present. There were 8 SIP-Events implementations present supporting winfo. 7 of the proxies present implemented some form of loop detection (only 3 have implemented the loop-detection part of fork-loop fix) There were 5 MSRP clients and one MSRP relay present. All of the clients supported file transfer (3 used file-transfer-mech). Several clients were able to exchange files. Two of the clients were able to exchange instant messages. (Only one had been created with the intent to send instant messages - the rest were file transfer centric.) The embedded-device implementers noted that the decision to not allow a negotiated maximum chunk size (not maximum message size) is causing them significant difficulty. The multiparty STUN/TURN/ICE test saw successful calls using ICE after correcting some implementation issues around authenticating a binding and becoming less strict on parsing SDP (specifically the rtcp attribute). There was some argument over what inputs to use for candidate pairs when one stream (of many) in an offer was rejected in the answer. I asked where people were taking bits from messages to display as caller-id. There were many different kinds of answers, including P-Asserted-Identity if present, then From From display name username part of From uri P-Asserted-Identity only Contact uri Remote IP address P-Asserted-Identity, then Remote-Party-ID, then From From, then Remote-Party-ID, then P-Asserted-Identity Remote-Party-ID then From From then P-Assertid-Identity P-Asserted-Identity, then Reply-To, then From entire From URI Of these, using the From display name occurred most frequently, but not much more than any of the other responses After removing some minor rough edges, the presence multiparty test exercised xcap successfully, modifying resource lists and presence rules. There are still many questions around how to discover the xcap root uri. The TLS multiparty test had several new participants and did not go as smoothly as it has in past events. Most of the issues were with configuration of individual implementations, but there was quite a bit of confusion around the use of sips: and transport=tls. We will hold a longer and more rigourous multiparty session focusing on TLS at the next SIPit.