Subject: [Sipping] Comments on draft-sinnreich-sipdev-req-00.txt (long)

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Feb 2003 16:16:47 -0500

I've looked through this draft and have several comments.

SIP-8, local dial plan:
  I'm unhappy with requiring a local dialing plan.
  Many of my customers wish to force all calls through the
    local proxy

SIP-13, client-based conferencing: 
  I don't know what the sentence "SIP devices MUST be able to 
  support handset based conferencing" means.  I understand the
  next sentence.  Are you proposing that each handset follow
  the SIP conferencing requirements?  If not, what, exactly,
  is the requirement?

SIP-15: DTMF RTP payload
  I'm confused why this is a MUST.  If the device only supports
  G.711 or better (i.e. no low bandwidth, highly compressed) codecs,
  why is it a requirement to generate 2833?

SIP-22 through SIP-26, multi-line support
  I'm having problems with the terminology.  "Multiline" to me
  means the ability to handle more than one call at a time (all but
  one on hold).  Here you mean "multiple users on the same UA"
  I think the requirements are okay (at MAY), but we need
  a new term that really means multiple users registered at one UA.

  I'll note that there is a possible problem with our basic standards.
  To allow multiple users at the same UA, the UA, the registrar and
  the incoming proxy all have to support such a thing.  There is no
  way for the UA to know if that is possible.

SIP-24, multi-line call waiting indicator
  I don't understand "If call waiting is set for an identity, the 
  client MUST respond with "486 Busy Here" when an incoming call 
  to that identity is received and the client has an existing 
  call with any of the identities"

  Are you disallowing the possibility of more than one waiting
  call for an identity?  How else do I understand "call waiting
  is set"?

SIP-25, Dynamic login/logout 
  I disagree with the architecture assumption made here.  I think
  emergency calls should NOT depend on any kind of authentication.
  Thus, I think it should not be necessary to register before
  making an emergency call, and thus there is no need for a default
  identity.  

  Specifically, if your proposal was implemented, and, for whatever
  reason, authentication failed, and a user could not make an emergency
  call, I think someone is in DEEP doo-doo.

  I think we need some convention for identity (ie what is in the From)
  to aid law enforcement in tracking malicious calls to emergency
  centers, but, please, don't depend on authentication.  As far as I
  know, emergency centers would rather get some "anonymous" calls than
  miss a call because someone configured something wrong.

SIPsec-2 password protection
  I dislike this requirement.  I think the problems it generates outweigh
  the security it provides.  Specifically, to make this work, you have
  to put a default password in the device, so you can get in the first
  time, and you need some kind of a reset function when people forget
  the settings.  The former almost always gets left in this state, which
  opens up a huge attack, the latter always eventually gets known, and
  exploited.

  Our systems have VERY limited configuration done at the terminal -
  basically, just how you get an IP address.  Everything else we store
  on a server and download.  This works well for us, and putting a password
  on the IP settings is just not justified.

SIPsec-4, INVITE user portion acceptance
  You don't have the corresponding output requirements - SIP devices must
  have a setting that forces all outbound messages to a specific proxy.
  This is a clear requirement for many operators.

International-1, language support
  I have a very minor problem with "The setting for this header MUST 
  be provisioned".  My problem is that it could be interpreted as
  disallowing a separate language preference for each user who is
  registered when multi-user support is provided.  We certainly would
  not provision the PHONE with language.  We would have a user profile
  setting for this.

App-2, hold ring-back
  Do you expect the phone to send any SIP message when it starts to
  ring?  Maybe you should say what you expect.

App-5, SIMPLE Integration
  I think this is not well specified.  SIMPLE has so many possible
  variations, I don't see what we say.  I also think there is no
  "address book" spec yet, and specifically, an address book may
  have many more addresses in it than you get presence for.

Web-1
  I object to this requirement.  We provide a very nice
  UI on our device to specify things like ring tones and forwarding
  preferences.  It happens that we also have a web UI that can do this,
  but we really don't need it.  I'll note that the wording is
  awkward.  The first sentence says "SIP devices MUST support a web server",
  while the second sentence says "Web pages ... MAY be [in] ..centralized 
  web servers"  The latter is more correct than the former.

