Subject: [RAI] SIPit 24 summary

From: Robert Sparks <[email-masked]>
Date: Fri, 22 May 2009 11:49:17 +0900

SIPit 24 was hosted by JPNIC and NICT the week of May 18-22, 2009 in  
Akihabara, Tokyo, Japan.

Because of the recent global economic changes and the outbreak of flu,  
we had a smaller
event than usual.  There were 65 attendees from 28 companies visiting  
from 11 countries.
Despite the smaller number of participants we still had 43 distinct  
implementations.

The mix of implementations was unusual. There were fewer proxies/ 
b2buas/sbcs than normal.
We also had a higher mix of partial implementations focusing on  
enabling testing.

GRUU is being more widely implemented - there were 8 implementations  
present.

As at the last SIPit, there were no implementations of the sip-config,
sip-consent, or session-policy frameworks.

The roles represented (some implementations act in more than one role):
  25 endpoints
   6 proxy/registrars
   6 b2bua/sbcs
   4 test/monitoring tools

Implementations using each transport for SIP messages:
   UDP    100%
   TCP     81%
   TLS     52% server-auth, 26% mutual-auth
   SCTP     7%
   DTLS     5%

57% of the implementations supported SIP over IPv6 (This is a big  
increase
over past events, and is related to where the event was held.)

For DNS we had support for:
    Full RFC3263		: 76%
    SRV only		: 5%
    A records only	: 8%
    no DNS support	: 11%

Support for various items:
   71% rport
   20% sigcomp
   26% enum
   10% RFC4320 fixes
   24% invfix
   69% session-timer
   20% IPSec
   12% outbound
   14% diversion

There was only 1 implementation claiming support for Identity. 2 for the
dial-string URI (RFC4967), and two for Service URNs (RFC5031). We asked
proxies to test processing an INVITE with a service URN in the Request- 
URI
and To: header field and a pair of SIP URIs in the route header. The  
majority
of reports back were that the message would be rejected (but they are  
changing
their code).

There were 4 MSRP and 3 XCAP implementations present.

There was one implementation of location-conveyance.

The UAs implemented these methods:
   95% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence  
only)
   95% REGISTER
   88% NOTIFY
   88% SUBSCRIBE
   83% PRACK
   80% OPTIONS
   76% REFER
   71% UPDATE
   68% INFO
   61% MESSAGE
   56% PUBLISH

Support for various extensions in the endpoints:
   82%   RFC3262 100rel
   31%   RFC3323 privacy
   23%   RFC3327 path
    8%   RFC3840/RFC3841 pref/caller-prefs
   62%   RFC3891 replaces
   10%   RFC4488 norefersub
    3%   RFC4538 target-dialog

50% of the implementations were RFC 3489 STUN capable. 21% were RFC  
5389 STUN capable.

There were 2 full ICE implementations (appearing in several  
instances), an additional
implementation of an older spec, and several implementations underway  
that were not quite
ready to test. There were no ICE-TCP implementations this time.
There were 7 TURN clients and 4 TURN server present.

70% of the UAs present both sent RTCP and paid attention to RTCP they  
recieved

39% of the endpoints present supported SRTP - a large uptick from the  
last event.
Only one had code based on the dtls-srtp.

Support for multipart/mime continues to increase - 58% of the  
endpoints present
would handle it.  There were no implementations present testing S/MIME.

Of the SIP-Events implementations, the following packages were  
supported:
   65%	presence
   65%	refer
   39%	message-summary
   32%	reg
   16%	conf
   13%	dialog

23% of those implementations supported eventlist.

There were 6 SIP-Events implementations present supporting winfo.

Four of the proxies/b2buas present still rely only on max-forwards.
There were two implementations of fork-loop-fix, but no  
implementations of max-breadth.

Based on a query from James Polk, I asked endpoints how they reacted  
to receiving
a 300 class response to an initial invite. Of those who responded:
   25% would stop processing the call
   33% would follow the redirect if and only if there was only one  
contact
   17% would follow the first contact if one or more were present
   25% would follow all contacts (or give the user a choice of which  
to follow)

---

From: Dean Willis <[email-masked]>
Date: Sun, 24 May 2009 04:12:59 -0500

> SIPit 24 was hosted by JPNIC and NICT the week of May 18-22, 2009 in  

Thank you for the report. Did we get a sense of support for History- 
Info?

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Tue, 26 May 2009 10:10:12 -0500

On May 24, 2009, at 4:12 AM, Dean Willis wrote:

>> SIPit 24 was hosted by JPNIC and NICT the week of May 18-22, 2009  
>> in Akihabara, Tokyo, Japan.
>

