Subject: [Sip] SIPit23 Survey Notes

From: Robert Sparks <[email-masked]>
Date: Thu, 23 Oct 2008 10:16:45 -0500

Also available at https://www.sipit.net/SIPit23_Summary :

SIPit 23 was hosted by ETSI with technical support from Orange
the week of October 13-17, 2008 in Lannion, France

There were 97 attendees from 37 companies visiting from 19 countries.

I manually surveyed the teams at this event to avoid some of the  
sampling error
we've seen with the use of an automated survey tool at the last few  
SIPits.
Please take care to remember this change in the measurement tool when  
trying to
read trends comparing this report to previous events. In particular, I  
was
careful to avoid counting two products that were essentially the same
implementation as different. With that in mind:

We had over 50 distinct implementations.

There were a higher than usual proportion of implementations attending  
SIPit
for the first time at this SIPit. As a result, there was more testing  
of basic
interoperability than we've seen for the last several events. There  
were still
several advanced teams demonstrating interoperability of more  
complicated
scenarios.

62% of the UAs present both sent RTCP and paid attention to RTCP they  
recieved
     this is the first sipit where this has been true for the majority  
of the UAs.

This event saw a (mostly) successful test of ICE between three  
implementations
at the multiparty tests.

There were no implementations of the sip-config, sip-consent, or  
session-policy
frameworks. The only people in the room who had even read the sip-config
framework documents are regular IETF participants. Even fewer had read
sip-consent or session-policy. There is currently a huge gap between
specification and implementation for these concepts. (Note - there  
have been
sip-config implemantations at previous events, but the teams that  
brought them
were not able to attend this time).

The roles represented (some implementations act in more than one role):
  29 endpoints
  13 proxy/registrars
   8 event servers
   7 gateways
   2 automaton UAs (voicemail, conference, appserver, etc)
  14 b2bua/sbcs
   3 UAs with signaling, but without media
   5 test/monitoring tool

The set of things considered UAs below (the union of the
endpoints/b2buas/gateways/etc) consisted of 42 implementations.

Implementations using each transport for SIP messages:
   UDP    100%
   TCP     93%
   TLS     48% server-auth, 28% mutual-auth
   SCTP    11%
   DTLS   none

30% of the implementations supported SIP over IPv6 (This was  
significantly down
from the last few events - I think it is mostly due to the number of  
very young
implementations present.)

19% supported SIP over IPSec

For DNS we had support for:
    Full RFC3263		: 65% (continuing to climb)
    SRV only		: 15%
    A records only	: 13%
    no DNS support	:  7%

Support for various items:
   72% rport
   15% sigcomp
   36% enum
   13% RFC4320 fixes
   13% invfix
   63% session-timer
   9% outbound (various versions)
   9% gruu-15

There were only 2 implementations claiming support for Identity. 2 for  
the
dial-string URI (RFC4967), and none for Service URNs (RFC5031). These  
are all
lower than what was reported at previous events - a result of the  
opportunity
to double-check answers during the manual survey.

Many teams expressed intent to implement outbound and gruu once  
something was
published as an RFC, and a strong unwillingness to even try until that  
happens.

36% of the implementations indicated support for anonymous calling.

24% reported using the Diversion header field.

76% of the implementations made some use of SIP Events.
There was a huge upswing in support for the message-summary event.

The UAs implemented these methods:
   95% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence  
only)
   93% REGISTER
   95% NOTIFY <- still a lot of unsolicted NOTIFYs
   95% SUBSCRIBE
   86% OPTIONS
   83% PRACK
   77% INFO
   72% REFER
   72% UPDATE
   64% MESSAGE
   43% PUBLISH (Note that several of these are b2buas
                that are not really processing the PUBLISH
                - the next survey will split those out)

Support for various extensions in the endpoints:
   98%   RFC3262 100rel
   50%   RFC3323 privacy
   36%   RFC3327 path
    7%   RFC3840/RFC3841 pref/caller-prefs
   79%   RFC3891 replaces
    9%   RFC4488 norefersub
    7%   RFC4538 target-dialog

There were 6 ICE implementations (and 1 ICE-TCP implementation)
There were 6 TURN clients and one TURN server present
There were 19 STUN clients (6 were stun-bis)

88% of the UAs supported symmetric RTP
16% supported SRTP - only one had code based on the dtls-srtp work

Support for multipart/mime increased (38% of the UAs would do  
something with it
on receipt). There were no implementations present testing S/MIME.

Of the SIP-Events implementations, the following packages were  
supported:
   82%	message-summary
   72%	refer
   59%	presence
    8%	reg
   16%	dialog
   12%	conf

There were two RLS servers and 6 clients supporting
the event-lists extension present. There were two xcap servers present.

There were 8 SIP-Events implementations present supporting winfo.

7 of the proxies present implemented some form of loop detection (only  
3 have
implemented the loop-detection part of fork-loop fix)

There were 5 MSRP clients and one MSRP relay present.  All of the  
clients
supported file transfer (3 used file-transfer-mech).  Several clients  
were able
to exchange files.  Two of the clients were able to exchange instant  
messages.
(Only one had been created with the intent to send instant messages -  
the rest
were file transfer centric.) The embedded-device implementers noted  
that the
decision to not allow a negotiated maximum chunk size (not maximum  
message
size) is causing them significant difficulty.

