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

From: [email-masked]
Date: Wed, 8 Nov 2000 15:19:57 -0600

Kevin,

I think there is a definite need for configuring multiple server addresses in a
SIP UAC. For example, our PSTN gateways can be configured for up to 8 SIP
proxies. Using REGISTERs, they determine which ones are alive, and then
distribute calls among the alive SIP proxies via one of a number of user
selectable algorithms.

I think this would be a very good addition to the SIP UA MIB.

Jim

Kevin Lingle <[email-masked]> on 11/08/2000 02:28:35 PM

Sent by:  Kevin Lingle <[email-masked]>

To:   "Henning G. Schulzrinne" <[email-masked]>
cc:   Jonathan Rosenberg <[email-masked]>, [email-masked],
      [email-masked] (James Renkel/MW/US/3Com)
Subject:  Re: [SIP] Some brief comments on the SIP MIB

"Henning G. Schulzrinne" wrote:
>
> Kevin Lingle wrote:
> >
>
> >
> > 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.
>
> 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.

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
>
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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

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

---

From: Jean-Francois Mule <[email-masked]>
Date: Wed, 8 Nov 2000 16:31:37 -0800

The comments here address mainly the application state variables: 2
variables in the current sip mib: sipServiceOperStatus and
sipServiceAdminStatus.

--- Usage status:
When the SIP entity is up, it would be nice to have a simple variable
showing its usage.  This way, as a sysadmin, I could query the app and if it
is up and idle, or up and busy.
Could we add a usage variable?   Something like:
   sipServiceUsageStatus OBJECT-TYPE
       SYNTAX     INTEGER

			idle(0),
			active(1),
			busy(2)
                  }
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
            "This object contains the current usage state of the
             SIP application.

             idle(0)         : The application is currently not in use.
             active(1)       : The application is in use, and has sufficient
spare operating capacity.
             busy(2)         : The application is in use but it has no spare
operating capacity."
       ::= { sipCommonCfgEntry x }

--- Regarding the number of state variables
The operational status variable contains numerous state information which
overlap.
For example, when the status is 'testing', the sysadmin does not know from
the MIB whether the service is up or down.  On large scale systems, we may
want to allow test procedures on some SIP functionality of the device while
calls are being served.  Unless we have a way to describe this properly, we
expose ourselves to implementation & operational issues.

The operability of the SIP service should be binary: enabled or disabled.
We could have another variable to reflect the procedural aspects (testing,
initializing, ...) or standby options.
Same applies to the AdminState:  I'd prefer keep a convention already
established where the admin state is either locked (sip application
administratively down), shutting down or unlocked.

Comments?
Without getting into too much detailed vars, I believe we could clarify the
admin/oper/usage states along with some procedural vars so that both vendors
and operators have a clear way of setting/querying the SIP apps behavior.

Cheers,
Jean-Francois Mule
Clarent Corp.

---

From: Jean-Francois Mule <[email-masked]>
Date: Wed, 8 Nov 2000 16:45:10 -0800

The current MIB allows to specify the authentication method that is used by
servers to authenticate request originators (sipProxyAuthMethod).   The
granularity is this config param means: a proxy will challenge all requests
or none.

There might be cases where a proxy requires authentication on some but not
all requests  (typically, authenticate REGISTER only then you are trusted
and can speak freely ;-), or authenticate REGISTER, INVITE, BYE -- for the
ACK, it is okay, etc.).

Shall we allow this level of granularity for the configuration of sip
proxies?

Jean-Francois Mule
Clarent Corp.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 08 Nov 2000 19:56:48 -0500

> Shall we allow this level of granularity for the configuration of sip

Unfortunately, it's more complicated than that. Our server allows
configuration for each local user, so that (for example)
[email-masked] requests, but does not require authentication for
non-REGISTER (but does for REGISTER), while calls to
[email-masked] requires authentication for all requests. I really
doubt you want to carry all of this in SNMP.

---

From: Kevin Lingle <[email-masked]>
Date: Thu, 09 Nov 2000 12:41:39 -0500

this issue does look like it can be relatively complex and open to
a variety of solutions with different levels of granularity.  for the
standard sip mibs we should try and avoid complexity.  vendors should
be able to decide whether they want to express their more elaborate
auth configuration mechanisms via vendor specific mib extensions.
we should not do anything in the standard mib that would prevent, 
impede or conflict with vendors being able to do that.

i believe the sipProxyAuthMethod object's purpose to specify the 
method used and not get into the particulars of when that method
is applied.

that said, it does look like the value 'none' and it's current description 
go beyond that intended purpose. the description says 'none' means no 
authentication will be performed.  perhaps that is a point of confusion.   
maybe 'none' should  be changed to 'unknown' and the description altered 
to not imply anything about authentication being performed?  comments?

additionally, we recently got a request to alter the syntax of this
object so that multiple auth methods could be in play at once.  that
would be done by making the object's syntax BITS rather than INTEGER.
you could turn on bits for any combination of 'basic', 'digest', or
'pgp'.  the value of 0 would likely imply 'none'.   
so while we're on the subject are there any comments regarding this
proposed change (ie, to specify multiple auth methods)?   
i am currently planning on making this change, so if there are strong 
arguments against i'd like to hear them now rather than later.

kevin