[Sipping] Comments on SIP Telephony Device Requirements, Configuration and Data

[Henry Sinnreich <[e-mail]>]

The draft 

http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt

 has received comments kindly provided by Denise Caballero-McCan(Cisco),
Yaron Scheffer (Personeta), Sanjoy Sen(Nortel), Ed Elleson (Lboard),
Jiri Kuthan (iptel), Jean Brierre (WorldCom), Adrian Louis
(Profile-ICT), Brian Rosen (Marconi), Gunnar Hellström (Omnitor AB),
Eric Tremblay (Mediatrix), Franz Edler (UTA Telekom AG), Banibrata Dutta
and Subir Saha (Hughes). There were also e-mails on the SIP Forum list
on SIP devices. 

The authors propose to edit version 01 based on these comments, in time
for the 57 IETF; with the objective of issuing an informational RFC on
BCP for SIP devices. The BCP will reflect the implementation and user
experience from a large number of SIP phones and PC clients deployed.

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA
 
____________________________________________

- In Sec. 4, I would expect DHCP to be a MUST protocol. Also, please
specify for some of the protocols (HTTP, DNS) whether client support,
server support or both are required.
- Sec. 5.3.1: the DNS A record implies manual configuration of the
server's DNS name (FQDN). It is also confusing that you recommend DNS
support, and then go on to mention "magic" IP addresses for the server.
- Emergency URL: just "sos", without the "sip:" and "@domain"
ornamentation, is probably more useful to lay users. I suppose many
phones would translate the URL automatically. Can it be made a MUST?
- Sec. 6.5.1, ILBR Codec: the referenced document is missing, or
expired.
- Sec. 8, Services: support in the devices does not imply support in the
proxies, so it is not a sufficient condition for deploying these
services. Based on the experience with IN, I believe services should NOT
be standardized. But this section should mention this distinction.
- Sec. 10, Security: use of SIP REFER opens up a number of large
security issues. Please mention them in this section. Although REFER
nominally requires positive user action at the UA, this is not the case
with current implementations. Thus, disabling REFER through
configuration should probably be a SHOULD - at least.


1. Section 4 under MUST support..  Given that there is little market
demand 
for TCP on our hard Phone clients I think this should be changed to 
may.   Adding TCP support will eat into valuable memory that can be
better 
used for features such as WEB Browsing, etc.

2. Section 4 - Does NTP mean _ Network Timing Protocol?

3. Section 5.3.1 - Not clear to me why Manual configuration needs to be
by 
a web Browser.. I think this should read... SIP devices must support
manual 
configuration, this configuration may be my means of a web browser.

4. Section 6.4 - I think this is a product differentiator and should not
be 
a must... for example, why should we have to support audio mixing for 
conference calls in a low end residential phone or the ATA device if the

market does not demand it.

5. Section 9.1 -  This seems a little two specific... buttons for 
initiating call set ups may be labeled dial, talk, etc... in addition
you 
may have voice activated calling... perhaps this section is better 
re-written to say that a mechanism to "Correct mistakes" should be 
supported...and a mechanism by which the user can initiate the call set
up 
should be provided...

6. Section 9.1.3. This is a little confusing..earlier in the document it

says that either 911 or sos calling should be supported, but this
section 
sounds like you need to support both which could be very confusing to a 
"panicked' user...

7. Section 11 - I think defining SNMP as should in most cases, including

high-end devices, is over kill.. in addition... high end-devices is a 
nebulous term... you could fix this by use may instead of should.


Requirements for SIP device/service configuration process:

OP-Req) The client SHOULD be able to perform remote operations on
configuration data, e.g., - upload, insert, modify, fetch, search. This
list of operations is not exhaustive.

ERR-Req) Adequate error codes MUST be supported for various types of
transaction failures as a result of performing these operations - such
as, 'server failure', 'authentication required', 'search failed' etc.
This list of error codes is not exhaustive.

CAP-Req) It SHOULD be possible for the client to provide its device and
service capability/preference information to the configuration server in
an extensible and flexible manner. This may be required by the server to
determine the appropriate provisioning data for the client depending on
the device capabilities. Examples of such information include vendor
name, device type, video enabled, supported protocols for download of
provisioning data etc. 

MULT-Req) It MUST be possible to request for different configuration
profiles associated with a single device. For example, different users
hosted on a SIP device may have different profiles.

DIS-Req) Disconnected operations MUST be supported. This implies the
need to track changes in configuration data.

REL-Req) Reliable transport of a large amount of data MUST be supported.