Web-2
  Object in that not all such settings make sense to be remotely settable.
  Forwarding behavior may be, ringtones may not be, at least with respect
  to a user.

FW/NAT-1, outbound proxy support
  I think this is too tightly specified.  Specifically, I think the
  device needs to accept an outbound proxy.  It must be configurable
  to always use this proxy, and for each user, there must be a full
  uri that may or may not be in the same domain as the outbound proxy.
  There is no need to explicitly know the domain; you need to know the
  URI.  It may be that your implementation affixes a registration name
  to a default domain.  Ours doesn't.  We authenticate with a username
  and then return an AOR.  I think that is quite reasonable.

  That means the first MUST (default domain) can go away.

Int-1: (buttons)
  I would not want this to be interpreted as requiring any specific
  hard buttons.  Any/all of these could be in some soft UI.

Int-3 
  There are several paragraphs after the first one in Int-3 that I
  can't make any sense of.  Is some of it supposed to be an Int-4?
  
  The fragment "End user options..." is not a sentence.

Lines-1 This requirement gets confused with the prior multi-line
  section above.  Consolidation and terminology change is needed.

Section 3
  First of all, at least at the moment, there is no SIP mechanism to
  do any of this, and I suspect it won't be a sip mechanism that
  does it, although it could be a form of PUBLISH.  So, I think 
  using terms like "User Agent" is incorrect.  Perhaps use Profile 
  Server and Profile Client.

  There are several cases where the word "may" became "MAY"
  inappropriately.  

  I also think there are "device profiles" that are associated with
  a particular UA, "user profiles" that are associated with a particular
  user, and a hybrid, where there is a profile for a particular
  user at a particular device.  These need names, we need a name
  for any of them, and the text has to be edited to use the
  correct one of these.

  I have some problems with:
    Change Notification is the means by which the profile server tells 
    the user agent that profiles of interest have changed.  Typically, 
    the intention would be for the user agent to get those changes or the 
    updated profiles.  

  My problem is that this is a database, the terminal may change it,
  or an external web accessed page may change it.  In the former, the
  device has to inform the database that it is changed.  In the latter,
  the database has to inform the device that it is changed.  Both of
  these are change notifications.

OpenExt-1: and OpenExt-2: are the same.
  I think extensibility of the data object is more important than
  "intelligence" at the server, whatever that means.

ENR-5:
  Also is needed to support multiple users on the same UA.

CN-3: 
  Could we have some justification for this?  I'm not objecting
  to a MAY, I want the device to MAY support a scheduled change.

SEC-n
  I have some problems with authentication, because I envision this
  to be close to the first thing you do after you have an IP address.
  The device is either provisioned with, or learns the profile
  server from DHCP.  It contacts it first, before any registration,
  ....  You don't have a lot to authenticate either end with, except
  the aforementioned password which I think is worse than nothing.
  
Section 4
  I am confused over what this intended to be.  Are we talking about
  settings that are made manually at the device, not covered by
  a device profile described in Section 3?  I personally think we should
  be minimizing such things.  Right now, ideally, I think you learn
  the profile server from DHCP and get everything from that except the
  IP address/mask stuff that you also get from DHCP.  It's a tossup
  whether you learn the sip proxy from DHCP or the profile server.
  You certainly shouldn't be having a "Session Timer" setting that
  doesn't come from the device profile.

  Also has the confusion on the term "line"

  There is a typo in the chapter number in the first sentence.

Network-2
  We should be clear whether we intend this wording to imply you have
  more than one setting, or whether there is one setting and it is
  applied to both media and signalling.  I think there are potentially
  many settings, one for each media type and one for signalling.

Dial-1: Dial Plan. 
  I object.  We SHOULD recommend a "Dial" button and not rely on
  a dial plan.  A dial plan should at best be a MAY.

