[SR-Users] Fwd: [RAI] SIPit 29 Summary

FYI -------- Original Message -------- Subject: [RAI] SIPit 29 Summary Date: Fri, 28 Oct 2011 09:40:51 +0200 From: Robert Sparks <rjsparks(a)nostrum.com> To: rai(a)ietf.org (also available at https://www.sipit.net/SIPit29_summary) SIPit 29 was hosted by Etsi Plugtests in Monte Carlo, Monaco the week of October 24-27, 2011. There were 34 attendees from 17 companies visiting from 12 countries. We had 25 distinct implementations. The roles represented (some implementations act in more than one role) 20 endpoints 5 proxy/registrars The b2buas attending this event were not attempting to appear to be proxies. Implementations using each transport for SIP messages: UDP 92% TCP 96% TLS 88% (24% server-auth-only) SCTP 8% DTLS 0% 44% of the implementations present supported IPv6. There were three RFC4474 Identity implementations present. For DNS we had support for: Full RFC3263 : 76% SRV only : 16% A records only : 08% no DNS support : 0% Support for various items in the endpoints: 75% replaces 50% ice 40% 5389stun 35% turn 25% sip/stun multiplexing 30% gruu 25% history-info (there were no implementations of 4244bis) 20% outbound 20% path 20% diversion 15% 3489stun 10% join 5% service-route 0% sigcomp Support for various items in the proxy/registrars: 100% path 80% sip/stun multiplexing 60% gruu 40% outbound 40% diversion 20% service-route 0% history-info The endpoints and b2buas implemented these methods: 100% INVITE, CANCEL, ACK, BYE 95% REFER 95% NOTIFY 80% REGISTER 80% INFO 75% OPTIONS 75% UPDATE 75% PRACK 60% SUBSCRIBE 35% MESSAGE 30% PUBLISH 100% of the implementations sent RTP from the port advertised for reception (symmetric-rtp). 30% of the implementations required the other party to use symmetric-rtp. 90% of the UAs present both sent RTCP and paid attention to RTCP they received. 80% of the endpoints present supported SRTP using sdes. There were no dtls-srtp implementations at this SIPit. 35% of the endpoints supported multipart/MIME. There were no implementations present with S/MIME support. 36% of the implementations present followed RFC6026 (corrections to the INVITE transaction) 36% followed RFC4320 (corrections to the non-INVITE transaction) Not counting implementations that support events only for REFER: There were 3 SIP Event Server implementations There were 5 SIP Event Client implementations These event packages were supported: Server Client 1 2 presence 1 1 presence.winfo 1 4 message-summary 1 1 dialog 1 1 reg 1 1 conference 1 1 xcap-diff 0 2 kpml These packages were supported with the eventlist extension: Server Client 0 1 presence Two of the proxies present still rely only on max-forwards and one that implemented 3261 loop detection. There were two implementations of fork-loop-fix, but no implementations of max-breadth. Multiparty tests (Notes provided by several test participants, including Eoin McLeod, Trond Andersen, Olle Johansson, and Adrian Georgescu) ** IPv6 Focused Tests The first multiparty session of the event focused specifically on IPv6. We used a basic forking scenario with endpoints registered with several proxies at the bottom of the tree. We had a mix of single and dual-stack endpoints, many supporting video. None of the participant's code would put both v4 and v6 candidates into ICE. Rather, it made assumptions about which candidates to use based on what was happening with the SIP signaling. We ran tests using SRV configurations stating that v6 should be tried first and v4 tried if the v6 failed (and a second configuration that tested v4 first) to ensure that implementations would fail forward and try both address families, with mixed results. We confirmed that one UA configured to use IPv6 only was able to request and use an IPv4 turn allocation and succeeded in making a call between an IPv4 UA and IPv6 ua. Most UAs that supported dual-stack had a configuration to tell the application to ignore any returned AAAAs due to issues encountered in deployments where endpoints autoconfigured IPV6 that didn't actually work. We successfully tested calls going though a mix of v4 and v6 hops (accruing Via and Route/Record-Route headers with addresses in both families. There was an instance of UA registering using sip-outbound (RFC5626) that used IPv4 and IPv6 flows simultaneously. We set up automated tests of using SRV records to indicate preference for IPv4 or IPv6. Two ipv4 only clients proved that they connect to a domain indicating preference for IPv6. ** Forking There are still UAs that do not sensibly handle multiple 200 OKs to a forked INVITE. When testing handling multiple 200 OKs on a simple two branch fork, we encountered an interesting failure. As the proxy handled the 200 OK from branch 1, it sent a CANCEL to the other branch. The UA on branch 2 had already responded with a 200 OK, so it responded to the CANCEL with a 200, but rather than ignoring it, it decided to send a BYE on the dialog. This surprised the calling UA which had chosen the 200 OK from branch 2 to keep, having already sent a BYE to the dialog from branch 1. The better thing for the UA to have done is ignore the CANCEL after replying to it. ** TLS Most of the implementations at the event supported TLS, and all the multiparty tests exercised it. One session focused on proper certificate verification. We tested a certificate at a server with several SAN URI fields, none of which matched the URI used for the server, but a CN that did. Only one UA failed to connect because of this, the rest of the UAs connected happily (or not at all, but because of other issues). Most of the implementations were "before 5922" code, which meant that there was a lot of checking of the Subject/CN. ** Identity There were several SIP Identity implementations present. We tested creating and verifying the Identity assertions at proxies. It wasn't immediately obvious to some implementers that the resource pointed to by the Identity-Info URI had to be DER encoded (a result of the requirement to use application/pkix-cert). Unfortunately, the tar encoded at the end of 4474 has .cer files in it that are PEM encoded. ** STUN/TURN/ICE and Outbound We spent a significant fraction of the multiparty test time (three sessions) focusing on STUN/TURN/ICE and Outbound. There are still clients using RFC 3489 STUN. The participants noted operator pushback against deploying ICE because when things go wrong, it's very hard to diagnose when, where and why they went wrong. If the endpoints always sent a reINVITE (or UPDATE) when concluding ICE, even if they used the default candidates, this diagnosis of failures would be much easier. Examples noted by the participants: * Without a mandatory conclusion, is not possible to know how long it took until end-points had successful media path established * Without a mandatory conclusion, is not always possible to know if different than default candidates have been chosen as lack of INVITE does not tell deterministically what happened * Without a mandatory conclusion, it is not possible for the callee to restart ICE if it does not agree with the conclusion We successfully exercised endpoints setting up and managing multiple outbound flows through separate edge proxies to a proxy/registrar (with different implementations taking turns in the proxy registrar role). We forced the network to break the flow in use in each case, verifying that subsequent dialog-forming requests would take an alternate flow. We discovered an issue with the recommendation in 5626 to have edge proxies record-route that prevents subsequent in-dialog requests from using alternate flows. ** SRTP All implementations supported SDES for SRTP key exchange. Good interop with many different combinations of endpoints. Some calls were left up for an extended period so that sequence number wrapping and roc increments were tested. Once the roc had changed the call was put on hold and resumed with success. In this situation new RTP streams with different SSRCs were created and the sequence number/roc combination re-generated thus proving that support for multiple SRTP contexts exists. Debate surrounding how to signal 'best-effort crypto' continues. Some implementations choose to advertise RTP/AVP with a=crypto attributes and then go crypto if answer also has them and non-crypto if they do not. RTP/SAVP is used to signal the desire for mandatory crypto. Another approach observed was to repeat the same media line twice, once for crypto and once for non-crypto and rely on the receiving end to only accept one of them and port reject the other. In this case both m-lines had the same port number and payload number descriptions so if a receiving end accepted both then the originator would have no clue as to whether it was receiving crypto or non-crypto traffic. ** Unusual messages We tried several kinds of valid, but unusual messages. Very few implementations did the right thing with a request-URI with an unknown scheme - some phones would answer an INVITE with that in the request-URI. ** Specification questions / comments RFC 3263 currently says "If no SRV records are found, the client SHOULD use TCP for a SIPS URI" - it should probably say TLS over TCP. In the spirit of Happy Eyeballs, there should be some guidance on what to do when the RFC 3263 process results in both A and AAAA records and the client is capable of using both. There were implementations of SIP over DTLS, but the specification of that usage seems not to have completed. There were questions on whether internationalized domain names could be used in SIP URIs. For use of SDP with ICE, there was an argument about whether a=rtcp was mandatory if rtcp was on the next port up. RFC 5245 says "If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 [RFC3605].", and 3605 says "when that port is not the next higher (odd) port number following the RTP port described in the media line" to motivate why the attribute was created to begin with. Any updates to 5245 should clarify that adding the a=rtcp attribute is not optional when RTCP is being sent on the next higher port. _______________________________________________ RAI mailing list RAI(a)ietf.org https://www.ietf.org/mailman/listinfo/rai