Subject: [SIP] A question on forwarding INVITES

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 18 Sep 2000 17:59:12 -0400

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)?

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?)

I appreciate your help and thank you in advance for your replies.

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Sep 2000 10:51:30 -0400

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Thursday, September 21, 2000 4:59 AM
> To: [email-masked]; [email-masked]
> Cc: Jonathan Rosenberg
> Subject: RE: [SIP] A question on forwarding INVITES
> 
> > 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?
> 
> 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.

Right. Processing at a proxy which owns the namespace indicated in the
request URI really is a matter of local operation. Often this involves
checking the location server database for a registration, in many other
cases it won't.

However, the processing of a proxy of a request for a request whose URI is
NOT in the namespace of the server is a different story; generally, it
should forward the request to that domain using a DNS lookup.

Also note that server processing is different when a Route header is present
in a request. In this case, it should pop the top Route into the request URI
and forward it to the server listed in the domain of the request URI.

-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