SIPit 26 summary
♫ June 6th, 2010 07:55SIPit 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
Robert 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 he has e 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
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
Multiparty test: 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.
Multiparty test: 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.
Multiparty test: 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
Multiparty test: 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.
Multiparty test: 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, interoperability 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.
Multiparty test: 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.
Multiparty test: 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.
Multiparty test: 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.
Robert J Sparks
