Subject: [SIP] revised SIP MIB draft

From: Dave Walker <[email-masked]>
Date: Thu, 13 Jul 2000 18:28:14 -0400

Dear All,

We have completed another revision of the SIP MIB and sent it to the IETF.  

To bypass the backlog, you can access it at
http://www.ss8networks.com/files/internet-drafts/draft-ietf-sip-mib-01.txt

Regards,

Dave Walker
SS8 Networks
Ottawa, Canada

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

---

From: Kurt Robohm <[email-masked]>
Date: Mon, 17 Jul 2000 15:01:12 -0400

All,
I had reviewed a previous edition of the SIP MIB and logged a number of 
inquiries as indicated below.  A good deal of the objects I had questions 
or comments about now appear to not be present in the latest edition.  I 
searched through the email distro discussions and found no mention of 
having deleted these objects, so I'm a bit confused.  Anyway, if anyone 
would like to enlighten me a bit regarding my comments below, I'd 
appreciate it.

Kurt Robohm
Worldcom
Ashburn Virginia

Object NameInquiry
sipOrganizationWhere does the organization information originate from?
sipSummaryInRequestsHow about similar object for rejected request or 
responses?
sipStatsAckInsHow about similar object for a Nak?
sipStatsInfoTryingOutsIntent of object was to show number of transactions 
necessary to complete a call?
sipStatInfoRingingInsIntent of object was to show number of devices 
involved in the call route?
sipStatsClientBadRequestInsWill objects be indexed for every client?
sipStatsClientBadRequestInsIs there a client name object?
sipStatsClientBadRequestInsWill counter be incremented for packets that are 
bad/incomplete?
sipStatsClientBadRequestInsIs there a client IP address object?
sipStatsClientReqTimeoutInsWould lost packets be reason for timeout- or is 
this counted after a "trying" response is rx?
sipStatsClientLoopDetectedInsIs this equivalent to an echo on the line in 
older telephony parlance?
sipStatsServerGatewayTimeoutIns
sipCurrentTransacationsDoes this reflect number of calls in progress?
sipTransactionTableIntent of objects in table to provide real time info on 
number of calls being handled real time?
sipTransCallingPartyContentTypeIntent of object was to provide details on 
calls in progress?
SIP retry statisticsDo retries indicate any general network problems?
sipRxProxyAuthPasswordWhy is this object needed?  (seems like a security 
issue)

At 06:28 PM 7/13/00, Dave Walker wrote:
>------------------------------------------------------------------------
>To email plain text is conventional, to add graphics is divine.
>We'll show you how at www.supersig.com.
>http://click.egroups.com/1/6811/7/_/361123/_/963530241/
>------------------------------------------------------------------------
>
>To Post a message, send it to:   [email-masked]
>To Unsubscribe, send a blank message to: [email-masked]

---

From: Dave Walker <[email-masked]>
Date: Mon, 17 Jul 2000 17:31:56 -0400

Kurt,

Thank-you for your comments.  My answers are in-line.

Kurt Robohm wrote:
> 
> All,
> I had reviewed a previous edition of the SIP MIB and logged a 
> number of inquiries as indicated below.  A good deal of the 
> objects I had questions or comments about now appear to not be 
> present in the latest edition.  I searched through the email 
> distro discussions and found no mention of having deleted these 
> objects, so I'm a bit confused.  Anyway, if anyone would like 
> to enlighten me a bit regarding my comments below, I'd appreciate 
> it.
> 
> Kurt Robohm
> Worldcom
> Ashburn Virginia
> 
> Object Name                     Inquiry
> 
> sipOrganization                 Where does the organization
>                                 information originate from?

It's a SIP header.  Value may typically be configured into the 
application by an enduser (UA) or via network management.

> 
> sipSummaryInRequests            How about similar object for
>                                 rejected request or responses?

Please take a look at the status code counters, particularly see 
sipStatusCodesTable and sipCommonStatusCodeTable.

> 
> sipStatsAckIns                  How about similar object for a
>                                 Nak?

There's no Nak method in RFC 2543.

>                                 Intent of object was to show
> sipStatsInfoTryingOuts          number of transactions
>                                 Intent of object was to show
> sipStatInfoRingingIns           number of devices involved in
>                                 the call route?
> 
> sipStatsClientBadRequestIns     Will objects be indexed for
>                                 every client?
> sipStatsClientBadRequestIns     Is there a client name object?
>                                 Will counter be incremented for
> sipStatsClientBadRequestIns     packets that are
>                                 bad/incomplete?
> 
> sipStatsClientBadRequestIns     Is there a client IP address
>                                 object?
>                                 Would lost packets be reason
> sipStatsClientReqTimeoutIns     for timeout- or is this counted
>                                 after a "trying" response is
>                                 rx?
>                                 Is this equivalent to an echo
> sipStatsClientLoopDetectedIns   on the line in older telephony
>                                 parlance?

As was pointed out at the IETF in Adelaide, there were far too
many counters in the MIB.  All of the counters above were replaced
by the class counters (in sipStatusCodesTable), and a generic 
mechanism was provided for counting specific status codes (in
sipCommonStatusCodeTable).

> 
> sipCurrentTransacations         Does this reflect number of
>                                 calls in progress?
>                                 Intent of objects in table to
> sipTransactionTable             provide real time info on

Transactions aren't calls.  The intent, as mentioned in Adelaide,
is to evolve the transaction table to a call leg table (probably 
for UAs only).  This hasn't been resolved yet, so no real changes 
were made.

> 
> sipTransCallingPartyContentType Intent of object was to provide
>                                 details on calls in progress?
> 
> SIP retry statistics            Do retries indicate any general
>                                 network problems?

That's one likely cause.  The interpretation of the data isn't a 
matter for the MIB.

> 
> sipRxProxyAuthPassword          Why is this object needed?
>                                 (seems like a security issue)

In Adelaide, it was also identified that support for SIP security 
mechanisms needs attention.  It still does.  The new draft was
primarily concerned with a base restructuring of the MIBs.

Best Regards,

Dave Walker
SS8 Networks
Ottawa, Canada