Subject: [RAI] Moved to RAI: A call for simplicity

From: Dean Willis <[email-masked]>
Date: Tue, 3 Mar 2009 13:41:51 -0600

I've moved this to RAI, since it really goes beyond the charter of  
SIPPING.

On Mar 3, 2009, at 11:15 AM, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Session Initiation Proposal  
> Investigation Working Group of the IETF.

At the risk of sounding like Henry, I think we have good cause to  
worry when we consider that we are on the 12th rev of our call  
transfer draft, and that the SIPPING working group version was  
preceded by 5 versions in the SIP working group. Even earlier, we had  
the original one individual version published in March, 2000.

What kind of monster have we created that it takes nine years and 18  
versions of a draft to specify call transfer, and we're still not  
done? [Ed: Mary says we are very close to done with this one. It's  
about time!]  The kudzu has eaten the crop, and it may be time to just  
spray Roundup on the whole field and replant. Learning to eat kudzu is  
not a viable option.

Seriously, we need to step back, take a deep breath, and think very  
seriously about simplifying the whole SIP framework instead of  
elaborating it further. I don't know that I completely agree with  
JDR's modest proposal about accepting the SIP-as-SBC-mediated- 
telephony-over-IP model as our entire scope, but we have to do  
something.

How about freezing SIP 2.0 in maintenance mode, taking on no further  
work (except for bug fixes), and starting a SIP 3.0 exercise that uses  
things we learned from SIP 2.0, including but not limited to:

1) Isolating the application, transaction, rendezvous/naming, and  
transport layers.

2) Supporting, or better, fundamentally integrating strong end-to-end  
identity.

3) Recognizing and formalizing the roles of active intermediaries that  
exceed the limitations of SIP 2.0 proxies.

4) Limiting optionality.

5) Including strong compliance specifications that can be tested  
against and certified independently.

I'd also like to put in some text about reusing/sharing connections  
and muxing signaling and media onto an address/port pair, but I'm sure  
that would cause somebody around here to self-destruct. Perhaps this  
could be accomplished by:

6) Assume that NAT, NAPT, and address family (IPv4/IPv6) translators  
are ubiquitous, and based on this assumption optimize the protocol  
design so as to minimize the protocol adaptation mechanics required to  
traverse those translators. In other words, stop referring to  
addresses and ports inside the payload.

Note: From a metrics perspective, it is interesting that the draft has  
been revised just over twice for every three meetings, which may go  
towards disproving the "drafts are revised for each meeting" theory,  
or perhaps restating it as "Drafts are revised, on average, no more  
than once for each meeting cycle."

--
Dean Willis, frustrated SIP gardener.

---

From: Theo Zourzouvillys <[email-masked]>
Date: Tue, 3 Mar 2009 19:56:43 +0000

On Tue, Mar 3, 2009 at 7:41 PM, Dean Willis <[email-masked]> wrote:

> How about freezing SIP 2.0 in maintenance mode, taking on no further work
> (except for bug fixes), and starting a SIP 3.0 exercise that uses things we
> learned from SIP 2.0, including but not limited to:

wow.  I was going to propose something almost identical after/in SF.
I really, really, *really*  like the sound of something like this.

I would be more than willing to donate a large amount of time to this,
both personally and through other members of my team.

 ~ Theo, frustrated two-stroke lawn mower engineer.

---

From: Adam Roach <[email-masked]>
Date: Tue, 03 Mar 2009 14:41:28 -0600

> against and certified independently.

Ooh, and we can get an H.xxx number assigned to it, too!

No, really -- "limiting optionality" inherently means "killing 
extensibility," which is the first and most important step towards 
destroying innovation.

/a

---

From: Michael Procter <[email-masked]>
Date: Tue, 03 Mar 2009 21:01:35 +0000

> extensibility," which is the first and most important step towards

Just to play Devil's Advocate on this one, the alternative (unlimited
optionality?) leads to "killing interoperability".  Whilst neither
extreme is particularly desirable, surely we can find some middle ground.

Maybe we should take a leaf out of Douglas Adams' books: "We demand
rigidly defined areas of doubt and uncertainty!".

Regards,

Michael

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 3 Mar 2009 15:07:49 -0600

