SIPit26 Summary

 

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