SIPit30 summary

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.