I agree with Dean's stated concern here, but that hardly matters for my 
point - without predjudice in either direction, we should be thinking about 
HTTP-NG, which was a similar effort for HTTP in the late 1990s ("now that we 
have a clue what the solution should look like, let's do it right this 
time").

Background at http://www.w3.org/Protocols/HTTP-NG/Activity.html (this even 
included adding layering and multiplexing, so we've been there before).

Just so we don't repeat the experience unintentionally, of course...

Spencer

> At the risk of sounding like Henry, I think we have good cause to  worry 
> when we consider that we are on the 12th rev of our call  transfer draft, 
> and that the SIPPING working group version was  preceded by 5 versions in 
> the SIP working group. Even earlier, we had  the original one individual 
> version published in March, 2000.
>
> versions of a draft to specify call transfer, and we're still not  done? 
> [Ed: Mary says we are very close to done with this one. It's  about time!] 
> The kudzu has eaten the crop, and it may be time to just  spray Roundup on 
> the whole field and replant. Learning to eat kudzu is  not a viable 
> option.
>
> elaborating it further. I don't know that I completely agree with  JDR's 
> modest proposal about accepting the SIP-as-SBC-mediated- telephony-over-IP 
> model as our entire scope, but we have to do  something.
>
> (except for bug fixes), and starting a SIP 3.0 exercise that uses  things 
> we learned from SIP 2.0, including but not limited to:
>
> 5) Including strong compliance specifications that can be tested  against 
> and certified independently.
>
> I'd also like to put in some text about reusing/sharing connections  and 
> muxing signaling and media onto an address/port pair, but I'm sure  that 
> would cause somebody around here to self-destruct. Perhaps this  could be 
> accomplished by:
>
> 6) Assume that NAT, NAPT, and address family (IPv4/IPv6) translators  are 
> ubiquitous, and based on this assumption optimize the protocol  design so 
> as to minimize the protocol adaptation mechanics required to  traverse 
> those translators. In other words, stop referring to  addresses and ports 
> inside the payload.
>
>
> towards disproving the "drafts are revised for each meeting" theory,  or 
> perhaps restating it as "Drafts are revised, on average, no more  than 
> once for each meeting cycle."
>
>
> --
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 3 Mar 2009 13:28:20 -0800

>rigidly defined areas of doubt and uncertainty!".

Totally agree: That's what Wikis and blogs are for.

It is time we move from the tools available to the IETF in the mid 90's.
Not to mention abandoning the mandatory .txt document format...

Henry

On 3/3/09 3:01 PM, "Michael Procter" <[email-masked]> wrote:

Regards,

Michael

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 03 Mar 2009 18:05:15 -0600

>extensibility," which is the first and most important step towards

This is an important point and must look closer:

* I do not remember any real innovations enabled by SIP, but please feel
free to refresh my memory.

* Real innovations have happened elsewhere on the Internet and the Web such
as p2p, wikis, blogs, social networks and web conferencing. This is the
reason why we buy broadband and smart phones  not call forwarding and
Centrex..

The IETF RAI has tremendous potential that will be realized IMO by divorcing
from the technologies that actively oppose e2e and the Internet
architecture. 
This amicable separation can and must be be done on our watch. The latest
SIPCore charter appears to be a good start, if this was envisaged. The
support for e2e is certainly they key issue for SIPCore.

Henry
(my strict personal opinion)

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 4 Mar 2009 01:29:28 -0500

________________________________________
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, March 03, 2009 7:05 PM
> To: Adam Roach; Dean Willis
>
> The IETF RAI has tremendous potential that will be realized IMO by divorcing from the technologies that actively oppose e2e and the Internet architecture.

[HK] Yes, we should stop using email.  It's not end2end and thus evil; and I have seen no innovation in email for years - who uses it anymore??  Also, these so-called "p2p" applications which use other people's PC's for discovery and relay on the Internet between me and the far-end host, they should be banned for not being end2end.  And so too recursive-resolver DNS's, and DHCP Relays, and mobile-ip Home Agents, and SOCKS, and NAT's, and Firewalls, and HTTP load-balancers, and HTTP caches, and HTTP anonymous proxies, and VPNs, and XMPP servers, and MSRP Relays (truly for that one), and AIM/OSCAR, and YIM/YMSG, and MSNP, and any other protocol, device or application that does not send my laptop/pc/phone's packets/messages directly to a far-end human's laptop/pc/phone at an IP layer.

Long live ICMP Ping! (but not traceroute)

-hadriel

---

From: Alan Johnston <[email-masked]>
Date: Thu, 05 Mar 2009 14:39:19 -0600

> spray Roundup on the whole field and replant. Learning to eat kudzu is 