EFFC-Req) Means for efficient transport of large amount of configuration
and capability information SHOULD be supported. This is particularly
important for low bandwidth wireless links.

AUTH-Req) The client MUST be able to perform remote operations on
configuration data securely. The framework MUST support adequate access
control of user profiles through proper authentication of clients
attempting to perform operations on provisioning information. The
provisioning server SHOULD be authenticated by the client.

PRIV-Req) The framework MUST support adequate confidentiality of
configuration data of the user.

EXT-Req) The protocol MUST be easily extensible

EASE-Req) Text based protocol encoding is preferable for ease of
interpretation, implementation and extensibility.


The immediate need that prompts me to request that such a document be
agreed to and advanced by the sippiing wg is that we at our company have
experienced problems on our own internal sip network due to problems
with the SIP registration behavior of certain end user devices.  

Here is the problem we have noticed:  

If a group of sip end devices loses connectivity with their SIP
registrar, due to, for example, an enterprise taking their firewall out
of service for several hours to do an upgrade over the weekend, we find
that certain end devices do not continue to try to register after
network connectivity to the registrar has been restored.  These devices
follow the sip spec in timing out their registration attempts, which is
fine.  However, at an application level, these devices should
re-initiate the registration process after, say, an hour, and every hour
thereafter, to see if network connectivity to the registrar has been
restored.  Without this application level behavior, what we have found
is that when people come in to use their phones after a network outage,
they find that they cannot receive phone calls unless they reboot their
phones.  Not all devices have this problem, but a sufficient number of
devices do, that it would be valuable to describe in a BCP what the
expected end device behavior should be for functions like this.  

Please consider this a vote in favor of working on and advancing a BCP
on appropriate end user sip device behavior. 


You may want to add some BCP recommendations. Particularly, I would like
to see a push on phone vendors "Do, really do implement SRV fail-over,
so that if a primary server fails, a backup server will be used".
Otherwise, service reliability is threatened.


Integrated Switch/Hub SIP devices designed for wired Ethernet SHOULD
have an uplink port such that another IP device, such as a personal
computer, MAY share the network connection. SIP clients MUST prioritize
the transmission of RTP traffic over the shared network connection. 

comment 1: 
Wish you would remove the Hub reference since this is a shared collision
domain concept which I do not recommend for sip client that has real
time requirements sharing this shared Ethernet environment with a host
device that may also have real time data on the same hub. Switch is the
only way to go since ethernet HUB collisions between 2 devices can
effect throughput

"IP Requirements IP-1: SIP telephony devices MUST be able to acquire an
IP address by: Automatic IP address configuration using DHCP, or Manual
IP address entry from the device. "

Comment 2 
Why did you not reference RFC3361 DHCP option for sip
ftp://ftp.rfc-editor.org/in-notes/rfc3361.txt this a great MAY RFC to
support for sip clients to learn SIP proxy servers

Comment 3 
No mention was made of support for Visual and Hearing Impaired Special
Equipment or even RFC3351 ftp://ftp.rfc-editor.org/in-notes/rfc3351.txt

Comment 4 
You mention management but only for provisioning, why can we not have
SNMP v3 support for network LAN statistics, SIP traffic stats or even
RTCP info on the SIP phone.


> it would be interesting to see if SIP phone manufacturers think this
is
>OK for any type of SIP device, or only for certain devices, such as SIP
>telephony adaptors that support key sets. I believe it makes sense only

>for latter. Opinions?

I agree!  SNMP v3 support for network LAN statistics etc. might just
about make sense for SIP telphony adaptors, but it is unlikely that you
would convince SIP telephone manufacturers of the need for such support
in their products.


I think it makes sense for any network device.  I'm not sure how far I
would go, but our network management systems want to know the devices
that are out there, and have the basic info any device gives you.

Certainly we've been asked by customers for tools that network
management can use to determine what is happening when users say "I got
a call, but I couldn't hear them".  We've offered syslogs and they got
amused.  

I'll admit that my "sipphone" engineers think this is silly.
My customers beg to differ.

I think the only thing there is to discuss is:
	How much info is available
	Are there alarms/traps

And, of course, it MUST be SNMPv3


SIP-xx, analogue text support: SIP adapter devices (for analog phone
lines)
  MUST support conversion between real time text transmission using RFC
2793 [y]
  and text telephones according to ITU-T V.18 [x] allowing alternating
use of
  text and voice. SIP clients MUST fallback to G.711 if RFC2793
connection fails.