Regional-4: 
  I recognize that some sites will not support DHCP.  DHCP should
  be the preferred way to find the time server.  The text should say
  that.  If you don't have DHCP, it has to be provisioned, and thus
  we need this in the list, I just think its use should be discouraged.
  
Phonebook-1:
  The text seems to not allow a phonebook to be stored on the profile
  server.  It should allow that.  The problem is the word "stored".

PhoneServers-1:
  I don't understand why you would encourage phonebooks to be stored
  in someplace other than the profile server.  I can see some difficulty
  in storing history there, although we would do it that way.

4.11 Ringer Behavior  
   
  The text "These devices SHOULD ignore all line related settings 
  that do no affect the default outbound line settings they receive"
  has a typo, and it confuses how "default" should work.  They are
  line settings.  There is a default line.  It should state something
  like "... all line settings other than the default line's settings"

  The last paragraph of this section should be deleted.  It doesn't
  help, and it ignores the most common choice of ringtone selection
  by caller.

4.12 User Related Settings
  This text is very confusing to me.  I'm certainly agreeable to supporting
  multiple users registered at a UA.  I'm interested in supporting
  multiple call appearances per user (or per UA if you prefer, they are
  the same as long as you don't restrict one user to a SINGLE appearance)

  The picture you seem to have is a physical or UI button per line,
  and you want to assign a user to a line.  Okay, if that's what you
  want as long as I can assign more than one line to one user.

  Our system works a bit differently but the effect is the same with
  regard to allowing multiple users registered at one UA, and multiple
  call appearances per user.

  The only thing I can make out of this text is that you want to be
  able to have some prior configuration that has some default association
  between a line button and a user.  While we wouldn't do that, I understand
  that such a facility may be useful for some vendors.  The text is far
  from clear about that, if indeed that is what you meant.

  Roaming means that a user walks up to a phone and does something that
  causes him to be registered.  In your picture, it causes one or more
  line buttons to be associated with him.  That isn't a configuration
  mechanism, that's a run time dynamic assignment mechanism.  Registering
  on a UA may cause a new user profile to be downloaded, I get that,
  but this section is on device configuration, as best I can figure out,
  and this text doesn't make much sense to me here.

4.13 Line Related Settings 
  
  Another very confusing section for me.  My problem is that I don't see
  a 1to1 correspondence between a "line" and an address of record.
  The whole "line" concept is POTS specific.  There are users and there
  are call appearances.  You can have one or more users, and each user
  can have zero or more call appearances.  Each user has an AoR, but
  you can have more than one active call at this AoR at a particular
  device.  

  It could be that if you changed "line" to "registered user", the text
  could make some sense, but it might need more work than that.
  You clearly don't have a separate registration if a user has more
  than one "line" in your sense of "line"; The first call to the user's
  AoR would show up on his first "line", the second would show at his
  second "line".  There doesn't have to be any knowledge of this in
  anything except the device.  There doesn't have to be a URI for each
  line.

4.16 through 4.20
  These are, or should at least have the option to be, PER USER settings,
  not per device settings.  I'm having a little conflicting views
  problems, because we implement these things in the proxy server
  not the device, but we're having some problems with the idea of 
  "ring once then forward".  Generally, we think that forwarding
  behavior is best done at the server since you have to do it anyway
  when the user is not logged in.  On the other hand, not all servers
  will do that, and so maybe requiring the phone to be able to do
  it may be necessary.

I did not review sections 5 and higher.

Brian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Feb 2003 16:47:38 -0500

>   why is it a requirement to generate 2833?

It's a lot easier if you don't have to recognize DTMF from tones. (Doing 
reliable DTMF recognition is surprisingly tricky; in particular, it's 
hard to do this without a full reconstruction of the audio signal, i.e., 
playout delay compensation.) Thus, it seems silly to waste CPU resources 
on the client to generate a sine waveform just waste more of them trying 
to detect which one it was on the ACD server or gateway. It's trivial to 
implement 2833 sending, so is there a reason *NOT* to require it?