Difference between revisions of "SIPit27 Summary"
Jump to navigation
Jump to search
(Created page with '<pre> SIPit 27 was hosted by ETSI in cooperation with ITRI in Taiwan, Taipei the week of November 15-19, 2010. There were 54 attendees from 22 companies visiting from 10 countri…') |
(No difference)
|
Latest revision as of 03:08, 19 November 2010
SIPit 27 was hosted by ETSI in cooperation with ITRI in Taiwan, Taipei the week of November 15-19, 2010. There were 54 attendees from 22 companies visiting from 10 countries. We had 34 distinct implementations. We had several first-time attendees at this event, many bringing engineering prototypes. The largest change from the previous SIPit was in the level of support for RFC5626 (Outbound). Nearly a quarter of the implemenations present included an outbound implementation. Interestingly, about half of those supported using outbound only with TCP. Multiparty testing uncovered a potential problem with that specification (see the notes below). The roles represented (some implementations act in more than one role) 25 endpoints 9 proxy/registrars/b2bua/sbcs 1 dedicated event server Implementations using each transport for SIP messages: UDP 100% TCP 86% TLS 74% server-auth, 62% mutual-auth SCTP 15% DTLS 0% 53% the implementations present supported IPv6. There were no Identity implementations present. For DNS we had support for: Full RFC3263 : 68% SRV only : 21% A records only : 11% no DNS support : 0% Support for various items in the endpoints 64% replaces 32% 3489stun 24% outbound 24% turn 24% path 20% ice 20% gruu 20% diversion 16% service-route 16% 5389stun 16% history-info (there were no implementations of 4244bis) 12% sip/stun multiplexing 12% sigcomp 12% join Support for various items in the proxies: 57% path 29% service-route 29% sigcomp 29% diversion 14% gruu 14% sip/stun multiplexing 14% history-info The endpoints and B2BUAs implemented these methods: 100% INVITE, CANCEL, ACK, BYE 96% REGISTER 96% OPTIONS 92% REFER 92% NOTIFY 88% SUBSCRIBE 80% UPDATE 80% INFO 76% PRACK 52% MESSAGE 48% PUBLISH 80% of the implementations sent RTP from the port advertised for reception (symmetric-rtp). 3 of the implementations required the other party to use symmetric-rtp. 80% of the UAs present both sent RTCP and paid attention to RTCP they received. 60% of the endpoints present supported SRTP using sdes. There was one SRTP-mikey implementation present, and two ZRTP implementations. There were no dtls-srtp implementations at this SIPit. 40% of the endpoints supported multipart/mime. There were no implementations present with S/MIME support. 32% of the implementations present followed RFC6026 (corrections to the INVITE transaction) 52% followed RFC4320 (corrections to the non-INVITE transaction) There were 3 SIP Event Server implementations (not counting endpoints that support events only for refer). There were 7 SIP Event Client implementations (not counting endpoints that support events only for refer). These event packages were supported: Server Client 2 6 presence 1 4 presence.winfo 0 2 message-summary 1 3 dialog 1 3 reg 0 1 conference 1 1 xcap-diff 0 1 reg-gruu These packages were supported with the eventlist extension: Server Client 1 3 presence There was one implementation of event-rate-control, and two implementations of subnot-etags present. There was one Info-Packages implementations present using an unregistered payload type. Four of the proxies present still rely only on max-forwards. There was one implementation of fork-loop-fix, but no implementations of max-breadth. Multiparty tests (notes contributed by Eoin McLeod and Byron Campen) The spiral and forking tests continue to be helpful, uncovering bugs in new endpoint implementations, particularly when there are multiple early-media legs or 200 OKs from multiple branches. The more notable interoperability problems this time were related to Route/Record-Route, especially when making a transition from IPv4 to IPv6 across a proxy. Most of those problems were resolved when the implementations involved followed the double record-routing recommendations in RFC5658. That said, when there were many IPv6 hops contributing to the route-set, we began running into maximum message-size assumptions in the endpoints. The team working on this multiparty created a clever self-testing tool allowing an endpoint to request a number of v6 and v4 hops by using the dialed digits (e.g. 664664446@). The end of the forking test focused on TLS. We constructed a configuration exercised a TLS connection between each of the partipating elements with a single SIP request (see <https://www.sipit.net/files/Forking_tls---digraph%20topology2.png>). The majority of the elements involved correctly validated the certificates when establishing connections. There were some issues with Record-Route values being created that did not match the certificate contents for the proxy. We exercised the proxy-doom (see RFC5393) test scenario utilizing a larger number of participating AoRs. Even with the loop detection mechanisms in that specification, the number of messages induced utilizing 30 AoRs flooded the participants in this test, pointing to the need for implementation of Max-Breadth. The STUN/TURN/ICE multiparty saw successful negotiation of the use of reflexive candidates at each endpoint. We exercised successful calls between endpoints supporting Outbound and those that didn't (but both supporting ICE). We induced a successful call with media traversing a TURN trapezoid by putting two endpoints behind different NATS, configuring them to not advertise reflexive candidates, and using firewalls to prevent each endpoint from seeing the other endpoint's TURN server directly. We had a significant number of Outbound implementations present, and exercised correct interaction between multiple edge-proxy and registrar implementations. A few of the UAs participating could only establish one flow. The participants discovered a potential problem in RFC5626 - the conditions under which an authoritative proxy/register is allowed to try a second (or subsequent) flow when receiving an error on the active flow may be incorrect. Currently, section 7 of RFC5626 restricts this to when the proxy has received a 430, a 408, or a transport failure. It does not allow quick failover if the proxy receives a 503, or a 480 that may have resulted form a 503 at some proxy between the edge proxy and the authoritative proxy/registrar. The characterization of all responses other than 430 or 408 meaning "The targeted instance has already provided its response." may be incorrect. The next SIPit's Outbound multiparty will focus on Flow-Timer behavior. The SRTP multiparty test continues to expose issues with how different implementations currently achieve "best-effort" security using SDES. Some implement RTP/SAVP, others implement RTP/AVP with crypto attributes. We encountered some issues with secure RTCP - even if 32-bit keys are negotiated for RTP, the RTCP still needs to use 80-bit keys. One implementation confused the flag indicating unencrypted SRTCP with meaning RTCP (hence leaving out the authentication hash). We spent some time late in the event introducing torture tests, and unusual messages into the network (for example, sending an unsolicted 200 OK to an INVITE to the broadcast address, which stimulated BYEs from a few implementations). In general, the implementations at the event handled (or ignored) these messages correctly, but enough didn't that we will continue to try these at the next several events.