Subject: [RAI] SIPit 30 summary

From: Robert Sparks <[email-masked]>
Date: Fri, 22 Feb 2013 14:26:41 -0500

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.