SIP-zz, digital text support: SIP telephone devices MUST support
  real time text conversation using RFC 2793 [y] for the text stream.
  It MUST be possible to use text simultaneously with voice.



---------------------------------------------
In 4.11 Ringer Behaviour  : add the section below for the purpose of
deaf, hearing impaired, deaf-blind people and people in the garden and
noisy
locations:

SIP Telephony devices MUST provide an external interface to
an external alerting system.



Add to References
-----------------
[y] G. Hellstrom: "RTP Payload for Text Conversation.", RFC 2793, IETF,
May 2000. [z] ITU-T Recommendation V.18 "Operational and interworking
requirements for DCEs operating in the text telephone mode", November
2000 with amendment November 2002.


  SIP-2, DNS SRV: SIP clients MUST t support RFC2782 [3] and MAY 
  support the SIP service examples [4] for basic PBX-like or Centrex-
  like functions.  SIP clients MUST support DNS SRV for locating a SIP 
  Server. When making a SRV query, the client MUST t use the DNS 
  additional information in the response that contains the IP addresses 
  for the A records. 
     
  If the DNS additional information is not present, the client MUST 
  make DNS A record queries to resolve the hostnames.

[EricT]
I suggest referencing RFC 3263 (Locating SIP Servers) in the above
section. I don't know what services are being referred to when saying
"and MAY support the SIP service examples [4] for basic PBX-like or
Centrex-like functions.".  This section is about DNS SRV, but I found
nothing in the latest SIP Services Examples draft about DNS SRV...


  SIP-3, Do Not Disturb: SIP clients MUST be able to set the state of 
  the client as Do Not Disturb.  Clients MUST respond to new INVITES 
  with a ô486 Busy Hereö.  Clients MUST respond to re-INVITES on 
  existing call legs as normal behavior [4]. 

[EricT]
I suggest rewording to something like "It must be possible for the SIP
device user to configure the device state to Do Not Disturb. ...", as it
is generally the user that sets the DND state ;)

  SIP-4, call hold resume: SIP clients MUST be able to place a call on 
  hold/resume [4].

[EricT]
Should it focus on the usage of RFC 3264, with the use of a=sendonly
instead of c=0.0.0.0? Also with a focus that the answer does not
automatically comes with a "held" sdp? I suggest adding something like
"SIP clients MUST follow RFC 3264 when placing a call on hold. More
specifically, the a=sendonly attribute MUST be used. The SDP answer of
SIP clients that are being placed on hold MUST NOT contain "held" SDP,
unless the user session was originally on hold."

  SIP-7, message waiting indicator: SIP clients MUST support SIP 
  message waiting  and an indicator for integration with voicemail 
  platforms [5]. 

[EricT]
This is kind of hard, since there is not RFC yet for this and different
vendor/integrators are using different draft versions which sometimes do
not interoperate.  Should maybe add a note to this effect... Maybe
something like "No RFC exist yet for this service. SIP clients MUST
implement this service in its RFC form when it becomes available."

  SIP-9, transfer: SIP devices MUST support REFER and NOTIFY as 
  required to support the transfer [6].  SIP clients MAY support 
  escaped headers in the Refer-To: header.

[EricT]
Same problem as SIP-7...  I suggest upgrading the "MAY support escaped
headers..." to MUST, as not supporting this has impact on attended call
transfer.


  SIP-11, attended call transfer: SIP devices MUST support attended 
  call transfer [3], [4].  SIP clients MAY support escaped headers in 
  the Refer-To: header. 

[EricT]
Reference [3] makes no sense here ;) Should probably be [6]. 

  SIP-12, music on hold: SIP devices MUST support music on hold [4]. 

[EricT]
Not sure why this service is a MUST? Maybe in enterprise environments,
but what about homes?


  SIP-15: DTMF RTP payload: SIP clients MUST be able to send DTMF 
  specified by RFC2833 [7].   
   
  Payload type negotiation MUST comply with RFC 3264 [8]. 
   
  Payload type MUST remain constant throughout the session.  For 
  example, if an endpoint decides to renegotiate codecs or put the call 
  on hold, the payload type for the re-invite MUST be the same as 
  initial payload type. 

[EricT]
Should probably refer to RFC 3388. Maybe add "SIP devices SHOULD support
Flow Identification (FID) as defined in RFC 3388."

  SIP-20, reason phrase display: If the ôReason Phraseö of a response 
  message is displayed, the client MUST use ôReason Phraseö in the 
  response packet.  The client MUST not use an internal ôStatus Codeö 
  table. 
   
  Another SIP device MAY respond with ô403 Forbiddenö, or various other 
  messages. 

[EricT]
I am not sure about the above two MUST. Something tells me that the
client could rely on an internal table if there was a problem with
language negotiation...  I don't know what the last sentence means???
"Another SIP device MAY ..." It makes no sense to me...

  SIP-25, Dynamic login/logout for user mobility: SIP devices MUST 
  support user mobility.  SIP clients MUST store a static profile in 
  non-volatile memory so that this information is available during the 
  power up sequence.  SIP clients MUST allow a user to walk up to a 
  client, login, and be able to send and receive calls with his profile 
  information. 
  For emergency numbers (e.g. 911) the client MUST send the credentials 
  (username/password) of the static profile. 

[EricT]
We are developing analog adapters and don't remember receiving such a
request. I suggest either changing the MUST to SHOULD or adding some
text to specify that it is a MUST for devices with the proper interface
to do it and a SHOULD for devices with a limited interface. I know we
could possibly configure this through a web interface, but the point is
that there are a lot of vendore that currently just want to replace the
wire, not the phone and its interface...

  App-5, SIMPLE Integration: SIP devices MUST provide a ôbuddy-
  list/addressbookö and use SIP extensions to leverage presence [21]. 

[EricT]
This also does not applies well to black phones applications. I suggest
changing this to "MAY".


  FW/NAT-2, NAT capable configuration: SIP devices MUST be able to 
  operate behind a static NAT/PAT (Network Address Translation/Port 
  Address Translation) device using the STUN protocol [x22].  SIP 
  clients MUST be able to populate SIP messages with the public, 
  external address of the NAT/PAT device and use specific port ranges 
  for RTP. 
   
  FW/NAT-3, UPnP capable configuration 
  SIP devices MUST be able to operate with a UPnP 
  (http://www.upnp.org/) firewall device. 

[EricT]
I suggest using a MUST on only one of these, and a MAY on the other. I
am not fully aware of all details about these two protocols, but I think
a device could very well work behind a firewall by using only one
mechanism. I think the draft should clearly state which mechanism is
preferred.

As a last point, I suggest splitting this draft into two or more drafts.
One about generic requirements for SIP devices, and one (or more) about
the configuration mechanism along with the data that can be configured.
The first draft could refer the second one.  The draft, as it is right
now, defines basic requirements, then some configuration framework and
its requirement, and then data (and data representation). I don't think
those mix well. Focusing would probably make the documents easier to
maintain ;)


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.


just a comment on SIP-25:

I am currently working on a PSTN - SIP migration concept avoiding to
re-invent all fancy features of the PSTN and in particular to
re-implement all legal/regulatory requirements (emergency call handling,
legal intercept). The concept builds upon a "dual homed" SIP-UA with one
"line" connected to the PSTN via V5 - SIP gateway and the other "lines"
beeing free for all new services of the SIP world. Therefore the
requirement of multiple identities on the SIP side and a static
identitiy on the PSTN side is essential, but I agree, if you are focused
on analog adapters only, this would mean an unnecessary burden. But I
suggest to re-think the migration perspective.

By the way, if anyone is interested in this "dual-homed" PSTN - SIP
migration concept let me know. I am convienced that this means a good
chance for a carrier to migrate towards SIP without heavy investments in
re-inventing what is already existing.


>Can SIP handle simultaneous session as in ...can we transfer a media to

>another sip client and talk to someone else at the same time using the 
>same device?

short answer is yes. longer answer is it depends on the SIP device in
question. SIP devices, s.a. the CISCO, Pingtel phones, have no. of
common, and some differentiating "features". Call park, call hold, call
trasfer are some of the business-line features you'd find in these
phones. These features, are nothing but the application of core-SIP or
some SIP-extentions, in form of an application, much like the
traditional PSTN features and services, both IN & non-IN.

--

From: rishi <[e-mail]>
To: banibrata dutta <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: [Sipforum-discussion] SIP Telephony Device
Requirements,Conf 
iguration andData
Date: Thu, 06 Mar 2003 01:21:03 +0530

Hi folks,
query - Can SIP handle simultaneous session as in ...can we transfer a
media 
to
another sip client and talk to someone else at the same time using the
same device?


Hello Everybody:
Now that the list has got reasonable members, I would like to start the
activities under this working group. To start with, we should brainstrom
on what we can do in this area. My guess is that the Draft authored by
Henry Sinnreich et. al.  [
http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt]
is a good starting point for our discussions. Also we should follow
similar activity started in H323 forum and elsewhere. Lets start...

_________________________________

Thanks, Henry 

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