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.