Subject: [Sip] SIPit 19 summary

From: Robert Sparks <[email-masked]>
Date: Wed, 25 Oct 2006 10:30:20 -0500

(This message is somewhat long, and may not survive some mail  
applications attempts to be helpful with formatting.
I've also placed it at http://www.sipit.net/report19.txt)

SIPit 19 took place Oct 16-20, 2006 at the University of New  
Hampshire InterOperability Laboratory (www.iol.unh.edu).

There were 140 attendees from 73 companies visiting from 16 countries  
present.
There were 79 teams and 90 distinct implementations.

The Interoperability Laboratory did a spectacular job of providing a  
rock-solid network for us to test on.
(For those who haven't been to a SIPit, it is a particularly intense  
network torturing environment).

The majority of the spec-arguments during testing centered around how  
to handle early media and early dialogs.
There was also a non-trivial subset of the implementers that were  
confused about whether REGISTER and PUBLISH
create dialogs (much of this confusion seems to come from the  
presence of to-tags in the 200 OK responses to
REGISTER in the examples in 3261). There were a number of interesting  
questions about edge cases that I will
send to the appropriate IETF lists separately.

We tried something different for collecting data for this report at  
this SIPit. We utilized a web-based
automated survey tool. As a result, we collected information on more  
questions than we usually do, so this
report is a bit long. A side-effect is that the accuracy of the  
information is probably a little lower. Almost
all of what's below is self-reported, and its unavoidable that for  
any given question an implementer or two
didn't understand, or didn't know the answer. So, with an appropriate  
level of respect for errors in sampling, here's
what we found:

The roles represented (some implementations act in more than one role):
   36 endpoint
   19 proxy/registrar
    8 standalone proxy
    4 redirect server
    4 gateway 	
   15 automaton UA (voicemail, conference, etc.)
   17 b2bua/sbc
    6 ua w/ signalling but no media
    8 test/monitoring tool

Implementations using each transport for SIP messages:
   UDP 100%
   TCP  82%
   TLS  45% (server auth only)
   TLS  36% (server or mutual auth)
   SCTP  6%
   DTLS  0%

10% of the implementations supported SIP over multicast.
30% supported SIP over IPv6.

70% of the implementations correctly reassembled fragmented UDP.

Proper use of DNS for SIP continues to rise:
   Full RFC3263 use of DNS  59%
   SRV only 		   14%
   A records only	   15%
   no DNS support           12%

Support for various items:
   32% ENUM
   65% rport
   30% multiplexing SIP/STUN
   14% SIGCOMP
   25% RFC4320 fixes
   14% Identity
   30% connect-reuse

14 of the implementations claimed support for outbound.  
Interoperability around this draft was fairly low, but the  
implementers are aggressively improving it.

15 implementations claimed support for some version of GRUU. Nothing  
worked together before code changes at the event. By the end a few  
teams were getting scenarios to work.

Only 3 implementations were attempting to support the consent framework.

The endpoints implemented these methods:
   100% INVITE and ACK
   100% CANCEL
   100% BYE
   96% REGISTER
   81% OPTIONS
   76% SUBSCRIBE
   80% NOTIFY
   56% PRACK
   52% MESSAGE
   74% INFO
   63% UPDATE
   80% REFER
   41% PUBLISH

The endpoints implemented these extensions:
   67% RFC3891: replaces
   63% RFC4028: session-timer
   17% RFC3327: path
   11% RFC3840: pref
    4% RFC3841: caller-prefs
   26% RFC3323: privacy
    6% RFC4538: target-dialog
    7% RFC4488: norefersub
   56% RFC3262: 100rel
    3% RFC3994: indication of message composition

44% of the endpoints implemented sipping-cc-transfer

When asked about STUN support, the client implementations replied:
    6% I implement all the client requirements of draft-ietf-behave- 
rfc3489bis
    6% I implement some, but not all, of the client requirements of  
draft-ietf-behave-rfc3498bis
   13% I implement all of the client requirements of RFC3489
    7% I implement some, but not all, of the client requirements of  
RFC3489
   59% I do not implement STUN as a client
    9% Other

There are still a large number of endpoints (25%) that do not use  
symmetric RTP.

There were only a couple of TURN client implementations. We had  
several STUN servers and 2 TURN servers.  There were only 3 ICE  
implementations, and only one of those was at the current version.  
Interoperability was reasonably high, but not seamless. The issues  
with interoperability were all implementation problems.

I asked the endpoint implementations to characterize their handling  
of S/MIME:
   15% I break if someone sends me S/MIME
   22% I pretend S/MIME doesn't exist if it shows up
   35% I don't pay attention to S/MIME, but will proxy it or hand it  
to my application
    7% I pay attention to S/MIME I receive, but don't send any
    2% I don't pay attention to S/MIME I receive, but I do send some
    4% I try to do something useful with S/MIME I receive and send
   15% Other

I asked the same question about multipart mime support:
    7% I break if someone sends me multipart/mime
   20% I pretend multipart/mime doesn't exist if someone sends it to me
   19% I ignore multipart/mime but will proxy it or hand it to my  
application if it shows up
   15% I try to do something useful with multipart/mime I receive,  
but I never send it
    4% I ignore multipart/mime that I receive, but I try to do  
something useful with multipart/mime I send
   22% I try to do something useful with multipart/mime I send and  
receive
   13% Other

48% of the endpoint implementations claimed to correctly handle  
merged requests.

Here is how the endpoints said they handled receiving 200 OKs from  
more than one branch of a forked INVITE:
   54% I send BYEs to all but one branch
    6% I use all of them (perhaps mixing the different media streams  
locally)
   16% I don't handle this case gracefully
   11% Other

Here is a sample of how endpoint implementors replied when asked how  
they handled early media from more than one leg:
   *	We allow multiple RTP streams with an affinity to the last one.
   *	First Media received is played until 200.
   *	The first 183 will be honored in case of the UAC. The rest will  
be dropped.
   *	Allow media from only negotiated address. Ignore media until  
negotiated (offer-answer exchanged).
   *	Listen to most recently started stream.
   *	all early media will passed on to the UA.
   *	pick the one who most recently sent me a criticial threshold of  
media.
   *	Play only one media stream and ignore others.
   *	The last sdp received override previous one.
   *	First 18x message goes through, rest dropped.
   *	Open voice only with the first one, but answer all of the 18x
   *	We will use the first recieved
   *	I ignore early media
   *	All get relayed - (all rendered leave final choice to recipient UA)
   *	Last early media replaces previous
   *	We update media as the 18x's come in. 200OK media will be the  
confirmed media channel.
   *	Take the first

Interestingly, 15% of the endpoints supported DHCP option 120.

This is how the endpoints (that actually handled media) described  
their use of RTCP:
   38% I fully implement RTCP and use the RTCP from my peers
   20% I send some RTCP, and open a port to receive RTCP, but I  
ignore any packets I receive
   18% I never send RTCP, but I do open a port for receiving (and  
ignoring) it
   24% I don't even open a port for RTCP

There were 12 (roughly 25%) endpoints testing SRTP support. Keying  
was predominantly sdes.
Interoperability is not yet high, but more pairs got something  
working than at SIPit 18.

There were only 4 endpoints supporting comedia.

There were 22 proxies present.

The proxy implementers characterized their handling of infinite loop  
prevention this way:
    0% I implement loop detection as per the sip-loop-fix draft
   45% I perform RFC3261 loop detection
   45% I don't loop detect, but do pay attention to max-forwards
   10% I don't loop detect or look at max-forwards

I asked proxies "Will you proxy a request with a RURI containing an  
unknown scheme
(such as splork:) when there is a Route header field whose first  
value is a SIP URI
you can resolve?" and got these responses:
   32% Yes
   68% No

Half of the proxies in attendence actively participated in session- 
timer.

There were 9 implementations (41%) that categorized themselves as  
proxies that would not forward an unknown method.

Two-thirds of the proxies claimed to properly handle SIPS.

None of the proxies made use of 3840 or 3841 information  
(capabilities and caller-prefs)

There were 19 registrars.

7 of the registrars (37%) accepted non-sip or sips Contacts in a  
registration
11 (58%) would accept a REGISTER request that had a multipart-mime  
body (almost all ignored it)
1 would accept an S/MIME signed or encrypted register

Half of the border-elements (B2BUA/SBC-like implementations) could be  
configured to forward unknown methods.
75% could be configured to forward unknown SDP lines

There were 41 SIP Events implementations present
15 (37%) of them  would send unsolicted notifies (there were 2 more  
things that ONLY sent unsolicited notifies).

They supported these event packages:
   29 refer
   23 message-summary
   14 presence
   12 dialog
   5  reg
   4  ua-profile (sipping-config-framework)
   4  conference
   2  reg gruu extension (sipping-gruu-reg-event)
   2  certificate/credentials (sip-certs)
   1  session-spec-policy (sipping-policy)
   1  kpml
   0  vx-rtcpxr (sipping-rtcp-summary)

Only 4 (10%) supported winfo

4 supported event-list

37% of the implementation supporting SIP Events supported PUBLISH

Of the 14 implementations supporting event presence, there was  
support for the following document formats:
   12 base PIDF only
    2 RPID
    0 CIPID
    0 timed presence
    0 PIDF-LO
    0 prescaps-ext

5 implementations supported XCAP
7 supported pres-rules

I asked all the implentations present which P- headers they actively  
supported:
(I suspect many of the respondents who passively let the headers pass  
or ignore them answered yes, so these
numbers, more than any others of the above are probably inflated)
   28 P-Asserted-Identity
   21 P-Preferred-Identity
   10 P-Called-Party-ID
   9 P-Associated-URI
   9 P-Access-Network-Info
   8 P-Charging-Vector
   6 P-Visited-Network-ID
   5 P-Charging-Function-Address
   4 P-User-Database
   4 P-DCS-* (any of the P-DCS headers)
   3 P-Media-Authorization

That's it. Please let me know if there are different questions you  
want to see asked next SIPit.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip