Subject: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 Oct 2001 04:22:16 -0400

Folks,

It is with great pleasure that I announce the availability of
draft-ietf-sip-rfc2543bis-05. Until it appears in the archives, you can pick
it up at:

http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-05.txt
http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-05.ps
http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-05.pdf

As most of you are aware of, this version represents a substantial rewrite
of the specification. As the spec has evolved over time, text was added in
here or there, and the spec grew inconsistent and hard to read. The aim of
this rewrite was to make vast improvements on both the conciceness and
completeness, and the readability, of the specification.

This was no small task, and it was clear that we would need help. So, a "bis
editor" team was formed. In addition to Henning and myself, we added four
new co-authors to the specification: Robert Sparks, Alan Johnston, Jon
Peterson, and Gonzalo Camarillo. Dean and Brian assisted in editing and
guidance, Rakesh provided project management, and a dynamicsoft technical
writer, Jean Mahoney, was brought in to work the text (although her edits
will not reflect until -07). I prepared a new structure for the
specification, and the team began to busily write. We held conference calls
at least once a week throughout September and October, and iterated on the
specification five times before the version above was produced. We even went
through the immensely painful task of tracking every single MUST/MAY/SHOULD
in bis-04 to make sure nothing was lost. The team did a phenomenal job, and
was really dedicated to making this happen in a reasonable time frame. Great
work, team!

If I had to summarize the nature of the change, I would do so in two ways.
First, the new spec is "semantically oriented" instead of "syntactically
oriented". That is, instead of focusing on the syntax, and descirbing
behavior as a side product of headers and methods, the specification focuses
on behaviors, and describes the syntax needed for it. For example, we now
have sections specifically dedicated to initating a session (you'd think
there would be a section on that in a specification called "session
initiation protocol"), modifying a session, and terminating a session. There
is a section that describes registrar behavior from the receipt of a
REGISTER to the sending of a response. As part of this change, the BNF was
collected into one place, and put in the end. We also took the time (Brian
did most of this work) to convert from implicit to explicit LWS. The headers
section has shrunk tremendously, as most of the normative behavior was moved
forward to sections that describe the main operations in SIP.

The second big change was to add layering to SIP. Most of us who know sip
well have recognized its layering, but it is not clear at all from the
presentation. Now, there is an explicit transport layer and transaction
layer. UA processing is defined as a UA "core" layer that sits ontop of the
transaction and transport layers. We have unified transaction processing
between proxies and UAs, so that there is a single set of state machines for
trnsaction processing in all elements. Doing so required a somewhat radical
change in structure; reliability of the 2xx response to INVITE, and the ACK
for 2xx, is no longer handled by the transaction layer. Rather, its done in
the UA core. There are now provably terminating state machines for all four
transaction types - INVITE and non-INVITE client and servers. The
transaction machines have been made transport independent by reverting to
timers for many transitions, rather than retransmit counts. 

As part of the effort to improve readability, there is a lot more tutorial
material. Included is a badly needed four page SIP overview up front, with
increasing details at the front of subsections as you move through the
document. We've also structured it to be top down. Details are towards the
end of the spec, basics up front. 

As a shocker to the PSTN community, the term "call leg" has been eradicated
from the specification with prejudice. The reason is that we are using call
legs for things like subscriptions, which have nothing to do at all with
calls. The new term is "dialog". 

At the direction of the ADs, I have also incorporated
draft-ietf-sip-serverfeatures into bis. In a future revision, the
reliability of provisional responses (draft-ietf-sip-100rel) will be
incorporated as well. For now, there is a placeholder for it to give people
a heads up.

Another big change was the extraction of SDP processing into a separate
document. The offer/answer model was submitted as a personal I-D, which
should appear in the archives soon. Until it does, you can grab a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-mmusic-sdp-offer-answer-00.txt

This has changed little from bis-04. The main change is how hold is done,
based on list consensus. I also added discussion of the ptime attribute.

THe bulk of the change in the spec itself is the presentation and rewrite.
However, there are, of course, some functional changes in the protocol
itself. We have tried to capture as much as we could in the changes section
for draft-05. However, I am certain that there are things that were lost or
added or changed that we missed. Please keep an eye out, and feel free to
point things out on the lists. And definitely read that changes section. 

This draft is not the end of the rewrite; its just the first major
milestone. We now need to get extensive reviews made of it, to verify its
correctness and its readability. Over the next few weeks, we'll be
collecting and integrating those comments and reviews, with the intent of
issuing bis-06 in a few weeks time. So, please take a look and send your
comments! I and the other co-authors will be monitoring the lists more
closely than usual to answer questions (my unusual absence on the list over
the past months has been entirely due to working on bis...)

Thanks,

Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.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: Christer Holmberg <[email-masked]>
Date: Fri, 26 Oct 2001 12:24:20 +0300

Hi,

Here comes the first small comments. 

1. 

The comment in the Via header is still there.

Via               =  ( "Via" | "v" ) HCOLON
                     1#( sent-protocol sent-by
                     *( SEMI via-params ) [ comment ] )

