Fwd: [Sip-implementors] SIPit26 summary
Victor Pascual Avila
From: Robert Sparks <rjsp...@nostrum.com>
Date: Fri, Jun 4, 2010 at 8:51 PM
Subject: [Sip-implementors] SIPit26 summary
To: "sip-impl...@lists.cs.columbia.edu Implementors"
<sip-impl...@lists.cs.columbia.edu>
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
_______________________________________________
Sip-implementors mailing list
Sip-impl...@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors