Hi,
This note provides our response to all the comments we received during
the expert review of the SIP MIB draft07. We'd like to thank all of
you for your valuable and detailed comments.
The SIP MIB draft08 was just released in the ID repository:
http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-08.txt
Kevin and I have been working on the draft for several months,
it is a long awaited update - it took us way too long to answer
the comments and update the draft.
There are 4 outstanding items we could not close in draft08:
see comments #1, #46, #79, #87.
Those comments need more discussions to be addressed properly and our
plan is to open separate threads to close them in draft09.
Kevin and Jean-Francois.
PS: please cc: me and Kevin if you have any comments on the sip mib
--- Legend:
AI = Action Item
AI: none (means no action taken => no changes due to the comment)
AI: done (means action were taken and resulted in I-D changes)
AI: open (means left for draft09)
Lines starting with # delimit our response.
--- A - Comments from Cullen Jennings
1) There is not enough in the MIB to configure
any UA or Proxy I have seen.
I don't think this is a problem but I think we should make the
configuration aspect of the MIB optional but the diagnostic and
reporting aspect mandatory. If we decide that configuration is part of
what we are doing here, we need a bunch more stuff. I think we should
make this targeted at status and debug instead of configuration - this
would significantly simplify the MIB.
# The authors exchanged several emails with Cullen and Rohan.
# In general, our response to this comment were along the lines of:
# a) It is very hard to cover all configuration in a general way.
# Vendors will need to add enterprise specific mibs to cover their
# additional config requirements (presuming the even do config via
# snmp).
#
# b) this MIB is intended to be a protocol MIB for SIP; configuration
# of sip entities, sip applications and sip services can be complex
# and it goes beyond the pure SIP protocol mgmt configuration. We have
# tried to keep the mib basic and simple, yet useful enough to be
# implemented. As we gain implementation experience, we will augment
# the protocol MIB as needed or define different sip-related standard
# mibs.
# c) wrt, optional config... we can manage this by how we organize
# object-groups and there status in the module-compliance.
# sipCommonConfigGroup is now MANDATORY. it has a large set of
# objects... some of which could be optional if moved to new or
# different OPTIONAL object-groups. same may hold true for other
# "config group" object-groups in the server and ua mib modules.
# we tend to agree that configuration (as in provisionable
# parameters) should be made optional as that seems to be the trend
# for snmp (ie, a move to being a performance monitoring and fault
# detection mechanism rather than a provisioning tool).
# There are still some things under "config" for these mibs that will
# still make sense to require at least read-only support for as they
# are useful information as to how a system is working or is
# configured.
Cullen added:
> we need to consider whether we want this mib to be able to
> generally configure a complete simple proxy. if so, then
> we are way short.
AI: re-work the compliance groups
open, left for draft09
# We plan on reworking all of the read-write/create objects into more
# object-groups and make them optional to reflect what people will
# likely implement per Cullen's comment.
2) There are mechanisms to deal with new methods
Why no just use these for all the methods including known ones. It
would simplify the MIB and implementations to be able to deal with
things in a uniform generic way instead of having separate code for
OPTION and INVITE.
AI: done
# We added some text in the IANA consideration section to state our
# need to have sip methods registered and assigned method IDs. This was
# recommended by Cullen and Rohan; and per the rfc review process, the
# IANA registry will be enhanced with method ids.
# We re-arranged all the method specific objects & tables to use a new
# method ID textual-convention and removed all the extension method
# tables as new methods registered with IANA will be managed the same
# way.
# sipExtMethodSupportedTable is gone.
# we generalized sipMethodSupportedTable
------------------------------------------------------
3) Why not just report stats for responses
based on an array of 100 to 699.
This again would allow very generic treatment. For some things, like
4xx, responses aggregating all the 4xx into one count does not provide
good information because things like 401 are very normal while other
4xx correspond to problems.
AI: done
# the sipStatusCodeClassesTable was removed after discussions with
# Cullen & Rohan. The rational is that going through some use cases or
# examples of how the code classes could be useful, we could not find
# justification for its use.
# An example we took was knowing stats about the 4xx messages but with
# the use of 407 (which does not translate into a pb), the use of the
# 4xx code class stats did not make sense.
------------------------------------------------------
4) In all the counts, I don't think we should include retransmissions
and we should have a few counters to do with the UDP transport that
take care of retransmission stats.s
AI: done
# we reflected some changes in various retransmission counters, see
# subsequent comments from Cullen for more details.
------------------------------------------------------
5) Many proxies can control more than one domain at the same time.
Need to support this.
AI: none
# Kevin and Cullen exchanged some emails on this topic:
# klingle: how might this manifiest itself in the mib? additional
# indexing of the tables for domain? what info about each domain
# might need to be cast into objects (ie, contents for a "domain
# table"). What about non-server entities?
#
# after more discussions, Cullen stated:
# "we won't try to solve this one at this point."
------------------------------------------------------
6) The UA stuff confuses, registrars, outbound proxies and such -
actually these have been confusing in various version of SIP documents
so not surprising - need to clean up a bit.
AI: done
# for the configuration of SIP UA's servers in sipUACfgSipServerTable,
# we added a new object to indicate the role or function of the
# server.
# see below:
SipUACfgSipServerEntry ::=
SEQUENCE {
sipUACfgSipServerIndex Unsigned32,
sipUACfgSipServerAddrType InetAddressType,
sipUACfgSipServerAddr InetAddress,
sipUACfgSipServerFunction SipEntityRole,
sipUACfgSipServerStatus RowStatus
..
sipUACfgSipServerFunction OBJECT-TYPE
SYNTAX SipEntityRole
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies the function of the SIP server
this user agent should communicate with: registrar, proxy
(outbound proxy), etc."
::= { sipUACfgSipServerEntry 4 }
SipEntityRole ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This convention defines the role of a SIP entity.
Examples of SIP entities are proxies, user agents,
redirect servers, registrars or combinations of
the above."
SYNTAX BITS {
other(0),
userAgent(1),
proxyServer(2),
redirectServer(3),
registrarServer(4)
}
7) Need to work through what things need notification attached to them
and what the filters should look like. For example, I might want to
find out if my invites per second goes above or below a certain value
and how often I will get notified while it out it's normal range.
AI: none
# Kevin stated that:
# "we had some other "last minute" internal cisco comments on possible
# notifications. We added several in last revision, but felt that we
# should not attempt to add lots of new things this late in the game.
# we were considering that new things could be defined by way of
# additional mib modules. there may also be other mibs that provide
# some generic mechanisms for monitoring statistical object's behavior
# (example RMON mib).
# Cullen conceeded that we shouldn't try to add lots in this area to
# the mib at this point.
8) Most proxies have some sort of dial plan table. Should we support
reading this table as a table of strings but not specify the format
for the strings?
AI: none
# We would recommend that we do dial plan mib extensions elsewhere as
# this may serve in multiple other areas in IETF. A DIAL-PLAN-MIB
# could be defined in the future.
# The dial plan mgmt is outside scope of SIP mib.
# Cullen agreed.
------------------------------------------------------
9) Could have flags indicating if enum was done.
AI: none.
# After further discussions with Cullen, we all agreed that we should
# keep the MIB simple and that we could had additional hooks later.
------------------------------------------------------
10) The term session is used a little inconsistently with 3261 -
suggest that most places session occurs we replace with dialog.
AI: done
# Agreed. Changes made in SIP-COMMON-MIB.
# We also found the term session in the overview paragraph but this
# usage matches the exact text in RFC3261 (no change required).
------------------------------------------------------
11) Proxy/Redirect server
I don't see any value in separating these. I would just make Redirect
a special case of Proxy and not split it apart in the MIB at all.
AI: done but kept the option to either combine or separate entities
# It does still make sense to keep redirect server separate from
# proxy. rfc3261 maintains a clear distinction and separation between
# the functions of a proxy and redirect server (sections 8.3, def. of
# location services, etc.). Also there are some SIP-based services
# purely based on SIP redirect servers (e.g. 800/LNP number
# translation based on SIP 3xx redirect).
#
# That said, even if most implementations combine the proxy & redirect
# functions, from a mgmt standpoint, we have allowed this proxy_server
# combination to be managed as one entity (point of your comment) or
# as 2 separate entities (see section 5.2. of draft# 07).
# added "sip_proxy_redirect" as an example in draft 08 front paper.
# Changed the type of sipEntityType and introduced a BITS syntax
# textual-convention in sipEntityRole (see response to comment#6).
------------------------------------------------------
12) I'm not sure that I really see Proxy and Registrar being very
different other than a Proxy that does not do Registration may have 0
values for a bunch of things.
AI: none
# See response to comment #11
#
# Same justification as for redirect server. The RFC identifies those
# as logical entities that can be separated and the managed objects
# do allow both options: proxy registrar combined into 1 entity or
# separate. The mib def offers the flexibility to manage them as one
# entity or separately. no action required.
------------------------------------------------------
13) Can you find the number of bad message a proxy has received.
AI: done
# Cullen further detailed his request:
# "Messages that were silently discarded without sending a response."
#
# We added sipOtherwiseDiscardedMsgs to sipOtherStatsTable.
sipOtherwiseDiscardedMsgs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of SIP messages received that for any number
of reasons was discarded without a response."
::= { sipOtherStatsEntry 2 }
------------------------------------------------------
14)Number of TCP or TLS session failures.
AI: none
# While sip is dependent on tcp/tls sesssions, we do not believe we
# should be incorporating transport layer managed objects in a sip
# protocol mib.
------------------------------------------------------
15) Getting information about the active dialogs on a UA.
AI: none
# We asked what kind of information?
# Cullen responded that other people convinced him that this
# information is just too dynamic to track in SNMP.
------------------------------------------------------
16) Getting information about the previous call on a UA.
AI: none
# Cullen did withdraw his comment
------------------------------------------------------
17) Setting log levels.
AI: none
# Logging is out of the scope of this mib. The disman or other ietf wg
# have a bunch of other tools or mibs to do this depending on what the
# needs are.
# Cullen: OK.
------------------------------------------------------
18) Section 5 - sipCommonStatsOther - lat word of para -
replace URIs with methods
AI: done but kept URIs
# no, URIs is right because the only object in that group currently is
# sipNumUnsupportedUris. Cullen ok.
# in our discussions, we also decided to add object to count unsupp. methods
SipOtherStatsEntry ::=
SEQUENCE {
sipNumUnsupportedUris Counter32,
sipNumUnsupportedMethods Counter32,
sipOtherwiseDiscardedMsgs Counter32
}
sipNumUnsupportedMethods OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of SIP requests received with unsupported methods.
A server normally responds to such requests with a
501 (Not Implemented) or 405 (Method Not Allowed)."
::= { sipOtherStatsEntry 2 }
------------------------------------------------------
19) Section 5 - SipProxyCfg
Canceling branches is not optional and there is no need to control it
from the MIB
AI: done
# ok, removed the sipProxySendsCancel object
sipProxySendsCancel OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies whether or not a forking proxy sends
CANCEL on outstanding branch requests after receiving a
2xx or 6xx, or after the request times-out.
If the value of this object is 'true', the server sends
a CANCELs on branches where no definitive response has been
received. If 'false', the proxy does not send CANCELs."
REFERENCE
"RFC 3261, Section 9, 16.10 and 16.11"
::= { sipProxyCfgEntry 3 }
------------------------------------------------------
20) If we go down this strange path of sip_proxy_redirect names
I think we need to provide a ordering of them so that everyone says
sip_proxy_redirect and no one says sip_redirect_proxy.
AI: done
# Cullen added:
# I just meant form a canonical way to form the names so everyone asks
# for the same thing and provides the same thing instead of parsing
# and sorting out complext ones
#
# We added some works recommending a canonical way to form
------------------------------------------------------
21) All the examples that have domain names like ss8.com or cisco.com
need to be changed to example.com.
AI: done
------------------------------------------------------
22) P19 - sipOrganization - should this be in UA only mib
AI: none
# We asked Cullen whether this was not general in nature?
# Cullen responded: "I think it is fine to leave it in where it is."
------------------------------------------------------
23) P19 - maxSipSession - do you mean dialogs or transaction
AI: done
# changed sipMaxSession to sipMaxTransactions per RFC3261
------------------------------------------------------
24) P19 - sipRequestUriHostMatching
A proxy that did not do this would be in violation of the RFC. Don't
think we need this.
AI: done
# protocol violation, removed sipRequestUriHostMatching object.
------------------------------------------------------
25) P21-22 - sipTransportRcv and Snd.
I think it is bogus to specify if you can receive or send on a given
port. In things other than UDP this has no hope of working. In UDP it
is of very little use given where we are going with rport.
Cullen added:
It's a somewhat useful bit of configration to know what ports a proxy is
running on - I think it is worth keeping but don't feel too strongly about
it.
AI: done
# Made objects read-only, removed object on send port, only kept
# listen_on ports
# We kept sipTransportRcv as it may be useful to know what port the
# SIP server entity is listening on. However, sipTransportSnd does not
# make a lot of sense if it is bound to a particular port. So I
# deleted sipTransportSnd and changed the objects as read-only
# objects, see below.
sipTransportRcv OBJECT-TYPE
SYNTAX SipTransportProtocol
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object will specify the transport protocol the SIP
entity will use to receive SIP messages.
This object is a bit map. Each bit represents a transport
protocol. If a bit has value 1, then that transport protocol
is currently being used. If a bit has value 0, then that
transport protocol is currently not being used."
::= { sipPortEntry 2 }
------------------------------------------------------
26) P22 sipPortStatus -
making a special exception for 5060 is not right. If more than one SIP
thing is running on the same host, one of them will not be on 5060.
AI: done
# removed specific handling of port 5060
------------------------------------------------------
27) P23 sipUriSupportedy stuff -
you have to do sip - why not just make a flag that indicates if tel is
supported or not.
AI: done
# object/table removed
# we do not see how useful this object can be in the MIB anymore, most
# service providers will know what URI schemes they need for their
# services and this will not change over time. Also, most SIP
# implementations would require application support for new URIs (i.e.
# this is not a simple addition in the mib or a .h header file)...
------------------------------------------------------
28) P27 - SipCommonCfgTimerEntry
Is being able to change all the timers really a good idea - I don't
have an opinion this - I'm just raising the question.
# Asked for more input from SIP wg.
# As of June 04, we haven't gotten additional feedback.
# Mary also mentioned it, but wasn't overtly opposed to it... just
# uncertain of it.
# Decision is a compromise:
# leave it as read-write in the MIB definition but only mandate that
# compliant implementations of the SIP MIB may only support
# read-only. This leaves the choice to implementers.
------------------------------------------------------
29) P 32 - I think per method timers are a bad idea.
AI: done
# agreed (we had left it from rfc2543 but after having more practice
# with rfc3261 timers), we agree.
# Deleted per method timers.
------------------------------------------------------
30) P 34 - I think per method retry counts are a bad idea.
AI: done
# Removed per method retry counts since the retransmission mechanism
# in rfc3261 is all based on timers.
------------------------------------------------------
31) P 37 - per method Expires seem like a dubious idea
the app should know how
AI: done
# ok, removed sipCommonCfgExpiresMethodTable and related objects.
# based on comments #32 - #35, also removed:
# sipCommonCfgExpiresStatusCodeTable
------------------------------------------------------
32) P38 - sipCfgExpiresInvite
proxy should not change this - seems like UA only at best
AI: done
# ok, removed, see #31 for more details.
------------------------------------------------------
33) P38 sipCfgExpiresRegister
this is something that the registrar does need to configure (and
perhaps the UA) but not the proxy. The text that the header value wins
on a registrar is wrong.
AI: done
# ok, removed, see #31 for more details.
------------------------------------------------------
34) P 38 - sipCfgExpiresHeaderMethod
this is a strong indication we went down the wrong path somewhere - I
don't like this, not on a train, not ...
AI: done
# ok, removed, see #31 for more details.
------------------------------------------------------
35) P 39 - sipCommonCfgExpiresStatusCodeEntry
no no no this is not right - this cat should not be in the MIB.
AI: done
# ok, removed, see #31 for more details.
------------------------------------------------------
36) P 42 - sipSummaryTotalTransactions counting forked request as one
transaction is wrong
AI: done
# agree, this is a mistake; fixed.
# Replaced:
< In the case of a forked request, all branches count as a
< single transaction.
# by:
> In the case of a forked request, each branch counts as a
> single transaction.
------------------------------------------------------
37) P 43 - SipMethodStatsEntry - don't think these should include
retransmissions
AI: done
# Changed all the descriptions to state that those objects must not
# count restransmissions.
# we are ok with not including retransmissions as we think these stat
# counters have values without them.
# E.g.
sipStatsOutbounds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object reflects the total number of requests
sent by the SIP entity, excluding retransmissions.
Retransmissions are counted separately and are not
reflected in this counter."
REFERENCE
"RFC 3261, Section 7.1"
::= { sipMethodStatsEntry 2 }
------------------------------------------------------
38) P 58 - sipCurrentTransaction
the forked requests are not the same transaction
AI: done
# ok, fixed description and replaced it with:
sipCurrentTransactions OBJECT-TYPE
SYNTAX Gauge32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the number of transactions awaiting
definitive (non-1xx) response. In the case of a forked
request, each branch counts as a single transaction
corresponding to the entity identified by applIndex."
::= { sipCurrentTransEntry 1 }
------------------------------------------------------
39) P 76 - sipUACfgSipServerAddress
is this the AOR? Where to send the registration? The outbound proxy?
The auth domain for digest? I think this needs to be broken into a
bunch of things. What about UA that can register to multiple proxies.
What does the contact get set to.
AI: done
# the comment refers to the sipUACfgSipServerAddr entry in the
# sipUACfgSipServerTable. Note that this is a table so if a UA has
# multiple servers it needs to communicate with
# (registrar/proxy/etc.), we have the means to configure multiple of
# them.
Cullen wrote:
> Where to send the
> registration? The outbound proxy? The auth domain for digest?
# Knowing the type or function of a sip server is definitely a plus
# and missing in this table. I would suggest we add a server
# application function object (similar to the notion of applName for
# sip entities) to give a hint to the UA as to what to do with it.
# The use of server type is kind of prohibited by the existence of
# server address types (v4, v6, fqdn, etc.)
# Action taken:
# 1. defined a new textual convention:
SipEntityRole ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This convention defines the role of a SIP entity.
Examples of SIP entities are proxies, user agents,
redirect servers, registrars or combinations of
the above."
SYNTAX BITS {
other(0),
userAgent(1),
proxyServer(2),
redirectServer(3),
registrarServer(4)
}
# 2. added columnar object for SIP UA server address cfg.
sipUACfgSipServerFunction OBJECT-TYPE
SYNTAX SipEntityRole
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies the function of the SIP server
this user agent should communicate with: registrar, proxy
(outbound proxy), etc."
::= { sipUACfgSipServerEntry 4 }
Cullen wrote:
> What about UA that can register to multiple proxies.
# you can do that.
> What does the contact get set to.
# this is starting to get into application specific configuration
# (i.e. beyond the pure SIP protocol stack config). I would differ
# this to future extensions of the SIP mib given the type of
# associations between contacts & servers (for e.g. register all
# contacts with all servers, only a subset with a specific server,
# etc.).
------------------------------------------------------
40) P 83 - sipRequestMeaxExpires
in what context? Would need to split this up not sure I see any value
in it
AI: done
# ok, removed object.
------------------------------------------------------
41) P 83 - sipProxyStatefulness
give the RFC forces proxies to switch mode - I am really lost at what
this would report or how it be of much value. The concept of it being
read-write is particularly hard for me to imagine.
AI: done
# made this object read-only and leave it as-is.
------------------------------------------------------
42) P 84 - sipProxySendsCancels, sipPRoxyForwardAll1xx
these just seem plain wrong
AI: done
# agree, removed sipProxySendsCancels and sipPRoxyForwardAll1xx
------------------------------------------------------
43) P 84 - sipProxyRecurions - I like this one :-)
AI: none
# good, no AI!
------------------------------------------------------
44) P 85 - sipRpxyProvieAlternatives - sounds like a bad idea
AI: done
# agree that doing this on a per server basis without invoking any
# other per user/destination rules is not practical.
# object removed.
------------------------------------------------------
45) P 85 - sipProxyRecrodRoute -
I'm very dubious on this one - a proxy would need to do this because
it was doing something that required it. In this case it' can't run it
off and otherwise it probably should be off.
AI: none
# some proxies want to be on the path (for accounting or boundary
# proxies for e.g.). Agree that it is most likely either on or off
# but it does not harm to have this toggle there. no action taken.
------------------------------------------------------
46) P 86 - sipProxyAuthMethod
bit 1 should probably say mutual TLS, S/MIME is not yet defined for
end to middle auth. I really doubt these bits are enough to control
how say mutual TLS would work
AI: open
# the definition is consistent with what's in the RFC 3261. We would
# like to leave it as-is for now and see based on implementation
# experience.
# We could define more granular controls on TLS authentication (like
# mutual TLS): do you only need mutualTLS as an additional option?
------------------------------------------------------
47) SipProxyNonceLifeTime
a max of 65 seconds is too short - do we really need this in the mib?
AI: done
# agree, object SipProxyNonceLifeTime deleted in the mib.
------------------------------------------------------
48) P 87 sipNumProxyRequiresFailures - I like this one
AI: none
------------------------------------------------------
49) P 88 sipRegAllowThirdParty - not sure I see the need for this
AI: none
# Registrars should authenticate the uac so I'm not a big fan of this
# object either. That said, I can think of a couple of uses for this
# object: the registrar may not even want to launch an authentication
# if the from/to headers in the register request are not equivalent
# (strict policy), may be because it nows the authorized ua clients on
# its network just do that...
# We see no harm in leaving this object but it may not be that useful.
# Can you find a reason why you do not want it in the mib at all
# (spec inconsistency, examples where this is flawed)?
------------------------------------------------------
50) P 89 sipRegmaxContactExpireyDuration - should not have a DEFVAL
AI: done
# removed DEFVAL
------------------------------------------------------
Note that we jump here from comment #50 to #60. This is a mistake, #60
is really 51. We made a typo and when we integrated our notes, we did
not want to renumber as we do have some cross-references.
Just a note to say: "no, we did not miss 10 comments...
60) P 90 sipRegUserTable - I don't know enough about SNMP here
AI: done
# we made this table optional in the compliance statement
Cullen wrote:
> If this table had a few million entries in it would that be ok?
# We recognize large tables as a general problem in snmp.
# This is a known potential problem for SNMP if you have millions
# of entries. It is a recognized pb for large tables.
Cullen wrote:
> Could you systematically access a chunk of it say the 10,000 to
> 20,000 entry. Going through the entries one at a time will be too
> slow. Going through the entries all in one gulp might hang things
> temporarily.
# we would like to gain implementation experience to see whether folks
# really use SNMP for large registration services where a SQL db may
# be in use and where other types of mgmt commands & protocols are
# more suited.
------------------------------------------------------
61) P 91 sipUserAtuhtneitcationFailures
AI: none
Cullen wrote:
> does this reset after a successful authentication?
# No, it is a counter32 so it does not reset. Is that ok? if not, we
# could change the syntax to a Gauge and count consecutive failures
# and then go to zero.
Cullen wrote:
> Would like to be able to do notification on a threshold on it?
# Per our response to comment #7, Cullen agreed not to add more
# notifications.
------------------------------------------------------
62) P94 - sipContactRetryAfter
I did not know you could do this - in fact, I don't think you can. Any
comments from others?
AI: done
# Great comment, thank you. You could do it in rfc2543 but not
# anymore... details below.
# After re-reading the def of Retry-After in the old RFC2543, there
# was an option back then to use the Retry-After header in a REGISTER
# request:
#
# from rfc2543:
# Retry-After R c e - - - - - o
# ^^^^^^^
# this was it
# Retry-After 404,480,486 c e o o o o o o
# from rfc2543 section 6.32:
# A REGISTER request MAY include this header field when deleting
# registrations with "Contact: * ;expires: 0". The Retry-After value
# then indicates when the user might again be reachable. The registrar
# MAY then include this information in responses to future calls.
# In rfc3261, this option is gone and only the retry-after header use
# in responses is specified and allowed:
# Retry-After 404,413,480,486 - o o o o o
# The obsolete object sipContactRetryAfter was deleted in draft08.
-------------
I'm sure some of my comments are just wrong or misunderstandings. It's
hard to read a MIB and easily get the big picture - perhaps as I think
about it more I will be able to provide better comments. Once again,
thanks to the authors - it looks like a lot for work.
Cullen
# Thank you Cullen for all the great comments.
--- B - Comments from Mary Barnes
Hi all,
Per my assignment, I've reviewed sections 7.2 and 8 through 10 of the MIB,
with the following general comments and nits. I have a few specific points
that require discussion that I'll post in separate emails to facilitate WG
discussion and hopefully to allow easier tracking of issues. I did try to
conscientiously review previous comments on the mailing list and to review
previous versions to make sure that I wasn't bringing up things for which
there had been consensus. I do apologize if I inadvertently open an issue
that was truly closed by the WG.
------------------------------------------------------
63) - Section 7.2, page 14.
The descriptions need to be updated to reflect RFC 3261 (section 6)
terminology/definitions for User Agent, Proxy Server, Redirect Server
and Registrar.
AI: done
------------------------------------------------------
64) - Section 7.2, page 15.
Really minor nit, but I found it very difficult to read the common MIB
objects with no blank lines between the comment lines and the object
definitions.
AI: done
------------------------------------------------------
65) - Section 7.2, page 20. sipEntityType. Per Cullen's comments not
separating the Proxy and Redirect Server, this would need to be reflected in
this object definition.
AI: done
# See response to Cullen's comment. The sipEntityType object is now a
# BITS syntax object which allows system admins to choose whether to
# separate or combine proxy/redirect/registrar servers. This should
# address the comment.
------------------------------------------------------
66) - Section 8: My understanding is that this section should be removed by the
RFC Editor. Thus, I would suggest adding a comment as such (something like:
"This section to be removed by RFC Editor before publication." and moving
this section just prior to the Author's address to facilitate that process.
AI: done
# DONE: added the line. didn't move the section. xlm2rfc formatting
# tool used is problematics for placing where you suggested.
------------------------------------------------------
67) - Section 9, page 109. The statement "If these objects are SET maliciously,
it may result in
incorrect or unwanted protocol operation." is probably a bit of an
understatement with regards to the timer, retry and expire values being
misconfigured. Certainly, a well designed system would but reasonable
boundaries on how these things can be configured, so as to hopefully prevent
significant problems. Cullen had brought up the more general issue of
whether all the timers should be configurable in his comments. Like Cullen,
I haven't thought about this enough to decide whether all these timers
should be configurable, but at a minimum, I think the security section
needs a more robust statement.
AI: done
# Good points and agree generally with your comment. Below is the
# proposal to enhance the text:
replace
< If these objects are SET maliciously, it may result in
< incorrect or unwanted protocol operation.
with
> If these objects are SET maliciously, it may result in
> serious protocol misbehavior or misoperation. In particular, the
> objects are related to the core SIP protocol stack timers, retries
> and request expiration values: all of these control how the SIP
> state machines are executed at runtime. It is therefore possible
> that the SIP service be affected, stalled or completely stopped if
> erroneous values are SET maliciously.
# If the above text is not sufficient, can you suggest some text?
------------------------------------------------------
68) There has been past discussion on possibly renaming this object, but I did
not see a clear conclusion. At one point, I had seen a statement that it
would be renamed "sipMaxCalls", but call isn't a precise SIP term. Cullen
also raised the question in his comments as to whether this should be
"Dialogs" or "Transactions". My view would be that "sipMaxTransactions"
would be a good choice.
AI: done
# Yes, we agreed to change it and in draft07, we used
sipMaxSessions OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum number of simultaneous
sessions that the SIP entity can manage."
::= { sipCommonCfgEntry 7 }
# After further discussion between the 2 mib co-authors, we believe
# that it should be sipMaxTransactions because if is more meaningful
# than max dialogs (it's hard to predict how many transactions a
# dialog will be made up of).
# We added some more defs around this object:
sipMaxTransactions OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum number of simultaneous
transactions that the SIP entity can manage. In general
the value of this object SHOULD reflect a level of
transaction processing that is considered high enough
to impact the systems CPU and/or memory resources to
the point of deteriorating SIP call processing but not
high enough to cause catastrophic system failure."
::= { sipCommonCfgEntry 7 }
------------------------------------------------------
69) There has been previous discussion on the purpose and intent of this table
(defined on page 24 of the -07 version of the draft). Tom Taylor in his
comments on the -03 was questioning whether this should not also handle the
Allow (for methods) and Accept (for media types). This was also Dan's A5
comment from his posting on the -05 version:
"A5 - sipFtrSupportedtable - I am questioning if these table design is
correct. Are the features similar (identically supported) for a multiple
entity (like a proxy and a registrar) which would generate just one row in
this table"
Right now, it's confusing because the current description only talks about
the Require and Proxy-Require headers, however, section 19.2 which is the
reference given to RFC 3261 also includes the Supported (and Unsupported)
header. Also, it should be noted that section 19.2 discusses the change in
SIP requiring IANA registration of all the option tags. Thus, my suggestion
would be to change the description to be consistent with 19.2, also
including the Supported option tags. And, per Dan's Comment, these headers
do not apply equally to each of the entities, so one does question whether
the format of this table is suitable.
AI: done
# To resolve the numerous confusions, we followed your recommendation
# to be consistent with section 19.2 of rfc3261.
# Here is what we have proposed in draft08.
# renamed feature to option per section 19.2
# added a new Textual convention for header fields using option tags
SipOptionTagHeaders ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This convention defines the header fields that use
the option tags per section 19.2 of RFC 3261.
These tags are used in Require (Section 20.32),
Proxy-Require (Section 20.29), Supported
(Section 20.37) and Unsupported (Section 20.40)
header fields."
SYNTAX BITS {
require(0), -- Require header
proxyRequire(1), -- Proxy-Require header
supported(2), -- Supported header
unsupported(3) -- Unsupported header
}
-- REFERENCE "RFC 3261, Section 19.2"
# reworked the entire section and added a columnar object in the
# option supported table to specify:
--
-- Support for SIP option tags (SIP extensions).
-- SIP extensions MAY be supported or required by SIP entities.
--
sipOptionTagTable OBJECT-TYPE
SYNTAX SEQUENCE OF SipOptionTagEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains a list of the SIP option tags
(SIP extensions) that either required, supported, or
unsupported by the SIP entity.
These option tags are used in the Require, Proxy-Require,
Supported and Unsupported header fields.
Example: if a user agent client supports and requires the
server to support reliability of provisional
responses, this table contains a row with the
string '100rel' in sipOptionTag and the value
0xA0 in sipOptionTagHeaderField.
If a server does not support the required feature
(indicated in a Require header to a UAS, or in a Proxy-
Require to a Proxy Server), the server returns a 420 Bad
Extension listing the feature in an Unsupported header.
Normally the list of such features supported by an entity
is static (i.e. will not change over time)."
REFERENCE
"RFC 3261, Sections 19.2, 20.32, 20.29, 20.37, and 20.40"
::= { sipCommonCfgBase 3 }
sipOptionTagEntry OBJECT-TYPE
SYNTAX SipOptionTagEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A particular SIP option tag (extension) supported or
unsupported by the SIP entity, and which may be supported
or required by a peer.
Each row represents those objects for a particular SIP
entity present in this system. applIndex is used to
uniquely identify these instances of SIP entities and
correlate them through the common framework of the
NETWORK-SERVICES-MIB (RFC 2788).
The objects in this table entry SHOULD be non-volatile
and their value SHOULD be kept at reboot."
INDEX { applIndex, sipOptionTagIndex } sipOptionTagHeaderField
::= { sipOptionTagTable 1 }
SipOptionTagEntry ::=
SEQUENCE {
sipOptionTagIndex Unsigned32,
sipOptionTag SnmpAdminString,
sipOptionTagHeaderField SipOptionTagHeaders
}
sipOptionTagIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object uniquely identifies a conceptual row in the
table."
::= { sipOptionTagEntry 1 }
sipOptionTag OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the SIP option tag."
::= { sipOptionTagEntry 2 }
sipOptionTagHeaderField OBJECT-TYPE
SYNTAX SipOptionTagHeaders
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates whether the SIP option tag is
supported (Supported header), unsupported (Unsupported
header), required (Require or Proxy-Require header) by
the SIP entity.
A SIP option tag may be both supported and required."
::= { sipOptionTagEntry 3 }
- end of response to comment #69
Regards,
Mary H. Barnes
mbarnes at nortelnetworks.com
</mary barnes>
--- C - Comments from AC Mahendran
Comments on the different sections
------------------------------------------------------
70) Section 3, Page 3 - On the last line, STD 58 repeated many times.
AI: done
# reworded to only mentione STD 58 once.
" This memo specifies a MIB module that is compliant to the SMIv2,
which is described in STD 58, comprised of RFC 2578, RFC 2579,
and RFC 2580. "
------------------------------------------------------
71) Section 5, Page 3 - In sipCommonStatsMethod, Does this include
retries as well? If yes, it would be better to mention that.
AI: done
# reworded to include retransmissions.
" sipCommonStatsMethod:
This object group defines a table containing the per method
statistics objects applicable to all SIP entities, including
the total number of SIP requests for the Invite, Ack, Bye,
Cancel, Options and Register methods. Retransmissions, where
appropriate, are also included in these statistics. "
------------------------------------------------------
72) Section 5, Page 4 - In sipCommonStatsMethod, Remove the "/" in
front of Register on the last line.
AI: done
------------------------------------------------------
73) Section 5, Page 4 - In sipCommonNotifObjects, letter "d" is
missing from the word "related".
AI: done
------------------------------------------------------
74) Section 5.2, Page 8 - First table, first column(s), the
app1Index should be 1 instead of 2..
AI: none
# No, I believe the table is correct. The example being depicted is a
# system with two sip entities (a proxy and a registrar). Both have
# unique applIndex values (1 and 2 respectively) - see the applTable
# just prior on page 7. The first table on page 8 is from the
# SIP-COMMON-MIB, so each table will have an entry from both the proxy
# and the registrar as both support the common mib. Thus, the
# applIndex values in that table are 1 and 2.
------------------------------------------------------
75) Page 17, sipEntityType can be a bit map instead of an
enumeration (INTEGER). In that, way combinations can be
specified much easier.
AI: done
# Good point. Added a new TC sipEntity role with BITS syntax and used
# it for sipEntityType.
------------------------------------------------------
76) Page 20, sipFtrSupported table - How do you differentiate
between mandatory features (or extensions) and optional ones.
Also, should the proxy or UA include the values in this table
in Required/Supported headers?
AI: none, duplicate comment with #69
# see response to comment 69 and changes in draft08 in
# sipOptionTagTable
------------------------------------------------------
77) Page 29, sipCfgRetryInvite - If the SIP is run over UDP, the
timers govern how often the SIP INVITES (or other methods)
are retried. If you are talking about transactions it needs
to be specified clearly.
AI: done
# In rfc2543, both timers and retry counters governed how the
# retransmission should be handled. In rfc3261, it is now based on
# timers for the methods. This is a left-over from our previous
# drafts, these objects were deleted.
# - we deleted sipCommonCfgRetry, sipCommonCfgRetryTable (& its
# entries), sipCommonCfgRetryExtMethodTable (& its entries).
# - we left the stats as it may still be useful to know how many
# retries were sent based on the timers.
------------------------------------------------------
78) Page 63, sipUACfgSIPServerEntry - why is this a part of
SIP-UA-MIB. Shouldn't this be a part of the SIP-COMMON-MIB?
(Especially, since the SIP-SERVER-MIB has similar
information[see sipServerCfgEntry])
AI: none
# Now that we have added sipUACfgSipServerFunction, it
# justifies the relevance of this table for SIP UAs.
# SipUACfgSipServerEntry ::=
# SEQUENCE {
# sipUACfgSipServerIndex Unsigned32,
# sipUACfgSipServerAddrType InetAddressType,
# sipUACfgSipServerAddr InetAddress,
# sipUACfgSipServerFunction SipServerFunction,
# sipUACfgSipServerStatus RowStatus
# }
# The sipServerCfgTable has a different meaning (it contains the type
# of Internet address by which the SIP server is reachable and it is
# indexed by applIndex which gives you the server type). Also, it may
# be a good structure to have in the server mib for future
# extensions.
------------------------------------------------------
79) Page 63, sipUACfgSIPServerEntry - Do we need to specify any
security parameters in this table (for eg: realms allowed,
authentication methods supported etc)
AI: open on security params.
# We have sipProxyAuthMethod, sipProxyAuthRealm in the proxy
# config table (later in the SERVER mib).
# Can you provide more details, specific additions or examples?
# please let us know.
Thanks,
AC
--- D - Comments from Orit Levin
80) 1. Lack of “Interface” concept.
SIP MIB doesn’t use a concept of a physical or logical
“interface” - ifIndex (see RFC 2863 and draft-ietf-entmib-v3).
I think it is a big conceptual flaw because a typical network
application (which a normal SIP device is) has a concept of multiple
network interfaces either directly mapped to physical interfaces or
being logically defined for numerous application reasons.
AI: none
# The authors exchanged a series of emails with Orit at the end of
# March 2004. Below is a summary of our responses.
# In ITU-T, H.341 MIB for H.323 took the route of ifIndex first in the
# early days and they changed to applIndex. This was the motivation
# for the SIP mib to go with ifIndex. Since then, the TRIP mib was
# also drafted with applIndex
# http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-10.txt
# TRIP MIB draft 10 has passed IETF Last Call and is in the RFC ed
# queue. We think we are consistent with the use of the RFC2788 mib.
# Orit is ok with our explanation and trust the mib doctor would raise
# this as an issue. Comment closed
Usually most of the information for configuration, management and
monitoring needs to be defined per “interface”. The most obvious
examples include: timers, retry counters and security parameters.
If a certain implementation doesn’t have a concept of interface
– a single “dummy” interface can be used across all MIB
definitions for this simple device.
Note that the concept of “application” and the concept of
“interface” are orthogonal – in many network devices
both are used.sipProxyAuthMethod
I suggest adding “ifIndex” as the second index
after “applIndex” at least to the following tables:
sipPortTable
sipExtMethodSupportedTable
sipCommonCfgTimerTable
sipCommonCfgTimerExtMethodTable
sipCommonCfgRetryTable
sipCommonCfgExpiresMethodTable
sipCommonCfgExpiresStatusCodeTable
sipUACfgSipServerTable
81) 2. sipPortTable
I find this table a little strange. May be I didn’t understand correctly
its meaning and use – so, please, read the following comments and
correct me where I am wrong.
The most important comment about this table is that it should be per
“interface” (as the second index).
# Per response to comments #80 and #82, we have indexed this
# sipPortTable with application index (applIndex) and not ifindex.
# no action on this part of the comment.
In addition, I don’t like the bitmap definition of the transport layer.
In my opinion, first should be the transport protocol (as the third index)
and afterwards its supported listening port number(s).
# Now that we've gone only with a receive port in that table, the
# bitmap def is justified and useful become it reflects the capability
# of a system to receive sip msg via tcp or udp or tls or a
# combination.
What is the meaning of sipTransportSnd? If required – the listening
port of a corresponding server should be used instead.
# sipTransportSnd is deleted - agreed.
I believe that we need a table (may be a separate one) to define
(ranges of) allowed RTP/RTCP ports as well.
# There's an RTP MIB and we believe we should not be mixing media and
# sip information objects in the SIP protocol MIB.
------------------------------------------------------
82) 3. Type of an arbitrary SIP device/application.
The type of an arbitrary SIP application/device is defined in the
following places:
sipEntityType in sipCommomCfgEntry (currently it is not even a
“bitmap”) and applName in applTable
AI: done.
# Great comment.
# We've defined a new textual-convention named SipEntityRole (BITS
# syntax so that a SIP entity may have one or more roles) and used
# it for sipEntityType in the common mib.
I also strongly recommend adding the same “type of service”
to the sipUACfgSipServerTable.
# yes. We've added a sipUACfgServerFunction object in the
# sipUACfgServerTable that uses the same object TC type.
All the definitions above MUST be coordinated (preferably being
of the same type) and must have the meaning of a bitmap – allowing
for any combination of simple types being defined simultaneously.
# yes, done per your comment. Thank you again for pointing this out.
------------------------------------------------------
83) 4. sipUACfgSipServerTable (now named sipUACfgServerTable)
Orit wrote:
> Wouldn’t it be more flexible to use SIP URI instead of the
> InetAddressType (with default value ipv4) in order to specify
> a SIP server?
# For sip UA, we added the sipUACfgServerFunction in that table to
# indicate the type of server (which could not be provided via a URI).
# Per your comment, we removed the defval ipv4.
# The authors still would like to use a server address rather than URI
# based on the management tools built to handle InetAddress types.
# (and if it is a SIP URI for a server, doesn't it become more of an
# academic question since the hostname of the SIP URI is all that
# really matter)?
In addition, the application type per SIP server needs to be added.
# yes, done with sipUACfgSipServerFunction
May be it is possible to rename the table to sipUACfgServerTable?
# yes, good suggestion - done.
------------------------------------------------------
84) 5. sipExtMethodSupportedTable
From the SIP MIB:
“The sipExtMethodSupportedTable is the main table for listing
all of the extension methods supported by a system. The table is
informational in nature and populated by the system. Entries
cannot be added or deleted by a SNMP manager. The other extension
method tables in the MIB are augmentations of this table.
The other extension method tables defined in the SIP-COMMON-MIB
are: sipCommonCfgTimerExtMethodTable, sipCommonCfgRetryExtMethodTable,
sipStatsExtMethodTable, and sipCommonStatsRetryExtMethodTable.”
As a result, NONE of the fields of the augmentation tables can be
read-create as defined for both SipCommonCfgTimerExtMethodTable and
sipCommonCfgRetryExtMethodTable.
AI: done
# SipCommonCfgTimerExtMethodTable and sipCommonCfgRetryExtMethodTable
# have been deleted.
------------------------------------------------------
85) 6. Statistics Tables
The “ifIndex” needs be added to the statistics tables. In
my opinion, it will make the information retrieved from these
tables more useful.
# We use the applIndex (ifIndex is not appropriate, see response to
# comment #80). The whole MIB is based on SIP entity applications
# (with no particular ties to interfaces).
# We exchange an email with Orit on this matter. No action.
I think that in general the SIP MIB has too many counters.
Especially the summary counters need to be calculated by the
management application (if needed) – not by the management agent.
# The number of counters has been reduced in general.
# Some of the stat tables have been reduced in term of the number of
# objects (sipStatsExtMethodTable, no more ext. method table).
# The sipStatusCodeClassesTable was removed, it had a significant
# number of counters.
# There are only 5 summary counters:
# SipSummaryStatsEntry ::=
# SEQUENCE {
# sipSummaryInRequests Counter32,
# sipSummaryOutRequests Counter32,
# sipSummaryInResponses Counter32,
# sipSummaryOutResponses Counter32,
# sipSummaryTotalTransactions Counter32
# }
# we decided to keep the above 5 counters.
To summarize, I would recommend having fewer counters but each
counter per-interface.
AI: none
# We use the applIndex (we do not have ifIndex). See comment #80no action taken.
------------------------------------------------------
86) 7. “Expires” configuration
Why does the “Expires” header, unlike other headers, have
a dedicated group? (There are additional headers that may need
to be configured as well such as “Max-Forwards”,
“Retry-After” and, in future, new headers are possible.)
I find strange the definition of the sipCommonCfgExpiresMethodTable.
The meaning of “Expires” is very different for different
methods. Separate sub-applications will generate/process INVITE
and REGISTER – so why put them into a common table and then
define a bitmap to access each method information separately?
In addition, SUBSCRIBE also uses the “Expires” header.
Therefore, the table needs to be easily extensible for future use.
My preference would be to have a table that augments the existing
standard and extension method tables for each header that requires
special (usually per method!!!) configuration.
# The sipCommonCfgExpiresMethodTable was deleted per Cullen's comment
# #31. As for the extension of such a table to include other
# parameters, we could always augment an existing method table in the
# future as needs arise.
In that regard, the definition of the sipCfgExpiresStatusCodeTable
is a good example.
# yes and btw, we have now dropped all the per method specific objects
# to move towards tables that rely on method ids (more extensible),
# method ids based on some IANA registry.
The only question about this table: why does it
need to be read-create?
# The sipCfgExpiresStatusCodeTable was also deleted based on Cullen's
# comments.
The application needs to present all the
return codes it supports with default values to a management system.
The manager needs to have means to change the values, but usually
he/she can not “inject” new status codes (if unsupported before
by the application).
# agree, had we kept the table, your point would have been integrated.
------------------------------------------------------
87) 8. UA MIB – UA’s basic configuration information.
The information about the UA itself - such as its AOR and
possible contact(s) - is missing. Are contacts always
automatically generated by the UA based on its server’s info?
AI: open, good suggestion to be addressed in draft09
# Postpone to draft09 since such a new contact table would need some
# more work & agreement.
------------------------------------------------------
88) 9. Lack of Security definitions.
In general it is not recommended to transfer any security
information over the network. Saying that, in the global
network, it is required to be able to learn about the way
a SIP entity can be accessed with details beyond just a SIPS
URI support (not including passwords, of course). We may define
the parameters in MIB and recommend using SNMPv3 or we need
to explain how to achieve this otherwise.
AI: none
# per standard IETF MIB boiler plate, section 1 describes the
# Internet Standard Mgmt framework. SNMPv3 is strongly recommended by
# default through rfc3410 and its subsequent links for security
# reasons in particular.
# see http://www.ops.ietf.org/mib-boilerplate.html
# In addition, inside the SIP MIB doc, in section 10, security
# considerations, we state:
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the
objects in this MIB module.
It is RECOMMENDED that implementers consider the security features
as provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
# So we think we are covered. Is there any special text you would want
# to change or add based on the above?
------------------------------------------------------
89) 10. sipRequestUriHostMatching in sipCommonCfgTable
Does this parameter have much sense for a proxy?
Shouldn’t it belong to a UA configuration?
AI: done
# per Cullen's comment, we decided to remove the object as it does not
# make sense for a server or UA.
------------------------------------------------------
90) 11. sipURISupportedTable
What does it mean “to support URI” for a UA?
Does this table belong to a common SIP MIB?
AI: done
# see comment #27 from Cullen and our response. Deleted.
# issue closed.
------------------------------------------------------
91) 12. Empty groups
It is not a good practice to have empty placeholders with
certain names for future use. I would either remove, rename
“for future use”, or deprecate the sipRedirCfg,
sipRedirStats, sipRegCfg, and sipRegStats.
AI: done
# sipRegCfg and sipRegStats are being used. The other "empty
# placeholders have been deleted from draft 08 (some were already
# removed in draft07.
------------------------------------------------------
92) 13. sipFtrSupportedTable
Please, describe the exact format of the sipFtrSupported
of SnmpAdminString. Provide the pointer(s) to the RFC(s)
that define these feature names.
AI: done
# The sipFtrSupported is now called sipOptionTagTable and the option
# tags are defined by IANA per RFC 3261 and
# http://www.iana.org/assignments/sip-parameters/.
# please take a look at the new def in draft08.
------------------------------------------------------
93) 14. sipExtMethodSupportedTable DESCRIPTION
An editorial suggestion:
"This table contains a list of extension methods supported
by each SIP entity in this system. These are in addition to
the BASIC [WAS standard] set of SIP methods PRESENTED [WAS
discussed] in Section 7.1 of RFC 3261. Any additional
STANDARD methods that WILL [was MAY] be incorporated into
the SIP protocol WILL [was SHOULD] be represented by this
table without any requirement to update this MIB…"
AI: done
# We have deleted the extension method tables per cullen's comments.
</orit levin>
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip