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

From: Ray Zibman <[email-masked]>
Date: Tue, 30 May 2000 13:12:49 -0400 (EDT)

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.

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.

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

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

---

From: Neil Deason <[email-masked]>
Date: Tue, 30 May 2000 18:37:25 +0100

> sentence "The user name MUST be empty."

Sorry, but I disagree.

> there is no concept of different servers for different users it is

 If I understand you correctly the response will come back to the right place
as the 'two' servers are listening on the same host/port. Not associating the
response with user2 is a local implementation issue. You could for example use
a branch tag, doesn't matter if the request wasn't really forked, or even use
a via-extension param.

> the Request-URI for routing purposes so we want the user name to be part

There is a reason why the user part is empty, because the Request-URI names
the domain of the registrar, not a user within a domain. If the information
you require already is in the To header I don't think a change is necessary
here either.

hth,
Neil
--
Ubiquity Software Corporation, UK           http://www.ubiquity.net