So, here's my take on this.   This version of the document is to clear 
the last DISCUSSes on it so it can be published.   Besides the usual 
reasons why a draft like this takes so long (editor changes/delays, 
etc.) is that it touched on a major bug in RFC 3261.  We knew about the 
bug when we published RFC 3261 but we just punted on it.  The fix we 
developed isn't even published as a RFC yet, although it is in the RFC 
Editor's Que.  Have you guessed what I'm talking about?  It is GRUU, of 
course.  We had to wait until this problem (and the problem of dialog 
correlation, solved by Target-Dialog) were solved before we could finish 
this draft.

Of course, the jury is still out on whether we have solved this problem 
at all - no one has delayed deploying and developing SIP despite this 
huge bug, so everyone has their own work around.  Will GRUU be widely 
deployed - we shall see.

I think this does tie into Dean's call for simplicity.  How often do we 
identify a bug or a problem, but take years (if not a decade) to 
actually finalize a solution for it?   There is something fundamentally 
wrong with the way we have tackled problems like GRUU in the past.

Publishing potential solutions as RFCs quickly, even if they aren't 
fully baked seems to be a better alternative than waiting almost a 
decade to publish a so-perfect-no-one-will-ever-implement solution.

Thanks,
Alan
> JDR's modest proposal about accepting the 
> SIP-as-SBC-mediated-telephony-over-IP model as our entire scope, but 
> we have to do something.
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 5 Mar 2009 12:50:33 -0800

All this proves Robert Spark's proposal to rewrite (if I remember correctly) RFC 3261 to be right.

There is plenty of things that have been learned, probably 99.9%.

The argument there are no writers to do this work sounds bizarre, given the flood of new Internet Drafts on SIP and SIPPING, both by the original authors of RFC 3261 and by new contributors as well.

Henry

On 3/5/09 2:39 PM, "Alan Johnston" <[email-masked]> wrote:

Thanks,
Alan

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 01:13:07 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
> Roach
> Sent: Tuesday, March 03, 2009 3:41 PM
> 
> Dean Willis wrote:
> >
> > 4) Limiting optionality.

I agree, but only in some aspects. 
Things like ignoring unknown methods/headers/params/mime/etc. are vital, yet constantly cause issues.  Having required/supported/accept/allow and such are vital, yet constantly cause issues.  I dunno what to do bout that.  

Where I think it goes nuts is on the ability to do the same thing different ways.  Re-Invite vs. UPDATE?  From vs. P-Asserted (vs. P-Remote-Party)?  Tel vs. Sip schemes?  The SDP offer/answer model with offerless-Invite/PRACK?  History-Info vs. Diversion?  Bleh.  And the issues with offer/answer will be someone's thesis paper, as will the ABNF rules.

The first thing I'd delete would be offerless-Invites, followed by re-Invites, and then parallel-forking.  If you don't know the type of media you want to offer, don't invite someone to a session; if you need a 3PCC model, then suck it up and send UPDATEs, after the INVITE transaction is done.  It's UPDATE only inside a dialog.  And proxies shouldn't parallel-fork, only UAC's should (which would not be parallel forking, but just creating multiple new sessions, some of which they can decide to cancel/end if they want).  And I'd clean up the response codes.  It doesn't matter what caused you to reply (that should be the reason-phrase) - what matters is what the previous hops should do when they get it, and there are only a few codes really needed for that.  And kiss early dialogs goodbye, 'cause 1xx is out, as is PRACK.  PRACK, REFER, and offerless-INVITEs would be added to a hall-of-fame list for interop issues.

Ahh... if only life were so simple.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Mar 2009 19:34:18 -0600

On Mar 3, 2009, at 12:41 PM, Dean Willis wrote:

> elaborating it further.

One rhetorical question - would the simplified framework support end  
user functionality we generally call transfer? If the answer is yes,  
it is not clear exactly how to make it significantly simpler thought I  
can believe there might be ways. If the answer is no, well a lot of  
people are willing to implement the current level of complexity to get  
that feature because it seems to get used in many deployments.

---

From: Dean Willis <[email-masked]>
Date: Thu, 12 Mar 2009 00:03:08 -0500

On Mar 11, 2009, at 8:34 PM, Cullen Jennings wrote:

> it is not clear exactly how to make it significantly simpler thought  
> I can believe there might be ways. If the answer is no, well a lot  
> of people are willing to implement the current level of complexity  
> to get that feature because it seems to get used in many deployments.

