Subject: RE: [SIP] A question on forwarding INVITES

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Sep 2000 01:44:48 -0400

> -----Original Message-----
> From: M. Ranganathan [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 5:59 PM
> To: [email-masked]
> Subject: [SIP] A question on forwarding INVITES
> 
> 
> Hello!
> 
> When a proxy server forwards an invite,  does it need to have a
> registration from the server that it is forwarding it to (or 
> is this an
> implementation choice)?

No, it doesn't need to have a registration.

Routing is a matter of local policy. A proxy can use whatever means it sees
fit to determine what next hop to forward to.

> 
> Second,  it would appear to be a good idea to periodically propagate
> user location information  between proxy's  to reduce latency  in  for
> user location.  If so, is there a  recommended method to do this? (and
> if not, is there a good argument against it?)

Let me make sure I am understanding what you are proposing. Lets say I
register to engineering.dynamicsoft.com. Your proposal is that my
registration basically be propagated to dynamicsoft.com as well, so that
calls for me ([email-masked]) can go directly to my PC, rather than
first to engineering and then to my PC?

There is no way for this to be done now; its close in concept to what TRIP
provides, but in this case its intra-domain and not phone numbers.

I don't think its a good idea in any case, as it presents a monstrous
scalability problem. I'll also note that in many cases proxies exist on the
call establishment path for useful purposes, and bypassing them is not
necessarily a good thing.

-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: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 20 Sep 2000 15:42:10 -0400

Based on your response to the first question, I am assuming that it is OK to
forward INVITEs to unregistered UAS's  as well.  The proxy can extract username
and host from the  SIP Url that is part of the request and use this to forward
the request. Of course,  this could result in servers sending unsolicited
invites (which are ignored by the UAS).

I have a follow-up question regarding user locaton and forwarding of invites.
( These are newbie questions so put the kid gloves on).

In my design, I  am making  the following assumptions:

1. If the target of the invite has not REGISTERed, then the invite is forwarded
based on address imbedded in the SIP url.

2, If the targetted user HAS a valid REGISTER, then  the addresses in the
registration record is used to forward the INVITE.

If 1 and 2 fail  then

3  Do a  lookup via LDAP or rwho etc (i.e. use a  location server) to figure
out where to send the invite where the information needed to do the lookup is
available as SIP URL parameters (name, value pairs).

Is item 3 the responsibility of the SIP proxy server? The RFC seems to indicate
that the SIP server MAY talk to a locaton server in addition to using REGISTER
(and there must be a good reason for it).  I realize that this is a design
choice but it affects the complexity of the system.   Why not let it be the
caller's responsibility to locate the user by talking directly to location
services if need be?

Thank you for answering  both my  previous questions.

Regards,
Ranga.

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0934

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 21 Sep 2000 09:59:15 +0100

> Based on your response to the first question, I am assuming that it
> is OK to forward INVITEs to unregistered UAS's as well.  The proxy
> can extract username and host from the SIP Url that is part of the
> request and use this to forward the request. Of course, this could
> result in servers sending unsolicited invites (which are ignored by
> the UAS).

Very much so.  If a SIP URL is specific enough that it can be
resolved to an IP:port, for instance, it is completely reasonable
for a SIP client (be it UA or proxy) to try that address "directly".

> I have a follow-up question regarding user locaton and forwarding of
> invites.  ( These are newbie questions so put the kid gloves on).
> 
> 1. If the target of the invite has not REGISTERed, then the invite
> is forwarded based on address imbedded in the SIP url.
> 
> 2, If the targetted user HAS a valid REGISTER, then the addresses in
> the registration record is used to forward the INVITE.
> 
> If 1 and 2 fail then
> 
> 3 Do a lookup via LDAP or rwho etc (i.e. use a location server) to
> figure out where to send the invite where the information needed to
> do the lookup is available as SIP URL parameters (name, value
> pairs).
> 
> Is item 3 the responsibility of the SIP proxy server? The RFC seems
> to indicate that the SIP server MAY talk to a locaton server in
> addition to using REGISTER (and there must be a good reason for it).
> I realize that this is a design choice but it affects the complexity
> of the system.  Why not let it be the caller's responsibility to
> locate the user by talking directly to location services if need be?

As Jonathan said, a proxy can use whatever means it sees fit to
route.

I might be mistaken, but it seems to me that you're unnecessarily
separating the database "used" by a REGISTER, and a Location
Server.  Basically, these are the same thing.  The RFC uses the
term "Location Server" to abstract the entity that is responsible
for resolving one URI into zero or more URIs.  In simple proxies
that have co-located registrars, a "Location Server" will simply
be a database of all active registrations.

In your steps above, item 1 is interesting, because typically it
always has to be done (okay, I've got a SIP URL, how do I
proceed?).  In general, it's going to consist of steps similar
to those specified in Section 1.4.2.  However, that is totally
up to the proxy.

Thus I would fold item 2 into item 3 (i.e., REGISTERs modify
the Location Server"), and then in a simple implementation you
might get the following:
 a) Apply item 3 to the Request-URI.
 b) If a) yields no results, apply item 1 to the Request-URI,
    and if this resolves to some network address, forward the
    Request there.
 c) If a) yields one or more results, apply item 1 to each
    URI in turn, and forward the Request to each URI that
    resolves to a routable network address.

Other implementations may apply item 1 recursively, or perform
b) regardless of the result of a), or never apply item 3 at
all...the possibilities are endless.

HTH,

 - Jo.