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