I didn't see any History-Info at the event at all. (But I didn't ask  
team-by-team).
Note that we had fewer proxies than usual, and some of the known-to- 
have-HI implementations were not present.
Not as precise an answer as I would like, but its safe to say that  
implementation of History-Info is not pervasive at this point.

RjS

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 May 2009 10:34:04 -0500

At 09:49 PM 5/21/2009, Robert Sparks wrote:
>Based on a query from James Polk, I asked

Robert - thanks for asking this...

>endpoints how they reacted
>to receiving

but wow... I am surprised at this high a number....

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 26 May 2009 11:53:29 -0500

We do know that there is a significant number of commercial
implementations of History-Info however. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Robert Sparks
> Sent: Tuesday, May 26, 2009 08:10
> To: Dean Willis
> Cc: [email-masked]
> Subject: Re: [RAI] SIPit 24 summary
> 
> 
> I didn't see any History-Info at the event at all. (But I 
> didn't ask team-by-team).
> Note that we had fewer proxies than usual, and some of the 
> known-to- have-HI implementations were not present.
> Not as precise an answer as I would like, but its safe to say 
> that implementation of History-Info is not pervasive at this point.
> 
> RjS
> 
> >
> >
> > --
> > Dean
> >
> 
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 May 2009 14:45:23 -0500

Which begs the question, Robert - (and I'm not evaluating you - just 
wanting to know):

Do you (somehow) list all the SIP (and related) RFCs on some 
questionnaire that participants fill out stating which they have 
implemented part or all of?

I understand the information you have gotten us, which is great, and 
am curious about the non-mainstream RFCs we have that may be not 
being reported because they aren't asked about.

Also, I can understand if this fact finding would make it too 
cumbersome or somehow untrustworthy in the data reported.

Thanks

James

---

From: Robert Sparks <[email-masked]>
Date: Tue, 26 May 2009 15:00:00 -0500

No problem with the question - I've tried to describe this process in  
previous reports.

I used an automated survey tool for awhile, and listed lots of RFCs/ 
drafts to help find when something started to emerge into  
implementation space.
The problem that I ran into was that the lists got long enough that  
people would quit responding (or at a minimum complain mightily).
I also discovered that I either had to leave an "I don't know" answer  
or allow leaving the question blank (which would get the majority) or  
folks who couldn't get the answer quickly would make something up so  
they could finish the survey.
Further, there was a measurable problem with people assuming they knew  
what a draft was from its name (figuring out who implements draft-ietf- 
sip-outbound from those who could just configure outbound proxies  
sometimes takes pointed questions).

So for the last few events, I've gone back to a manual survey based on  
a short list of questions tuned by what people are asking about and  
where the edges were at recent events.
I _should_ have asked about History-Info this time, but didn't (an  
unintentional omission).

For future events, if there's a particular draft people are interested  
in asking about, doing so on-list about the time registration for the  
event closes would be very helpful.

RjS

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 May 2009 15:04:02 -0500

>No problem with the question - I've tried to describe this process in

yeah -- I remember something about this, and I know it was thorough, 
but didn't remember the details.

>people would quit responding (or at a minimum complain mightily).

yep - this was what I was afraid of

>what a draft was from its name (figuring out who implements 
>draft-ietf- sip-outbound from those who could just configure outbound proxies

that's also a fair point

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 27 May 2009 12:09:57 +0200

It should also be remembered that the implementations represented at a SIPit session are probably not a statistically valid sample from the complete SIP implementation population. 

While the results of the survey are extremely useful, they are bounded.

regards

Keith

> Sent: Tuesday, May 26, 2009 9:00 PM
> To: James M. Polk
> Cc: [email-masked]
> No problem with the question - I've tried to describe this 
> process in previous reports.
> 
> I used an automated survey tool for awhile, and listed lots 
> of RFCs/ drafts to help find when something started to emerge 
> into implementation space.
> The problem that I ran into was that the lists got long 
> enough that people would quit responding (or at a minimum 
> complain mightily).
> I also discovered that I either had to leave an "I don't 
> know" answer or allow leaving the question blank (which would 
> get the majority) or folks who couldn't get the answer 
> quickly would make something up so they could finish the survey.
> Further, there was a measurable problem with people assuming 
> they knew what a draft was from its name (figuring out who 
> implements draft-ietf- sip-outbound from those who could just 
> configure outbound proxies sometimes takes pointed questions).
> 
> So for the last few events, I've gone back to a manual survey 
> based on a short list of questions tuned by what people are 
> asking about and where the edges were at recent events.
> I _should_ have asked about History-Info this time, but 
> didn't (an unintentional omission).
> 
> For future events, if there's a particular draft people are 
> interested in asking about, doing so on-list about the time 
> registration for the event closes would be very helpful.
> 
> RjS
> 
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 May 2009 14:42:20 -0500

