Re: [sipcore] SIPit27 Summary

Henry Sinnreich <henry.sinnreich@gmail.com> Fri, 19 November 2010 14:57 UTC

Return-Path: <henry.sinnreich@gmail.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B898C3A67F2; Fri, 19 Nov 2010 06:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94bPkwtaJhJI; Fri, 19 Nov 2010 06:57:49 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id EBA953A67E5; Fri, 19 Nov 2010 06:57:48 -0800 (PST)
Received: by gxk27 with SMTP id 27so2923585gxk.31 for <multiple recipients>; Fri, 19 Nov 2010 06:58:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=jaOmT2GK1RjRhWchVNTG1Jz14pa08AelGM1B9uNUW/g=; b=W/dgtg1TlgkGKOyquVym+PNWFI/L9riulhNwvoq8sEsQrCdpIb/A3tVa7c0NCHUgl1 J1/kA0sEC4UiIoBupzecLGDLkFIxajj6lLy8OdtvtGP7cegRJG7RRDlezQ++xy7amS5c Q0EDKa5hNRhe7piNi5d05e3mob0Le+8DIVpe4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=naC1ZViPzmgPSUWO1CMzANVrueQ7lbyz4IGKOyvH3G9NIz0vPRNr+DtEokoFkDa9Wd gD6JUsjJamWgm4X7S0oWhKPS+yEG96+ki9t/g0pzta2/REnlmY0Y8obZf0056W+hrm4g z3nPGGqa2+TcrVd3Cyo1qTA/XnWpMT8O7XDds=
Received: by 10.150.54.14 with SMTP id c14mr4005940yba.57.1290178718473; Fri, 19 Nov 2010 06:58:38 -0800 (PST)
Received: from [10.0.1.2] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id m12sm1133445ybn.12.2010.11.19.06.58.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 06:58:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.27.0.100910
Date: Fri, 19 Nov 2010 08:58:34 -0600
From: Henry Sinnreich <henry.sinnreich@gmail.com>
To: Robert Sparks <rjsparks@nostrum.com>, <rai@ietf.org>, SIPCORE <sipcore@ietf.org>
Message-ID: <C90BECBA.159A0%henry.sinnreich@gmail.com>
Thread-Topic: [sipcore] SIPit27 Summary
Thread-Index: AcuH+jyxUqlXTY2D9Uq6quYrFVu9Jw==
In-Reply-To: <E41EE386-9C5C-4A84-B431-BA02DFD0AD4B@nostrum.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [sipcore] SIPit27 Summary
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2010 14:57:50 -0000

This is an excellent report and attests a very successful SIPit.

Thanks for sharing and Kudos for all the work,

Henry


On 11/18/10 9:09 PM, "Robert Sparks" <rjsparks@nostrum.com> wrote:

> (Also available at <https://www.sipit.net/SIPit27_Summary>)
> 
> <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 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.
> </pre>
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore