Activity report – SIPit 19

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 University of New Hampshire 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). Kudos to UNH-IOL. (Editors note: UNH-IOL has become a SIP Forum Full Member.

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 were forwarded 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:

Demographics

The roles represented (some implementations act in more than one role):

Endpoint	36
Proxy/registrar	19
Standalone proxy	8
Redirect server	4
Gateway	4
Automaton UA (voicemail, conference, etc.)	15
B2BUA/sbc	17
User Agent w/signaling but no media	6
Test/monitoring tool	8

General SIP compliance

Implementations using each transport for SIP messages:

UDP	100%
TCP	82%
TLS (server auth only)	45%
TLS (server or mutual auth)	36%
SCTP	6%
DTLS	0%

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

Correctly reassembled fragmented UDP70%

ENUM	32%
rport	65%
multiplexing SIP/STUN	30%
SIGCOMP	14%
RFC4320 fixes	25%
Identity	14%
connect-reuse	30%
SIP over multicast	10%
SIP over IPv6	30%

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.

Endpoints

The endpoints implemented these methods:

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

The endpoints implemented these extensions:

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

NAT traversal

When asked about STUN support, the client implementations replied:

I do not implement STUN as a client	59%
I implement all of the client requirements of RFC3489	13%
I implement some, but not all, of the client requirements of RFC3489	7%
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	6%
Other	9%

25% of endpoints still 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.

MIME

I asked the endpoint implementations to characterize their handling of S/MIME:

I break if someone sends me S/MIME	15%
I pretend S/MIME doesn’t exist if it shows up	22%
I don’t pay attention to S/MIME but will proxy it or hand it to my application	35%
I pay attention to S/MIME I receive but don’t send any	7%
I don’t pay attention to S/MIME I receive but I do send some	2%
I try to do something useful with S/MIME I receive and send	4%
Other	15%

I asked the same question about multipart mime support:

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

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

Forking

Here is how the endpoints said they handled receiving 200 OKs from more than one branch of a forked INVITE:

I send BYEs to all but one branch	54%
I use all of them (perhaps mixing the different media streams locally)	6%
I don’t handle this case gracefully	16%
Other	11%

Media

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.

RTCP

This is how the endpoints (that actually handled media) described their use of RTCP:

I fully implement RTCP and use the RTCP from my peers	38%
I send some RTCP, and open a port to receive RTCP, but I ignore any packets I receive	20%
I never send RTCP, but I do open a port for receiving (and ignoring) it	18%
I don’t even open a port for RTCP	24%

SRTP

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.

Proxies

There were 22 proxies present.

The proxy implementers characterized their handling of infinite loop prevention this way:

I implement loop detection as per the sip-loop-fix draft	0%
I perform RFC3261 loop detection	45%
I don’t loop detect, but do pay attention to max-forwards	45%
I don’t loop detect or look at max-forwards	10%

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:

Yes	32%
No	68%

Half of the proxies in attendance 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)

Registrars

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.

SIP Events

There were 41 SIP Events implementations present.

15 (37%) of them would send unsolicited notifies (there were 2 more things that ONLY sent unsolicited notifies).

They supported these event packages:

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

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:

base PIDF only	12
RPID	2
CIPID	0
timed presence	0
PIDF-LO	0
prescaps-ext	0

5 implementations supported XCAP

7 supported pres-rules

P-headers

I asked all the implementations 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):

P-Asserted-Identity	28
P-Preferred-Identity	21
P-Called-Party-ID	10
P-Associated-URI	9
P-Access-Network-Info	9
P-Charging-Vector	8
P-Visited-Network-ID	6
P-Charging-Function-Address	5
P-User-Database	4
P-DCS-* (any of the P-DCS headers)	4
P-Media-Authorization	3

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