Subject: RE: [SIP] Some brief comments on the SIP MIB

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Nov 2000 03:45:09 -0500

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, October 29, 2000 8:30 AM
> To: Kevin Lingle
> Cc: [email-masked]
> Subject: Re: [SIP] Some brief comments on the SIP MIB
> 
> > >
> > > - ULS should probably at least mention LDAP as an example.
> > 
> > ULS has undergone some changes.  We had a request to handle 
> prioritzed
> > backup addressess.  I also got some comments that having one generic
> > ULS address wasn't sufficient.  Systems may have multiple 
> resources they
> > use to determine where users are.
> > 
> > You can view the proposal on [email-masked] archive
> > [http://www.egroups.com/message/sip-mib/40].  There has been no
> > feedback on the proposal yet (unfortunately that is typical).
> > I would appreciate if you could take a quick look.  Btw, the
> > current proposal does not actualy handle prioritized addresses
> > correctly (i need to consider that further).  What is your view
> > on having the ability to specify backup addresses ULS?
> 
> Probably needs discussion by those building proxies, as I can 
> primarily
> speak from our own experience. In our server, locations are 
> derived from
> several different sources
> 
> - LDAP
> - an SQL database for registrations
> - a set of user-configurable scripts that provide mappings 
> from SIP user
> ids to other user id's, e.g., resolution of email aliases.
> 
> While being able to change the LDAP URL via the management console is
> useful, I doubt that describing or changing the others is particularly
> helpful (and not likely to be feasible, given that just 
> connecting to a
> different SQL server just doesn't magically make the table definitions
> appear there).

I think the notion of generalzied, configurable ULS through SNMP is
fundamentally a hopeless cause. THe problem is that a location service is an
abstract concept. It can be the result of program execution, LDAP queries,
SQL queries, ENUM, finger, whois, local files, IVR interaction, etc. Your
assumption is that in all cases there is at least an IP address that
indicates where the service is. I don't think thats generally true. Certain
location services (local file, IVR interaction, program execution), don't
really have such a concept. 

So, there are two choices. Either completely drop this ULS thing, or
restrict it to a specific set of known location services which do have a
common set of configuration information. Access to an external database is
probably pretty broad but has a common set of information that you could
configure (IP address, username and password for access, port, transport,
database instance name)

-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: Kevin Lingle <[email-masked]>
Date: Wed, 08 Nov 2000 14:56:28 -0500

> really have such a concept.

this is the general feeling i've been having about this.  it's good to hear
you say this.  that said, i'd still like to explore the issue a bit more.

> configure (IP address, username and password for access, port, transport,

i can't drop ULS completely w/out replacing it with something.  primarily
because to this point, the ULS addr object has been used for a gateway to
specify the ip address of the sip proxy/redirect it uses.  

question: is calling a sip server an abuse or mis-use of the term "user 
location server"??  i was thinking that from a gateway's perspective, it 
looks to a sip server as one potential user location server (ie, doesn't know
where to go next to setup session to a terminating gateway)  now i'm 
wondering if that's confusing sip things with non-sip things like external
databases.  i've been using the term that way for a long time and noone 
has really objected.

so i will at least need sip server address info somewhere to replace ULS addr 
object if it goes away.  perhaps a specific sipServerAddr object added to SIP-UA-MIB??   
we were trying to also allow for backup sip server addresses... a request
we got a while back from someone on the sip-mib list.  do you think that is of value??

i'd like to try and identify a small set of known location services that we
think will be common enough that you'd expect to find them used by most sip 
entities.  if such a list can be identified then the question is how appropriate 
is that content for a standard sip mib?  if used by most sip entities, it would be 
convenience to provide the ability to address these resources.  the alternative
would be non-standard variety of ways to configure such things (other mibs). 
i could use some wisdom/guidance here, jonathan.

kevin
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police.html
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 08 Nov 2000 15:04:34 -0500

Kevin Lingle wrote:

> specify the ip address of the sip proxy/redirect it uses.

That is not in any way related to a "location server". If you want to
specify the default outbound proxy (which this seems to be), that would
be useful, but it's a separate category from a location server.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Kevin Lingle <[email-masked]>
Date: Wed, 08 Nov 2000 15:28:35 -0500

> be useful, but it's a separate category from a location server.

that was what i was afraid of :(  the mib needs to be corrected then.
funny, this uls addr object has been in the mib since -00 rev of the I-D
and the description has been very clear that a sip server was a possible 
use of the object.  

i am going to create a new object in the SIP-UA-MIB that is specifically
for configuring the address of the sip server a user agent use.  again,
is there any value in allowing for multiple server addresses to be 
configured (eg, for backup purposes)?  we had a request for that a while
back on sip-mib alias.

kevin

---

From: Kevin Lingle <[email-masked]>
Date: Wed, 08 Nov 2000 16:16:17 -0500

how about this configuring sip server address in a user agent?
this table would be defined in the SIP-UA-MIB module and allow 
the old sipUserLocationServerAddress object in the SIP-COMMON-MIB
to no longer be used (incorrectly) for this purpose... and
actually be removed.

note: a table and the use of applIndex are inherent in the
      way all of the sip mib modules are defined 
      (see http://search.ietf.org/internet-drafts/draft-ietf-sip-mib-01.txt)

   -- 
   -- SIP Server Configuration 
   --     
   sipUACfgSipServerTable OBJECT-TYPE 
       SYNTAX      SEQUENCE OF SipUACfgSipServerEntry 
       MAX-ACCESS not-accessible 
       STATUS     current 
       DESCRIPTION 
            "This table contains SIP server configuration objects 
             applicable to each SIP user agent in this system.  The 
             instances of SIP entities are uniquely identified 
             by applIndex." 
       ::= { sipUACfgSipServer 1 } 
    
   sipUACfgSipServerEntry OBJECT-TYPE 
       SYNTAX     SipUACfgSipServerEntry 
       MAX-ACCESS not-accessible 
       STATUS     current 
       DESCRIPTION 
            "A row of server configuration." 
       INDEX { applIndex, sipUACfgSipServerIndex } 
       ::= { sipUACfgSipServerTable 1 } 
    
   SipUACfgSipServerEntry ::= 
       SEQUENCE { 
                sipUACfgSipServerAddrIndex   Unsigned32,
                sipUACfgSipServerAddrType    InetAddressType,
                sipUACfgSipServerAddr        InetAddress,
                sipUACfgSipServerStatus      RowStatus
       } 
   
   sipUACfgSipServerAddrIndex OBJECT-TYPE 
       SYNTAX     Unsigned32
       MAX-ACCESS not-accessible 
       STATUS     current 
       DESCRIPTION 
            "A unique identifier of a server address when
             multiple addresses are configured by the SIP entity.
             If one address isn't reachable, then another can
             be tried."
       ::= { sipUACfgSipServerEntry 1 } 

   sipUACfgSipServerAddrType OBJECT-TYPE 
       SYNTAX     InetAddressType
       MAX-ACCESS read-create
       STATUS     current 
       DESCRIPTION 
            "This object specifies the type of address contained
             in the associated instance of sipUACfgSipServerAddr."
       DEFVAL { ipv4 }
       REFERENCE "INET-ADDRESS-MIB (RFC 2851)"
       ::= { sipUACfgSipServerEntry 2 } 
    
   sipUACfgSipServerAddr OBJECT-TYPE 
       SYNTAX     InetAddress
       MAX-ACCESS read-create
       STATUS     current 
       DESCRIPTION 
            "This object specifies the address of a SIP server
             this user agent will use to proxy/redirect calls."
       ::= { sipUACfgSipServerEntry 3 } 

   sipUACfgSipServerAddrStatus OBJECT-TYPE 
       SYNTAX     RowStatus
       MAX-ACCESS read-create
       STATUS     current 
       DESCRIPTION 
            "This object is used to control rows in this table.
            
             'active'        : the row's information is completely
                               populated and that information is 
                               being used by the user agent.

             'notInService'  : the row's address is not being used
                               by the user agent, but will remain in the table.

             'notReady'      : key information is missing thus, preventing
                               the row from being made 'active' (eg, no
                               address specified).

             'createAndGo'   : only allowed if the manager also provides
                               a varbind for sipUACfgSipServerAddr object
                               in the same set operation.

             'createAndWait' : not applicable.

             'destroy'       : the row's address will no longer be used
                               by the user agent and the row will be
                               removed from the table."
       ::= { sipUACfgSipServerEntry 4 }