We have certain complexity-driving factors deeply buried in our  
protocol. These include things like:

1) Entangling application state with transport, which includes being  
unable to separate the transaction layer from the application, the  
complexity of three-message INVITE and two-message non-INVITE  
transactions, the inclusion of provisional messaging at the transport  
layer, intertwingling the "did your phone get this message" concept  
with the "did your user press the forward-to-voice-mail-button"  
concept, and so on.

2) PRACK and its entire family of misbegotten mind-bendingly complex  
bad ideas, including preconditions.

3) Early media and the related inability to decouple our transport  
model from the broken disjoint-path resolution model (and associated  
billing idioms) of the PSTN.

4) SDP and its inability to say what we mean.

5) Insistence on discussing media addresses in the signaling protocol,  
which as anybody who ever pondered FTP knows is a Bad Idea.

7) An astoundingly open-ended verbiage around transfer. Yes, transfer  
alone COULD be defined more simply than REFER does it. REFER is, I  
might speculate, God's own protocol message, as nobody below that  
level is likely to understand all its ramifications. And since I have  
agnostic leanings, I'm not all that sure ANYBODY really understands  
it. A much simpler in-dialog mechanism could pretty much get the job  
done.

8) Third-party control and the offerless transaction.

9) Reinventing transport reliability, confusing it with transactional  
reliability, and using the result to trigger retransmit-storms that  
lead to congestion collapse.

10) Something else I can't remember, but is probably worse than  
anything I've listed here, and may have something to do with knowing  
who you're talking to.

So: Could we effectively do call transfer with a simpler protocol  
base? Skippy damned right we could!

Now, are people willing to use what we have to get their work done? Of  
course they are. Sort of. It's amazing what can be done with SIP  
despite its imperfections. It's a powerful tool, amazingly flexible in  
its applicability. Do people use all of it? Not yet, and I don't think  
they ever will.

So the question is: would redesigning the tool for simplicity make it  
easier enough to use to make the effort of redesigning it worthwhile?  
I tend to think "yes" is the answer here, to the extent that any  
standard is worth developing.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 12 Mar 2009 02:36:23 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings
> 

There's no doubt that transferring a session is mandatory.  The thing that really blows my mind though, is that in my experience few people actually intend or want the REFER (and/or INVITEw/replaces) to be processed by the real UA's involved.  Now maybe it's just the specific Enterprises and Providers my company sells to, but since it looks like a lot of the systems made by the folks in RAI process them "on-behalf-of" the remote UA's, my sense is I'm not dreaming.  I don't know why it's so surprising to me, because the rationale for it makes a lot of perverse sense, but still it makes me wonder what kind of monster transfers will become when the architecture assumes end-to-end.

-hadriel

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 12 Mar 2009 08:07:27 -0700

>base? Skippy damned right we could!

I don't mind being flamed on this, but call transfer and most other telephony call control functions can be done in two ways:

 *   At the SIP protocol level, such as illustrated in RFC 5359 and RFC 36665, or

 *   At the application level, between any UAs that know about each other via the SIP rendezvous function. There are no standards for this and maybe need not be, unless interoperability with legacy is absolutely required. Advanced call control functions are mostly used in customer support networks and using specific telephony applications there can be left to those specific applications. Using Darwinian innovation like on the Web, such networks may be left best out of Internet standards anyway, given the potential of integrating voice with rich data applications.

The IETF would do both application developers and the Internet a favor by not spending time and resources on telephony functions that may actually impede innovation for those who need it. Set free the creativity of developers for customer support centers and give competition a chance.

The SIP protocol base need not be much more than rendezvous and session negotiation. SIPCore sounds about right.

Henry

On 3/12/09 12:03 AM, "Dean Willis" <[email-masked]> wrote:

---

From: Greg Herlein <[email-masked]>
Date: Thu, 12 Mar 2009 09:55:59 -0700

I agree with Henry that we should not try to standardize telephony
call control functionality.   I don't do much telephony development
anymore, but over the years I've done call control with H.323 (ick),
Net2Phone API, DeltaThree API, SIP, Genesys TServer API, several
protocols that I made up, and of course the Linux Telephony API that I
co-developed.  Most of the time we picked the call control scheme for
a project based on various business factors and we did not need a
grand unified call control scheme like traditional telephony has.
Look at Asterisk - IAX did not wait for the IETF to become so dominant
in the open source telephony world.

