Prem,
I have to assume that the "registrar" in your scenario is also an outbound
proxy for the users that register with it. The registrar would already have
location information for inbound INVITEs from the Contact headers in the
REGISTER messages.
The registrar would only need to get location information for outgoing
INVITEs. In that case, a location server that talked SIP would probably act
as a redirect server, returning a 3xx class response with a list of
locations (in Contact headers) to which the INVITE should be forwarded. A
200 response would only be proper if the INVITE actually reached a UAS,
which would make the location server a SIP proxy.
(-:bob
Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[EMAIL PROTECTED]
----- Original Message -----
From: "Prem Sumetpong" <[EMAIL PROTECTED]>
To: "Jo Hornsby" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 11, 2001 10:58 AM
Subject: RE: [Sip-implementors] Registrar question
> On Tue, 10 Jul 2001, Jo Hornsby wrote:
>
> >
> > Prem Sumetpong wrote:
> > > Since SIP doesnt define the interface between the registrar and
location
> > > service and leaves it to the implementation
> > >
> > > The assumptions then are
> > >
> > > - registrar and proxy are (must be ??) from the same vendor. The
"how
> > > to" fetch and store from the shared storage is known by both the
> > > registrar (stores) and proxy (fetches).
> >
> > No, not necessarily. The registrar and proxy might just
> > need to be configured with some ODBC Data Source (e.g.,
> > an Oracle DB), or an LDAP Server.
> >
>
> what is the schema or database data dictionary shared between the
two
> that will be fetched via LDAP or ODBC/JDBC so that a proxy from one vendor
can
> work with a location server from another vendor ?? If it is not a
published one
> then how can interoperability be guaranteed.
>
> Or at least there needs to be an API that hides the underlying
store and
> its details.
>
> > > or.- there is a published interface (schema/dictionary/api) for
storing
> > > and fetching the registered addresses.
> > >
> > > Am I right to say that SIP doenst address the latter ??
> >
> > Yes.
> >
>
> > > Wouldnt that
> > > cause an interoperability problem ??
> >
> > No, not really, unless people wanted to deliver "Location
> > Servers" that didn't talk SIP, but talked some new
> > protocol X.
> >
>
> Assuming the location server talked SIP - would an INVITE to location
server
> from a registration server cause it to return location information in the
200
> OK response ??
>
> If the location server/service talked SIP and used
> LDAP/JDBC/ODBC as its backend then the schema/database data dictionary
doesnt
> needs to be exposed.
>
> Most call flows in the drafts or tutorials or SIP documentation dont
show
> location server talking SIP.
>
>
> > In practice, this isn't going to happen because we have
> > things like LDAP and rwhois and finger and JDBC and X.500
> > and and and. These are going to be typical "Location
> > Servers". The most important thing to remember is that
> > user discover and whathaveyou relies on some abstract
> > notion of a "Location Service"; in essence, this could
> > be absolutely anything, and in some cases thinking of
> > it as fronting some "Location Server" is not going to
> > be so helpful (imagine a proxy that does all it's routing
> > based on an in-memory set of regular expressions).
> >
>
> true. The original question was from the perspective of registration
> server/location service and proxy server are two seperate logical entities
with
> a well defined interface to getting location information.
>
>
> Prem
>
> > HTH,
> >
> >
> > - Jo.
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [EMAIL PROTECTED]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