The multiparty STUN/TURN/ICE test saw successful calls using ICE after
correcting some implementation issues around authenticating a binding  
and
becoming less strict on parsing SDP (specifically the rtcp attribute).
There was some argument over what inputs to use for candidate pairs when
one stream (of many) in an offer was rejected in the answer.

I asked where people were taking bits from messages to display as  
caller-id.
There were many different kinds of answers, including
  P-Asserted-Identity if present, then From
  From display name
  username part of From uri
  P-Asserted-Identity only
  Contact uri
  Remote IP address
  P-Asserted-Identity, then Remote-Party-ID, then From
  From, then Remote-Party-ID, then P-Asserted-Identity
  Remote-Party-ID then From
  From then P-Assertid-Identity
  P-Asserted-Identity, then Reply-To, then From
  entire From URI
Of these, using the From display name occurred most frequently,
but not much more than any of the other responses

After removing some minor rough edges, the presence multiparty test
exercised xcap successfully, modifying resource lists and presence  
rules.
There are still many questions around how to discover the xcap root uri.

The TLS multiparty test had several new participants and did not go as  
smoothly
as it has in past events. Most of the issues were with configuration  
of individual
implementations, but there was quite a bit of confusion around the use  
of sips:
and transport=tls. We will hold a longer and more rigourous multiparty  
session
focusing on TLS at the next SIPit.

_______________________________________________
Sip mailing list  https://www.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

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 24 Oct 2008 16:33:47 +0200

Hi Robert!

> 19% supported SIP over IPSec

What do you mean with "SIP over IPSec"? Every protocol runs over IPSec 
as it is transparent to the application.

>  From, then Remote-Party-ID, then P-Asserted-Identity

So, if the From header is missing ???, the other headers are used?

thanks for the summary
Klaus

---

From: Thomas Froment <[email-masked]>
Date: Fri, 24 Oct 2008 16:52:27 +0200

> as it is transparent to the application.
Well, SIP over IPsec is not really "transparent" to the SIP implementation:
when you want to send a request over an IPSec SA, you MUST be able to 
choose what is the source interface / source port and destination 
interface / destination port. This is not something so easy to implement 
at SIP transport level.
Thomas

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 24 Oct 2008 17:51:50 +0200

> interface / destination port. This is not something so easy to implement 

I still do not get it. You can use IPSec without any additional 
interfaces. If the IPSec implementation creates tunnel interfaces, that 
may cause problems to SIP client. But then the problem is due to tunnel 
interfaces (which can be anything, not only IPsec), not due to IPSec.

So if the SIP client does not care if the communication is secured with 
IPsec, then every client should work over IPsec too.

So the question is still - what means "supported SIP over IPSec"?

Does it mean, "Is the SIP client capable of retrieving IPsec information 
from the kernel to find out if a message will be sent via IPsec secured way?

regards
klaus

---

From: [email-masked]
Date: Fri, 24 Oct 2008 13:32:54 -0400 (EDT)

From: Klaus Darilion <[email-masked]>

Probably "If the From header is missing a display-name, the other
headers are examined."

Dale

---

From: Robert Sparks <[email-masked]>
Date: Fri, 24 Oct 2008 15:25:21 -0500

On Oct 24, 2008, at 9:33 AM, Klaus Darilion wrote:

> What do you mean with "SIP over IPSec"? Every protocol runs over  
> IPSec as it is transparent to the application.
Thomas answered this already.
> So, if the From header is missing ???, the other headers are used?
Yeah - each row represented an ordered set - if the first thing in the  
row was present, it was used, otherwise, the next thing was looked  
for, and so on...

---

From: Robert Sparks <[email-masked]>
Date: Fri, 24 Oct 2008 15:34:20 -0500

Hi Klaus -

The number represents endpoints that could actually emit a SIP message  
over IPSec at the event, not just ones that would work if IPSec  
happened to be the part of the transport. Its a measure of what the  
available implementations can be configured to do.

What it doesn't capture is the tight-coupling w/ the IPSec  
implementation that's required to support, for instance, Digest-AKA as  
used in IMS. I don't have that statistic from this event, but based on  
conversations and observations at past events, the number would be non- 
zero but small.

RjS

On Oct 24, 2008, at 10:51 AM, Klaus Darilion wrote:

>> when you want to send a request over an IPSec SA, you MUST be able  
>> to choose what is the source interface / source port and  
>> destination interface / destination port. This is not something so  
>> easy to implement at SIP transport level.
>
> interfaces. If the IPSec implementation creates tunnel interfaces,  
> that may cause problems to SIP client. But then the problem is due  
> to tunnel interfaces (which can be anything, not only IPsec), not  
> due to IPSec.
>
> So if the SIP client does not care if the communication is secured  
> with IPsec, then every client should work over IPsec too.
>
> Does it mean, "Is the SIP client capable of retrieving IPsec  
> information from the kernel to find out if a message will be sent  
> via IPsec secured way?
>
> regards
> klaus

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2008 16:32:45 -0500

On Oct 24, 2008, at 9:52 AM, Thomas Froment wrote:

> to choose what is the source interface / source port and destination  
> interface / destination port. This is not something so easy to  
> implement at SIP transport level.

That depends. For example, if you're running SIP over tunnel-mode  
IPSec, there is no impact at all to SIP.

So clearly, you mean something else by "SIP over IPSec". What do you  
mean? Is this something that we need an RFC to define so that we can  
say "RFC XXXX" instead of "SIP over IPSec"?

--
Dean