fair statement

at the same time, I'm looking at what's missing as an indicator (from 
the sample), what's nearly 100% implemented, and with what I asked 
Robert to look for, what some would have considered obvious to 
implement - and it wasn't universally implemented (i.e., lack of 
handling of 300s by 25% of this SIPit, which was surprising to a few 
of us at least).

At 05:09 AM 5/27/2009, DRAGE, Keith (Keith) wrote:
>It should also be remembered that the implementations represented at 
>a SIPit session are probably not a statistically valid sample from 
>the complete SIP implementation population.
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 May 2009 17:08:37 -0500

I really don't think SIPit is the relevant place to see "what's implemented"
in commercial products.

I don't even think the numbers are good indicators. It's the wrong place to
look for this type of information.

SIPit will provide valuable information about how implentable a protocol is, 
but it won't tell you what makes it into commercial products. Especially 
not for something like 302 support.

The sad thing, is I don't believe there is any formal place to look for
such information. In the service provider market you can look at SBC vendors
for stats perhaps. In enteprise market, you probably need to look at a 
not-so-big list of software vendors who account for the majority of
the market share. 

> Behalf Of James M. Polk
> Sent: Wednesday, May 27, 2009 12:42
> To: DRAGE, Keith (Keith); Robert Sparks
> Cc: [email-masked]
> at the same time, I'm looking at what's missing as an 
> indicator (from the sample), what's nearly 100% implemented, 
> and with what I asked Robert to look for, what some would 
> have considered obvious to implement - and it wasn't 
> universally implemented (i.e., lack of handling of 300s by 
> 25% of this SIPit, which was surprising to a few of us at least).
> 
> >It should also be remembered that the implementations 
> represented at a 
> >SIPit session are probably not a statistically valid sample from the 
> >complete SIP implementation population.
> >
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Robert Sparks
> > > No problem with the question - I've tried to describe 
> this process 
> > > in previous reports.
> > >
> enough that 
> > > I also discovered that I either had to leave an "I don't know" 
> > > answer or allow leaving the question blank (which would get the 
> > > majority) or folks who couldn't get the answer quickly would make 
> > > something up so they could finish the survey.
> > > Further, there was a measurable problem with people assuming they 
> > > knew what a draft was from its name (figuring out who implements 
> > > draft-ietf- sip-outbound from those who could just configure 
> > > outbound proxies sometimes takes pointed questions).
> > >
> > > So for the last few events, I've gone back to a manual 
> survey based 
> > > on a short list of questions tuned by what people are 
> asking about 
> > > and where the edges were at recent events.

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 May 2009 13:28:29 -0500

> people would quit responding (or at a minimum complain mightily).

I experience the same thing every time I try to read through our list  
of RFCs. I used to include such a list in my standard slide set; I  
gave up when it started taking multiple eye-chart pages.

There's gotta be a better way to track compliance.

I hate to suggest this, but is it time for "reference profiles" that  
describe fixed subsets of functionality? I seem to recall the Java  
people did this, with two or three levels of Java functionality; ME,  
MIDP, CLDC, and so on.

My sense is that while this didn't work 100%, it at least served to  
encapsulate functionality bundles so people could talk about them.

--
Dean

---

From: Dan York <[email-masked]>
Date: Fri, 29 May 2009 08:46:32 -0400

Dean,

> encapsulate functionality bundles so people could talk about them.

This is largely what the SIP Forum is seeking to do with their  
"SIPconnect" certification program, although that is only looking at  
the SIP interconnection between an on-premise system and a SIP Service  
Provider.  The idea, though, is to build a profile of what are the  
necessary RFCs, etc. to support and have people test against that.

Similarly, the WiFi Alliance has done this with the various IEEE  
802.11 specs.  Hide the specific details of exactly which 802.11 specs  
are supported behind broader, more user-friendly certification marks.  
(in their case)

Regards,
Dan
-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-407-455-5859    Skype: danyork

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.voxeo.com/facebook

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 29 May 2009 13:14:06 -0400

Yep I'm in total agreement Dean ... this is a serious flaw in the way RAI
does business. 

It is very very difficult to reconcile the various SIP RFC's into a coherent
implementable specification. Dan is correct in pointing out this is exactly
what we are trying to do in the SIPforum with SIPconnect and its taking much
longer than we anticipated. We've had hours of discussions over History-Info
with only marginal consensus on what to actually recommend to the industry.

