Subject: Re: [SIP] Allowing the user@host form on Via header

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 02 Jun 2000 10:39:03 -0400

Sean Olson wrote:
> 
> Comments inline
> 
> > I propose the following changes to draft-ietf-sip-2543bis-00:
> >
> > Page 59, BNF of sent-by for Via header should read:
> > sent-by = ([user@]host[:port])|(concealed-host)
> > where user is as defined in Section 2, on page 18.
> >
> > Also, in section 4.2.6, page 28, description of Request-URI, delete the
> > sentence "The user name MUST be empty."
> >
> > The reason for both changes is that we have a model in which a SIP Server
> > is providing proxy services to a large collection of users.  It often
> > happens that a client belonging to user1 will send a SIP request such as
> > an INVITE to this server.  The server will receive this request and make
> > various decisions according to logic installed on behalf of user1.  This
> > logic frequently requires stateful interactions.  One decision could be to
> > proxy the INVITE to the server for the invited party (user2).  The proxy
> > server for user2 is located on the same host (and same port) as the server
> > for user1.  The server for user2 may create the response to the INVITE or
> > it may proxy it onwards to one or more clients for user2, or perhaps to
> > other users that have been designated by user2.  This is all according to
> > logic installed on behalf of user2. When the response comes back to the
> > server we want the server for user2 to see the response (and perhaps
> > decide to proxy the request to SIP entities) before the response is seen
> > by the server for user1.  The addition of the user part in the sent-by of
> > the via allows such a routing.  If it is ever used in a situation where
> > there is no concept of different servers for different users it is
> > ignored.
> >
> > Note that the branch parameter does not meet our needs since there may, in
> > fact, be no branching.  Also, note that a common port on the SIP Server
> > services all user agents, so the port parameter could not be used to
> > differentiate servers for different users.  And, there may be more users
> > serviced on this host than could be separated with a typical 16 bit port
> > number.
> >
> 
> You would only need to play these games if the proxy you are referring to is
> transaction-stateless. If it is NOT transaction-stateless, then it is a trivial
> matter to add the user information from the Request-URI to the transaction state
> you are already maintaining.

No. This problem is addressed directly by the new mechanisms for loop
detection and computation of the branch parameter. The spec details
these, but is incorrect in its statement that it need only be done for
forking proxies. All proxies are going to need compute and insert the
first piece of the two described pieces of information. We'll correct
this.

Let me explain how this will work for Rays case with the following
picture:

                               +-------------+
                               |             |
                               V             |
                         +-----------+       |
                         |           |     2 |
                         |           |       |
                         |   Proxy   | ------+
                         |           |
                         |           |
                         +-----------+
                                   \
                           ^        \
                         //          \ 3
                        /             \
                       /               \
                     //  1              \
                    /                    V
           /-----\ /                        /-----\
          /       \                        /       \
         |         |                      |         |
         |    U1   |                      |   U2    |
          \       /                        \       /
           \-----/                          \-----/

(PS - figure created by email effects, http://www.sigsoftware.com, which
generates ascii art - this picture took me one minute to do....)

U1 sends message 1 to its proxy, P. The proxy forwards to itself, and
inserts into message 2 a via header with a branch parameter containing
the hash of the request URI from U1. Also note that because the request
URI is different, as is the Via header, when this request is received by
the proxy over again, it is viewed as a different request, and thus
creates a new transaction. It is also NOT viewed as a loop, since the
branch parameters in the Via indicate to the proxy that the previous
time this request was received, the request URI was different. Now, in
step 3, its forwarded to U2, and again the Via header is inserted, with
a different branch paramter again, reflecting the hash of the request
URI in message 2. When the response from U2 comes back, its forwarded
from the proxy to itself, matched with the correct request because of
the branch ID once more. It is then forwared to U1, and we're done.

This approach effectively encodes the user part of the request URI into
the Via header, as Ray was suggesting. However, by using the branch
parameter, we remain backwards compatible and have greater flexibility.

> > The suggestion for removing the sentence about the user part in the
> > Request-URI of REGISTER requests is similarly motivated. There is no
> > reason given in the rfc why the user part MUST be empty in a Request-URI
> > for REGISTER.  In our model, a client will want to REGISTER itself with
> > the server representing it within the SIP Server.  In practice, it would
> > be sufficient to use the From or To field of the REGISTER to determine
> > which server should be used, but in a large system, where the servers
> > might be distributed among many hosts (even though they are seen as a
> > single SIP server host to the outside world) it is more efficient to use
> > the Request-URI for routing purposes so we want the user name to be part
> > of the Request-URI.

In this case, you should do your routing in a specialized way by looking
at the To field, which truly tells you which registrar to go to. This is
purely a local policy decision.

Adding the user name to the request URI in REGISTER is also not
backwards compatible.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip