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

From: Sean Olson <[email-masked]>
Date: Tue, 30 May 2000 15:26:27 -0500 (CDT)

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. Frankly for the application you have in mind, it
makes more sense to use a stateful proxy than to try and change the way SIP Via:
handling works. (Though I think your use of the term "proxy" is a little different
from what I mean given your assumption that you have two proxies on the same machine
using the same port; in your case, the routing you are doing seems to be an internal
application decision and doesn't need to be explicitly handled by the SIP protocol)

> 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.
> 

Though I don't agree with this statement, I do agree that the user name should
be allowed in the Request-URI.

> Ray Zibman
> Senior Scientist
> MetaTel, Inc.
> 45 Rumford Ave.
> Waltham, MA 02453
> (781) 392-2509

--
Sean Olson <[email-masked]>
tel: 972-583-5472

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