Subject: [Sipping] RE: [Sipforum-discussion] SIP Telephony Device Requirements, Configuration and Data

From: "Eric Tremblay" <[email-masked]>
Date: Wed, 26 Feb 2003 11:41:01 -0500

Hi Henry,

Here is a somewhat lengthy email with a few comments about the SIP Telephony Device Requirements draft:

  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 ;)

I might come back later with more comments on configuration/data.

Best Regards,

EricT

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Monday, February 10, 2003 9:49
To: 'Jörgen Björkner'; [email-masked]
Subject: [Sipforum-discussion] SIP Telephony Device Requirements,
Configuration and Data

For everyone interested SIP phones and other SIP communication devices,
and the 56 IETF  coming next month, please see if you like or dislike or
don't care about the draft:

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

The idea is to have discussions on the lists, and if there is interest
and rough consensus to move ahead with an informational RFC. Would
appreciate your comments to 

[email-masked] , and also to

[email-masked] 

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA

_______________________________________________
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