FYI - the summary from SIPit regards Klaus -------- Original-Nachricht -------- Betreff: [RAI] SIPit26 summary Datum: Fri, 4 Jun 2010 13:50:50 -0500 Von: Robert Sparks <rjsparks(a)nostrum.com> An: rai(a)ietf.org SIPit 26 was hosted by Edvina and TANDBERG in Kista, Sweden the week of May 17-21, 2010. There were 67 attendees from 28 companies visiting from 15 countries. We had 42 distinct implementations. There was a huge upswing in the number of TLS and SRTP implementations at this event (and IPv6 support continues to grow steadily). There was also a large upswing in ICE and TURN implementations. The roles represented (some implementations act in more than one role) 29 endpoints 13 proxy/registrars/b2bua/sbcs 5 dedicated event servers I focused more on helping with the multiparty tests and specification discussions and did not review each survey response with its team as closely at this event as I have in the past few. As a result, please be cautious of a little more uncertainty in these values. Implementations using each transport for SIP messages: UDP 98% TCP 98% TLS 81% server-auth, 57% mutual-auth SCTP 21% DTLS 0% Just over half of the implementations present supported IPv6. There were three Identity implementations present For DNS we had support for: Full RFC3263 : 86% SRV only : 5% A records only : 2% no DNS support : 7% Support for various items in the endpoints 55% replaces 38% 3489stun 31% ice 24% gruu 21% sip/stun multiplexing 21% turn 17% diversion 17% history-info 17% path 17% ipsec 17% sigcomp 15% 5389stun 14% service-route 10% join Support for various items in the proxies: 38% path 23% service-route 15% sigcomp 31% ipsec 31% gruu 15% sip/stun multiplexing 31% diversion 0% history-info There were 2 MSRP and 2 XCAP implementations (one with xcap-diff support) present. The endpoints and B2BUAs implemented these methods: 100% INVITE, CANCEL, ACK, BYE 90% REGISTER 90% OPTIONS 84% REFER 79% NOTIFY 79% UPDATE 69% INFO 66% SUBSCRIBE 55% PRACK 52% MESSAGE 48% PUBLISH 79% of the implementations sent RTP from the port advertised for reception (symmetric-rtp). 4 of the implementations required the other party to use symmetric-rtp. 72% of the UAs present both sent RTCP and paid attention to RTCP they received 55% of the endpoints present supported SRTP - all were using sdes. There were no dtls-srtp implementations at this SIPit. 45% of the endpoints supported multipart/mime. There was one implementation present with S/MIME support. There were 10 SIP Event Server implementations (not counting endpoints that support events only for refer). There were 13 SIP Event Client implementations (again, not counting endpoints that only support events for refer). These event packages were supported: Server Client 8 11 presence 4 7 presence.winfo 4 8 message-summary 5 6 dialog 0 3 reg 1 2 conference 1 1 xcap-diff 1 1 kpml 0 1 ua-profile 0 1 reg-gruu These packages were supported with the eventlist extension: Server Client 3 1 presence There were two Info-Packages implementations present. One was using a proprietary payload type. The other was reusing a SIP-Events package. Six of the proxies present still rely only on max-forwards. There were three implementations of fork-loop-fix, but no implementations of max-breadth. Multiparty tests (Reports contributed by Mark Thompson, Eoin McLeod, and Olle Johansson) * Forking Teams coalesced quickly into a working topology that was successful in having all forked targets ringing in parallel. With different UAs injecting the call, a number of different implementation issues arose, including: some UAs could not process sdp offers with multiple instances of the same media type in (e.g. 1x Audio, 2x Video, 2x Application). When stripped back to 1x Audio, 2x Video the situation improved, but even then some would only ring if there was at most one m-line of each type. some UAs could not handle messages greater than 2048 bytes (sdp payload and SIP header overhead). Rather than returning 513 Message Too Large, the UAs in question would silently discard the request. one UA implementation present elected to BYE early dialogs for forks that they do not wish to be answered having successfully established at least one confirmed dialog. The dialog-stateful outbound proxy in this test successfully survived the race condition by failing with a 481 Call/Transaction Does Not Exist response. one UA implementation incorrectly assumed that the To header could be used for request targeting rather than the Request-URI. This assumption led to them not being able to participate as the recipient of re-targeted call forks. one proxy implementation present, when configured with both IPv4 and IPv6 DNS servers to query, would stall request forwarding until all DNS requests had been resolved. Where one of the configured servers was unavailable or slow to respond, the entire call setup would suffer significant latency despite there being sufficient candidates available to route toward. The test procedure was then updated so that the multiple answer edge condition could be tested: the link between the top-most forking proxy and its downstream forks was disconnected whilst all signaled UAs were instructed to answer. Upon reconnecting the network, the forking proxy would receive multiple 200 OK responses to the initial request. most UA implementations placed as originators of the call were shown to successfully ACK-BYE the undesired alternative answers whilst maintaining the first responder's confirmed dialog. at least one UA implementation did not respond to subsequent 200 OK responses establishing confirmed dialogs, instead discarding them as if they were not received resulting in re-transmits and eventual timeout. * Loops/Spirals Implementations all behaved well during the basic loops and spirals tests using multiple protocols on IPv4 only. When we introduced IPv6 into some hops, several proxy and endpoint implementations would not recognize messages as valid when they failed to parse the IPv6 addresses in Vias or Record-Routes that should have just been opaque bits to them. We constructed a loop with 3 of the participating B2BUA implementations and discovered that none of them were decrementing Max-Forwards (some were resetting the value to 70) or performing any other type of loop-detection. * SRTP There were a much larger number of SRTP implementations present at this event, and many scenarios were exercised with success. Some of the notable problems encountered included a few implementations that were using SDES without TLS and continued arguments around how to implement sips/how to indicate one hop of SIP over TLS. Individal testing between the peers exercised wrapping and hold/resume. The next event's test will focus more closely on scenarios like those, and streams utilizing multiple SSRCs * STUN/TURN/ICE This test was very well attended. Endpoints successfully negotiatied sessions utilizing both server and peer reflexive candidates. Connectivity was established between UAs behind different NATs that were using the same private address ranges. We exercised connectivity through TURN chosen using ICE. When older SDP mangling elements were introduced, fewer setup attempts were successful - some implementations were not recognizing ICE mismatches. Several implementations stopped sending keepalives when streams were put on hold. Some implementations restarted ICE when coming off hold. * TLS As noted earlier, there was a large upswing in the number of implementations utilizing TLS present. Configuration of endpoints (establishing trusted CAs and installing certificates) is still very slow, but once the endpoints were configured, iteroperability of SIP over TLS was very high. (However, see the related note on the SRTP test). The automated tests started at SIPit 25 continue to be refined and will soon be available for tests between SIPit events. * Early Media The early media test was also well attended, and the automated tests for early media scenarios continue to be refined. We tested handling early media in forking situations (one branch sends early media, another branch answers) and taking early media on and off hold. The early media test was developed as a self-test and will be available for tests between SIPit events. The test involved forking the call to multiple servers sending early media in the same dialog. The participants argued that early media for ring tones could and propably should be separated from early media for operator messages by using 180 with SDP for ring tones and 183 with SDP for other messages. This way, a UA can decide to stop listening to the 180 ring tone if an 183 message is sent. UAs showed very different behaviour, from jumping between the various streams to mixing them. * Presence The multiparty presence tests successfully exercised basic inter-domain presence exchange, including exchange of winfo information. The participants tried to set up a back-end-subscription loop between two RLSes, but configuration issues got in the way. We will try to exercise that scenario early at the next event. * IPv6 The IPv6 multiparty was set up in order to run various calls through gateways between IPv4 and IPv6, as well as to discuss and setup permanent self-tests for UAs and proxys. IPv4 UAs successfully placed calls to IPv6 UAs through servers that handled the gateway situation. IPv4 UAs mostly had a hard time handling getting SDPs or Contact: headers with IPv6 addresses when placing calls through a proxy that supported dual stack. Successful sessions were established on an IPv6 only networkA lot of experience was gained and we will continue to refine these tests on following SIPits _______________________________________________ RAI mailing list RAI(a)ietf.org https://www.ietf.org/mailman/listinfo/rai