In addition we're look at the ongoing problems of implementing T38 fax in
SIP. ( NO fax is not dead)

We are NOT writing protocols in the SIPforum but the exercise of creating a
profile of SIP for PBX to SSP's also exposes additional flaws in the overall
architecture of SIP ( what little exists) that creates huge problems for
implementers, like dealing with e164 and the provisioning of data between
the PBX and the SSP in order to enable service.

IMHO the Hitchhikers guide SIP is NOT a implementable specification more of
a road map. 

We need a better way ...

>  From: [email-masked] [mailto:[email-masked]] On Behalf Of
>  Dan York
>  Sent: Friday, May 29, 2009 8:47 AM
>  To: Dean Willis
>  Cc: [email-masked]

---

From: James Rafferty <[email-masked]>
Date: Fri, 29 May 2009 14:58:09 -0400

Rich,  

As a product manager for a SIP-based gateway, I can tell you it's a nightmare trying to interwork with the many variations of SIP that are out there.  We've been forced to profile SIP and also mediate between different SIP implementation options.    

I do think that industry profiles and test specifications help push implementers into some aspects of commonality.  

Communities that come to mind who are doing such profiles include:  

- SIP Forum (SIP Connect) 
- Microsoft OCS 
- 3GPP (IMS)  

I would not think the IETF wants to get into the business of specifying profiles, which would usually be done by 3rd parties such as the SIP Forum.  

On the other hand, most implementers don't seem to adhere to any of the 3 profiles I've noted, so it gets messy.   

James 

James Rafferty 
Product Line Director, Integrated Media Gateways 
Dialogic, Inc.  
15 Crawford Street 
Needham, MA 02494 
USA 

Tel:    781 433 9462
Mobile: 781 929 3895
Fax:    781 433 9268
Email:  [email-masked]
Web:    www.dialogic.com
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Friday, May 29, 2009 1:14 PM
To: 'Dan York'; 'Dean Willis'
Cc: [email-masked]
Subject: Re: [RAI] SIPit 24 summary

We need a better way ...

---

From: Avshalom Houri <[email-masked]>
Date: Sun, 31 May 2009 11:38:18 +0300

One comment on this thread is that we educate people on the importance of 
standards and when they get to the real world they learn that standards is 
not a new religion... it is always hard to explain to them the dichotomy 
while making them still "believe" that standards are important.

--Avshalom

From:
James Rafferty <[email-masked]>
To:
Richard Shockey <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
29/05/2009 10:17 PM
Subject:
Re: [RAI] SIPit 24 summary
Sent by:
[email-masked]

Rich, 

As a product manager for a SIP-based gateway, I can tell you it's a 
nightmare trying to interwork with the many variations of SIP that are out 
there.  We've been forced to profile SIP and also mediate between 
different SIP implementation options. 

I do think that industry profiles and test specifications help push 
implementers into some aspects of commonality. 

I would not think the IETF wants to get into the business of specifying 
profiles, which would usually be done by 3rd parties such as the SIP 
Forum. 

On the other hand, most implementers don't seem to adhere to any of the 3 
profiles I've noted, so it gets messy. 

James 

James Rafferty 

Tel:    781 433 9462
Mobile: 781 929 3895
Fax:    781 433 9268
Email:  [email-masked]
Web:    www.dialogic.com
This e-mail is intended only for the named recipient(s) and may contain 
information that is privileged, confidential and/or exempt from disclosure 
under applicable law. No waiver of privilege, confidence or otherwise is 
intended by virtue of communication via the internet. Any unauthorized 
use, dissemination or copying is strictly prohibited. If you have received 
this e-mail in error, or are not named as a recipient, please immediately 
notify the sender and destroy all copies of this e-mail.

-----Original Message-----
Richard Shockey

It is very very difficult to reconcile the various SIP RFC's into a 
coherent
implementable specification. Dan is correct in pointing out this is 
exactly
what we are trying to do in the SIPforum with SIPconnect and its taking 
much
longer than we anticipated. We've had hours of discussions over 
History-Info
with only marginal consensus on what to actually recommend to the 
industry.

We are NOT writing protocols in the SIPforum but the exercise of creating 
a
profile of SIP for PBX to SSP's also exposes additional flaws in the 
overall
architecture of SIP ( what little exists) that creates huge problems for
implementers, like dealing with e164 and the provisioning of data between
the PBX and the SSP in order to enable service.

IMHO the Hitchhikers guide SIP is NOT a implementable specification more 
of
a road map. 

We need a better way ...