[*] [Fwd: [sip.edu] Notes from 1-11-2007 call with Henning Schulzrinne]

[John Lange]

This was a very good read.

Was anyone able to find the "Hitchhikers Guide to SIP" mentioned in the
document?

I could only find mentions of it with Google but no actual links to it.

John

On Sat, 2007-01-20 at 15:20 -0600, Bill Reid wrote:
> -------- Original Message --------
> Subject: [sip.edu] Notes from 1-11-2007 call with Henning Schulzrinne
> Date: Sat, 20 Jan 2007 11:04:36 -1000
> From: Garret Yoshimi <gyoshimi at hawaii.edu>
> Reply-To: sip.edu at internet2.edu
> To: Internet2 VoIP SIG <sig-voip at internet2.edu>, "Internet2 SIP.edu" 
> <sip.edu at internet2.edu>
> 
> Hi folks,
> 
> Thanks again to Henning Schulzrinne for presenting on our 1/11/2007
> call.  This was a very well attended call and a great one to start the
> new year.  Notes from the call are included below (thanks to Jeff
> Kuure).  Henning's slides are posted at
> http://www.cs.columbia.edu/~hgs/papers/2007/internet2.ppt .
> 
> Best regards.
> Garret, Walt, Candace & Dennis
> 
> 
> 
> *Discussion*
> 
> Today's call begins with Walt introducing guest speaker Dr. Henning
> Schulzrinne. Dr. Schulzrinne is the head of the department of computer
> science at Columbia University, as well as the director of the IRT lab.
> He is involved with several Internet standards organizations and will
> provide an overview of VoIP and SIP in terms of the IETF.
> 
> Dr. Schulzrinne begins by stating that he feels we are approximately ten
> years into the modern phase of VoIP. There were experimental
> predecessors in the early 1970s, but the current second-generation of
> VoIP began roughly ten years ago and is still rapidly maturing. Ten
> years is a long time, but VoIP is more complicated and depends on more
> protocols than the Web, for example.
> 
> Henning believes that the current situation is the third phase of the
> second generation of VoIP. Starting in approximately 1996, VoIP systems
> were available but never claimed to be equivalent to telephones. They
> were used by hobbyists or to bypass tolls, but were not reliable, had
> undesirable amounts of lag or echo, and were not robust. Users tired of
> demo quality software and lack of features. The second phase
> concentrated on feature parity with PBX systems and a fair amount of
> interest in service creation. The third phase, which is just beginning,
> focuses on adding new features such as presence and location-based
> service, though most of the effort of the IETF is still concentrated on
> feature parity with PSTN systems. Currently VoIP systems are fairly
> close to PBX systems in terms of features.
> 
> A question is asked about the more complicated shared-call features
> which are available on commercial IP Centrex platforms but are difficult
> to implement elsewhere and don't always work with proxies. Henning says
> that this is exactly the set of features that are hard to implement, as
> traditionally the PBX was able to exert media control in these
> situations. Henning feels that there should be some investigation into
> what type of workflows should be supported, and if these shared-line
> models could be better implemented with presence and conferencing
> features. Mimicking the old behaviors exactly is difficult.
> 
> Henning begins talking about the current IETF working groups. In the
> early 1990s, there was one group working with media, the AVT group. Now
> there is an entire area known as Real Time Applications involved with
> VoIP related projects. The AVT group deals with the real-time transfer
> protocol, while the MMUSIC group handles the session description
> protocol (SDP). The various IETF groups all converge with the SIP and
> SIPPING groups, which handle the protocol definition and usage
> requirements, respectively. Other groups generally fall into two
> categories, dealing with either protocols or architecture.
> 
> In the SIP space, unlike the rest of the Internet, there are
> approximately 15 core RFCs necessary to implement most applications such
> as proxies and user agents. The SIP, SIPPING, and SIMPLE working groups
> submit a large number of RFC drafts each year. Henning discusses a slide
> which shows the number of draft-ietf and draft-personal 00 drafts
> submitted on a yearly basis by these groups. The SIPPING group still
> generates dozens of drafts each year, far exceeding any other IETF
> working group, with the SIP group not far behind. The SIMPLE group is
> leveling off, an indication that work with presence is mostly done. Most
> drafts never see RFC status. There have been 44 SIP-related RFCs published.
> 
> Current activity of the SIP working group focuses on a number of areas,
> some of which are important and others that are more narrowly focused.
> There is a guide published online called the Hitchhiker's Guide to SIP,
> which provides a quick overview of SIP specifications grouped by
> category. In terms of infrastructure, there is work being done on GRUUs,
> which are randomly generated SIP URIs. Previously there were two types
> of URIs, one permanent and the other tied to an IP address. The GRUU is
> generated by machine and used for things like NAT traversal and
> registrations. Other work focuses on URI lists, XCAP for configuration
> of devices, and MIB for SIP systems. Services under development deal
> with the rejecting of anonymous requests, a consent framework for calls,
> location conveyance, and session policy. Security topics include work on
> end-to-middle security, certificates, SAML, and SIPS, a secure SIP-based
> calling system. Finally, as with most working groups, dealing with NAT
> is a major issue.
> 
> The SIPPING group is focused on three primary areas. Under the policy
> banner they are working on a media policy as well as a definition for
> session border controllers. For services they are investigating call
> transfer, and providing service examples and call-flow documents.
> Additionally, they are working on text-over-IP, which differs from
> instant messaging or SMS as it is character-by-character, displayed as
> the characters are typed. For hearing impaired users this provides a
> more conversational interface. Transcoding, such as from text to speech,
> is also being investigated. Finally, testing areas include work with
> IPv6, work with various race conditions, and torture tests for
> commercial and open-source proxies. Test events called SIPit, sponsored
> by the SIP Forum, take place every six months, with no spectacular
> failures but no complete successes. In particular, bogus and legal but
> odd requests are not handled well. Overload work is also being done,
> which is more of a concern for carriers.
> 
> Henning mentions that he personally is heavily involved with
> restructuring emergency communication. Issues with emergency
> communication were usually thought to be an issue with VoIP not working
> with the existing 911 infrastructure. Following hurricane Katrina, the
> existing 911 system showed that it was out-of-date and expensive to
> maintain. Billions of dollars have been spent integrating wireless
> systems into the existing 911 system with only partial success. The
> current notion is that extending the current system is not worth it and
> a new system should be built from scratch. This is being funded through
> a variety of means. A large grant from the Department of Transportation
> will lay the groundwork for a new 911 system. The second part is more
> localized, and focuses on deployment. At least five states are in the
> process of generating RFPs for new systems.
> 
> The IETF ECRIT working group is focused the problem of location
> resolution. If given either a street address or a latitude and longitude
> location, which PSAP is the call going to be sent to? ECRIT is
> developing a protocol to do this sort of location mapping. Other work
> focuses on discovering dial strings and how to identify emergency calls,
> and there are still issues with communication between agencies and
> interoperability. The most difficult aspect is actually finding
> locations for devices. It would be helpful if authorized parties could
> reliably locate devices, but there is currently no real consensus on the
> matter.
> 
> The next working group of interest is the SPEERMINT group, which focuses
> on peering and interconnecting different providers. Henning says that at
> first many SIP proponents were naive, and thought that DNS lookups would
> solve their problems. This is still possible, but some carriers need a
> more controlled environment or don't want to forward calls for everyone.
> The mapping problem leverages ENUM, either public or private. One model
> how this might be solved involves the providers needing to find each
> other, exchanging policies, discovering the endpoints, and deciphering
> the media path, which can be problematic with border controllers and
> voice-only networks.
> 
> The AVT working group deals with RTP and SRTP. The main issues involve
> reporting and extended QoS feedback, codec control mechanisms,
> congestion control, and unequal error correction. The most controversial
> is SRTP key management, which several proposals address.
> 
> The MMUSIC group is the home of SDP. There was an effort to build a
> next-generation SDP based on XML, with more expressive description of
> the end system. There has been no great progress to adopt this, and some
> of the features have migrated into the older SDP. The other major issue
> is NAT traversal.
> 
> The newest SIP working group will deal with specifying services. This
> will create more "bandwidth" in the IETF, with more meeting time and
> more chair attention. Henning is not sure when this will happen.
> 
> One other interesting development is the peer-to-peer SIP effort. This
> does not have anything to do with file sharing, but is driven by the SIP
> model of replacing DNS, and, to some extent, SIP registrars. This
> requires a distributed hash table, as well as a protocol to generate
> this hash table, and a protocol for nodes who aren't necessarily
> participating as first-class citizens. This infrastructure could be used
> for many things besides SIP, but for political purposes this is not
> being emphasized. This effort was initially motivated by a desire for
> small stand-alone systems, but is also useful for events such as
> conferences or sports events without needing a proxy to form an ad-hoc
> network. Another development is a published, non-proprietary version of
> Skype, which would operate as a semi-public network. Unlike Skype,
> however, more than one could exist at a time. There are still issues of
> trust and reliability. There are three basic ways to accomplish this,
> using a full distribution similar to Bonjour, DHT using SIP as a
> management protocol, or using an external DHT.
> 
> Henning mentions that there are some open issues, particularly NAT,
> which he feels changes the nature of the Internet. There is no longer a
> single global address space, only locally significant ones. NAT behavior
> is hard to discover - it's difficult to know what part of an incoming
> packet is used for sourcing, how long binding is maintained, and so on.
> Connections can be lost unless one disables silence suppression, and
> working around this by sending SIP REGISTERs every few seconds is
> undesirable. Additionally, NAT may do one thing with 10 connections and
> something totally different with 20. There is a working group named
> BEHAVE which aims to define NAT behavior, but there are millions of
> existing devices which will never be updated.
> 
> Another issue for Henning is the user interface design and configuration
> issues with SIP clients. Inconsistent terminology is used and unexpected
> behavior occurs, leading to many problems. There is an effort to
> automate configuration, but there are many sources of information
> necessary for configuration. Ideally this would allow no-touch
> configuration of thousands of devices, but all of these are proprietary
> and this is difficult to accomplish.
> 
> To summarize the state of VoIP, Henning says that he feels that there is
> basic interoperability and reasonably good performance after any
> configuration hassles are solved. Advanced features are less polished.
> VoIP is also not terribly reliable at the Internet level. BGP plays a
> large role in this, as do NATs. Another problem is that to the user, all
> problems seem the same regardless of what is actually causing the
> problem. Diagnostic reporting is non-existent in hard phones and not
> much better in soft clients. Despite all this, Henning feels that the
> core standards for media and signaling are in place, and real, usable
> systems can be built. There are also several decent enterprise-level
> server implementations. Soft clients are still lacking security,
> implement only a small part of SIP, suffer from long latency, and all
> clients have problems with NAT. There is also an overall priority placed
> on voice traffic over any new services.
> 
> There are also problems with the IETF, as their model does not work well
> for large efforts, such as VoIP. There are a small number of people who
> are spread too thin, leading to relatively simple things taking up to
> five years to accomplish. Henning sees this work not as a simple
> question of protocols but a systems engineering effort as dozens of
> policies, services and protocols need to interact.
> 
> Christine Roe asks about the not particularly rosy picture painted by
> Henning of the IETF, and asks about its future. Henning feels that there
> are essentially two possible outcomes. One option is that the
> organization muddles through in basically the same manner as now, which
> is the likely scenario. The other possibility is that the organization
> devolves into some other form. Henning says that this isn't all a
> problem with the IETF, as they are in a position where their influence
> as a change agent is diminished and they are becoming more reactive than
> proactive. He blames this in part on the "ossification" of the Internet
> as a whole. He's most familiar with the IETF, which is a large volunteer
> organization with weak leadership, but there hasn't been any real change
> in the basic protocol machinery of the Internet in 20 years despite it
> being seen as new and full of exciting developments.
> 
> 
> _______________________________________________
> Asterisk mailing list
> Asterisk at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/asterisk