[RAI] SIPit 30 summary
Robert Sparks <rjsparks@nostrum.com> Fri, 22 February 2013 19:26 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7706F21F8C4C for <rai@ietfa.amsl.com>; Fri, 22 Feb 2013 11:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf9LJJVO1njn for <rai@ietfa.amsl.com>; Fri, 22 Feb 2013 11:26:50 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9272121F8BE0 for <rai@ietf.org>; Fri, 22 Feb 2013 11:26:50 -0800 (PST)
Received: from unnumerable.local (ip-64-134-182-173.public.wayport.net [64.134.182.173]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1MJQmuB084909 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <rai@ietf.org>; Fri, 22 Feb 2013 13:26:50 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <5127C671.2080300@nostrum.com>
Date: Fri, 22 Feb 2013 14:26:41 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rai@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 64.134.182.173 is authenticated by a trusted mechanism)
Subject: [RAI] SIPit 30 summary
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2013 19:26:53 -0000
SIPit 30 was hosted by Cisco in Raleigh-Durham, North Carolina, the week of February 18-22, 2013. There were 58 attendees from 24 companies visiting from 8 countries. We had 38 distinct implementations. This event saw both successful srtp-dtls calls and successful exchange of media using the RFC6716 (opus) codec. The roles represented (some implementations act in more than one role) 31 endpoints 7 proxy/registrars Most of the b2buas attending this event were not attempting to appear to be proxys. Implementations using each transport for SIP messages: UDP 97% TCP 100% TLS 84% (19% server-auth-only) SCTP 8% DTLS 5% 55% of the implementations present supported IPv6. There was one RFC4474 Identity implementation present. For DNS we had support for: Full RFC3263 : 76% SRV only : 11% A/AAAA records only : 11% no DNS support : 0% With more IPv6 enabled endpoints its becoming clearer that we need to improve the specification for finding sip servers (RFC3263) when dual-stacked. The implementations at this event had a mix of policies, some favoring A over AAAA, and vice-versa. Very few tried to make constructive use if the records when both were present. Support for various items in the endpoints: 71% replaces 39% diversion 35% 3489stun 32% ice 32% 5389stun 32% turn 26% sip/stun multiplexing 26% history-info (there were no implementations of 4244bis) 24% outbound 19% gruu 16% path 13% join 13% service-route Support for various items in the proxy/registrars: 57% diversion 43% outbound 43% path 29% sip/stun multiplexing 29% gruu 29% history-info 0% service-route The endpoints and B2BUAs implemented these methods: 100% INVITE, CANCEL, ACK, BYE 97% OPTIONS 90% REFER 85% NOTIFY 81% UPDATE 80% REGISTER 74% INFO 71% PRACK 71% SUBSCRIBE 42% MESSAGE 42% PUBLISH 100% of the implementations sent RTP from the port advertised for reception (symmetric-rtp). one implementations required the other party to use symmetric-rtp. 90% of the UAs present both sent RTCP and paid attention to RTCP they received. 81% of the endpoints present supported SRTP using sdes. There were 5 endpoints present that supported DTLS-SRTP (not counting the RTCWeb implementations that just came for Tuesday) There was 1 endpoint present that supported SRTP using Mikey 55% of the endpoints supported multipart/MIME. There were no implementations present with S/MIME support. 45% followed RFC4320 (corrections to the non-INVITE transaction) 39% of the implementations present followed RFC6026 (corrections to the INVITE transaction) Not counting implementations that support events only for REFER: There were 5 SIP Event Server implementations There were 14 SIP Event Client implementations These event packages were supported: Server Client 2 7 presence 1 2 presence.winfo 2 8 message-summary 1 4 dialog 0 2 reg 3 4 conference 3 3 kpml Four of the proxies present still rely only on max-forwards. There were three implementations of fork-loop-fix (rfc5393), but no implementations of max-breadth. Multiparty tests (Notes provided by Olle Johansson, Richard Barnes, Balint Menyhart) * RTCWeb The RTCweb tests at SIPit involved two browsers, a proxy with a websocket implementation, a SBC with websocket support and one "traditional" desktop SIP UA with SAVPF support. The open source JSSIP library for SIP over Websockets was used for testing of the sip-over-websockets IETF draft. In addition a vendor-specific SIP over Websockets implementation was used. We successfully set up calls between browsers with both video and audio over both the proxy and the SBC. During the test, we invited a large set of SIP UA's to test receiving INVITEs with these large SDPs to test how they responded. A few ones responded incorrectly with "bad media type", one parsed via headers and failed with a "400" message and most of the UA's correctly responded with a "488" response code. The second part of the RTCweb multiparty test focused on ICE. Using RFC 1918 networks with the same network address and different addresses. All tests worked, even with two clients in different networks using the same private IP address. * SRTP We had a focused test on SRTP, with a mix of sdes and dtls-srtp capable devices. Most implementations did the right thing when offered a keying mode they did not support. There were a few implementations that responded oddly to offers containing only SAVPF. One implementation of dtls-srtp initially didn't understand SHA-256 fingerprints, and failed correctly. That implementation was able to update its code during the event and establish a successful call. We should look at what we need to specify to make it less likely that something in the wild would not understand SHA-256. We exercised multiple branches with early secure media, and calls where one leg provided early secure media and a different leg answered, providing secured confirmed media. * TLS During the test session Olle Johansson gave a presentation on the basics of TLS and how it is used in SIP. After that, user agents focused on the SIPit TLS-O-Matic(TM) self tests as well as server-to-server connections. A number of issues were discovered including UAs not understanding NAPTR, not validating correctly with the URI but using the IP address the hostname resolved to in order to validate against the contents in the server certificate. * ICE/Outbound/Nat Traversal During the tests we had one outbound server implementation and a few clients supporting one-legged outbound connections. We also tried testing with two edge proxies, but due to bugs in the server implementation and the lack of clients supporting for more than one edge proxy, these tests were not successful. ICE tests were done with a lab network with multiple NATs, v6 only networks, v6 native, with natted v4, and two networks with the same RFC1918 addresses. We tested many combinations of multiple nats in the paths. Questions and observations that arose during this testing: - When ALGs might be in the path, it's possible that when ICE fails, an offer without ICE might succeed. Should elements try a reINVITE without ICE when ICE fails? - There were implementations that used a component id other than 1 on a single stream media line (BFCP in this case) that caused peers to fail. - There was a RFC5761 implementation that set the rtcp fallback port to the rtp port leading to an interesting failure. - The testers observed edge cases when handling re-INVITEs during ICE processing. There was discussion of buffering any such received re-INVITE and wait to service it when ICE completes, raising the issue of what to do with UPDATEs that cannot be buffered in the same way. 491 was offered as an alternative, but experience shows that it is often badly handled. The whole issue was raised by implementations trying to lock down to a single codec straight after the original INVITE (hence, when ICE is running). These implementors were not yet aware of the trickle-ice discussions. - The participants ran into issues with NATs evil enough to map RTP and RTCP to the same reflexive address. Implementations should watch out to detect that and not end up pairing an RTP candidate with an RTCP candidate for example! (The same issue may exist between media lines, pairing up audio with video for example.) Other than being careful, the discussed solutions were: rtcp-mux (slight improvement, as RTP and RTCP cannot be confused, but media lines can still be paired up badly between each other) and TURN, which can solve the problem by using a single pin hole, by targeting every media stream and every component to the same port on the TURN server. * General Interop Issues - The BCP for 3rd party call control (RFC3725) recommends sending an offer in an INVITE with no m-lines instead of using delayed-offer-answer. However, many endpoints return a 488 to such an offer. - Many implementations would give up on a call if the offer had a v6 c-line and the answer had a v4 c-line even when both ends were dual-stacked. - There was more than one implementation that generated SDP with a single m-line with a zero port, but no c-line anywhere in the SDP.
- [RAI] SIPit 30 summary Robert Sparks