2. 

The definition for outbound proxy still says that ALL outgoing requests
are sent there, not only the initial INVITE (and, of course, every other
request if the proxy record routes).

My question is: has this solution now been agreed on upon the list?
There have been discussions about it before, and I am not sure there
really was a solution (if it was, I missed it).

Regards,

Christer Holmberg 
Ericsson Finland

---

From: Vijay Gurbani <[email-masked]>
Date: Fri, 26 Oct 2001 14:45:31 -0500

Jonathan Rosenberg wrote:
> draft-ietf-sip-rfc2543bis-05. Until it appears in the archives, you can 
> pick it up at:
[...]

Jonathan:

2 issues with -05 bis:

First, since I am updating our proxy to include the new R-R "magic" 
described in -04 bis, the first thing I did was to note the sections of -05 
bis dealing with the R-R "magic".  The sections in -05 bis appear to be 
incomplete wrt to the R-R "magic".  

Second, the routing procedures outlined in section 16.4 for proxies with 
Route headers appear to missing some processing that was present in -04 bis. 
The new routing procedures for proxies processing requests with Route header 
may NOT work.

First, here's what I think is missing from the R-R "magic", along with a
suggestion to make it complete.

   (1) Section 16.6, "Response processing", step 7, first paragraph: the 
       bis mentions that "... the proxy MAY choose to rewrite this value
       before forwarding the response." but (as far as I can make out) 
       provides no guidance on how to rewrite this value.  Note that 
       Section 16.5 provides guidance on how to use Contact (or From) + a 
       transaction identifier in a R-R header when it is being *inserted* 
       in a request.  

       At the very least, section 16.6, "Response processing", step 7, 
       first paragraph can provide some information on how to rewrite
       the value in an R-R response as follows:

       "If the selected response contained a Record-Route header field
        originally inserted by this proxy, AND the proxy had modified
        the request-URI when inserting the Record-Route, it MUST 
        substitue this value with the Request-URI of the initial request, 
        maintaining the maddr field and port field, before forwarding 
        the response."

       This ensures that when the R-R response makes it to the UAC, and it
       creates a Route set, subsequent requests from the UAC will go towards
       the same downstream direction the original request did.

   (2) Provide an example, much as -04 bis did.  I think that R-R rules
       for re-writing R-URIs are complex enough that an example will go
       a long way to ensure clarity, which will aid in interoperability.

Now regarding proxy routing procedures, section 16.4 says that if a Route
header is present, proxies must use this and follow steps outlined in
section 16.5 for further processing this request.  Section 16.5, step 8
refers implementors to section 24 to compute an ordered set of addresses
from the R-URI and send the request downstream.

Problem occurs when a UAC without DNS capabilities has successfully 
established a session using an outbound proxy which R-R'ed.  In this case,
subsequent requests arriving at the outbound proxy have the same R-URI and
topmost Route (since according to rules in section 12.2.1.1, a DNS-incapable
UAC does NOT strip the topmot Route, but DOES use it as the R-URI for the 
new request)

In order to see the problem, consider a proxy for domain example.com which 
received the following re-INVITE from its DNS-incapable UAC:

   INVITE sip:[email-masked];maddr=proxy.example.com SIP/2.0
   Route: <sip:[email-masked];maddr=proxy.example.com>
   Route: <sip:[email-masked]>

The proxy strips the topmost Route header, uses it as the R-URI (leaving 
only 1 Route header in the request) and following Section 24, ends up 
sending the request to *it'self*, without stripping maddr.  If the maddr is 
NOT stripped, during the second iteration, the proxy will attempt to route 
the request to a private address, which may not have any significance 
outside of the fiction.com domain.

-04bis had it right; the proxy should really examine maddr, and if it is one 
of the interfaces that the proxy is listening on, strip it and route based 
on the remaining R-URI.  This makes the request end up at the proxy for
fiction.com domain, which eventually routes it to the private network 
address 10.2.3.44.

Section 16.4, second paragraph can probably be modified to reflect the
behavior of stripping maddr if it is one of the interfaces the proxy was
listening on.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184