The power of the Internet *is* the endpoints and the disruptive power
of new ways of doing things.   Some of those innovations stick, some
don't.  I think the IETF serves a role to establish base
interoperability but the process can result in a stifling effect.  I
speak to a lot of folks who just dismiss the IETF as a waste of time.
These complaints may not be factual but the perception is:

- IETF WG's take too long to accomplish anything
- the resulting standards are often too complicated
- no one ends up implementing all of a spec since it seems like
there's no real world use case for all the stuff
- the only entities that can and do implement close to the full specs
are big companies who also pay staff to be on the WGs - and are they
complicated on purpose?
- no innovation happens in the IETF - all the disruptive innovation
happens at the edge and gets standardized later if at all (like IAX)

I tend to agree with folks who think that all standards should have a
working reference implementation in the real world - preferably with
source code available for inspection if not re-use.  I also think that
simple is good, less is more, and that success is measured by
adoption/usage rate and not how clever something is.  So I agree with
Henry a lot.  :)

Greg

On Thu, Mar 12, 2009 at 8:07 AM, Henry Sinnreich <[email-masked]> wrote:
> I don’t mind being flamed on this, but call transfer and most other
> telephony call control functions can be done in two ways:
>
> At the SIP protocol level, such as illustrated in RFC 5359 and RFC 36665, or
>
> At the application level, between any UAs that know about each other via the
> SIP rendezvous function. There are no standards for this and maybe need not
> be, unless interoperability with legacy is absolutely required. Advanced
> call control functions are mostly used in customer support networks and
> using specific telephony applications there can be left to those specific
> applications. Using Darwinian innovation like on the Web, such networks may
> be left best out of Internet standards anyway, given the potential of
> integrating voice with rich data applications.
>
> The IETF would do both application developers and the Internet a favor by
> not spending time and resources on telephony functions that may actually
> impede innovation for those who need it. Set free the creativity of
> developers for customer support centers and give competition a chance.
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 19:17:36 +0200

Hi Greg, 

Thanks for your feedback. 

>- no one ends up implementing all of a spec since it seems 
>like there's no real world use case for all the stuff
>- the only entities that can and do implement close to the 
>full specs are big companies who also pay staff to be on the 
>WGs - and are they complicated on purpose?
>- no innovation happens in the IETF - all the disruptive 
>innovation happens at the edge and gets standardized later if 
>at all (like IAX)

Any ideas on how we could improve the situation? 

Anything useful in Section 3 of
http://tools.ietf.org/html/draft-tschofenig-rai-reducing-delays-00? 

Ciao
Hannes

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 13 Mar 2009 01:43:37 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg
> Herlein
> Sent: Thursday, March 12, 2009 12:56 PM
> 

Protocols created by a single company (effectively), are always faster and easier to specify and deploy.  This is not news.  Consensus building is really hard and takes time, because it is an inclusive process with many participants and no King.  And in the IETF we generally try to not make assumptions about specific vendor implementations, nor focus on a specific community of users - protocols which do are easier to design and deploy, which again is not news.

And it wasn't IAX that made Asterisk popular, afaict.  Asterisk is popular because it's free, has a ton of features, and can be changed to suite one's needs.  IAX is "popular" only because Asterisk uses it, and for its user community it does what it needs to do.  Novell IPX was quite popular too, as was Banyan Vines, Appletalk, etc.

> of new ways of doing things.   

Ironically, Asterisk is not an endpoint, afaik.

> Some of those innovations stick, some
> interoperability but the process can result in a stifling effect.  

Yes we're trying to fix that.  All suggestions are welcomed. :)

> are big companies who also pay staff to be on the WGs - and are they

I don't think they're on purpose - or at least I darned well hope not.  And there are quite a lot of us who are not paid to be in the WG's, in the sense that it is not our day job. (most folks don't have to take vacation days to go, and many get their expenses paid for sure, but I'm not sure if that's what you mean)

> happens at the edge and gets standardized later if at all (like IAX)

In what way is IAX a disruptive innovation?

-hadriel

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 13 Mar 2009 09:57:06 +0100

> Ironically, Asterisk is not an endpoint, afaik.

I can only disagree. Based on the most important draft of the last
year, http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt, it is.
I can't await to have it RFCed.

> In what way is IAX a disruptive innovation?

While I quite agree with the conclusion (in the end innovation is not
synonymical with standardization), I'm also keen to learn more about
what is disruptive in this example.

-jiri