Subject: [Sipping] FW: New Version Notification - draft-sinnreich-sipdev-req-05.txt

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 21 Jan 2005 14:12:40 -0500

The IETF Last Call that was announced for draft-sinnreich-sipdev-req-04 should be considered to apply to this new, -05 version of the draft.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: ID Tracker [mailto:[email-masked]]
> Sent: Friday, January 21, 2005 10:57 AM
> To: [email-masked]; Peterson, Jon
> Subject: New Version Notification - draft-sinnreich-sipdev-req-05.txt
> 
> 
> 
> New version (-05) has been submitted for 
> draft-sinnreich-sipdev-req-05.txt.
> http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-05.txt
> 
> 
> 		
> 

_______________________________________________
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: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 26 Jan 2005 17:49:41 +0100

It is very positive that the sipdev-req-05 is in last call. I see it as a good harmonising
factor that will increase opportunities for interoperability and common functionality for
the benefit of all users.

I have some minor proposals for edits for consistency.

I have aligned the change proposals to the recently issued version:
http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-05.txt

Most of the proposals relate to Req-55 requiring Interactive text support.
Therefore in places where actions for audio is described, it is also valid to mention
the text medium.

Proposals:
1-----------------------------------------------------------------------
Current wording:
Req-22: SIP telephony devices MAY support device based 3-way calling
               by mixing the audio streams of at least 2 separate calls.

Proposal because 3-way calling is valid for text and audio:
Req-22: SIP telephony devices MAY support device based 3-way calling
               by mixing the audio streams and displaying the text of at
               least 2 separate calls.
2----------------------------------------------------------------------
Current wording:
Req-36: SIP telephony devices SHOULD support conferencing services
               for voice [48], [49] and if equipped with an adequate display
               MAY also support presence [50].

Proposal because conferencing is valid for text and audio:
Req-36: SIP telephony devices SHOULD support conferencing services
               for voice and interactive text [48], [49] and if equipped
               with an adequate display MAY also support presence [50].
3-----------------------------------------------------------------------
Current wording in the Note in section 3.9 connected to REQ-52:

Note: SIP telephony devices supporting Instant Messaging based
               on SIMPLE [50] support text conversation based on blocks of
               text. However, interactive text conversation is often
               preferred here due to its interactive and more streaming-like
               nature, thus more appropriate for accessibility.

Proposal because the importance and characteristics of real time text conversation
needs to be more clearly explained and is essential for emergency services and is a
feature of general usefulness. This text could be moved to be an introduction to section
3.9:

Note: SIP telephony devices supporting Instant Messaging based on SIMPLE [50] support text
conversation based on blocks of text. However, continuous interactive text conversation is
often preferred as a parallel to voice due to its interactive and more streaming-like
nature, thus more appropriate for real time conversation. It also allows for text
captioning of voice for very noisy environments and those who cannot hear or hear well.
Finally continuous, character by character text is what is preferred by emergency and
public safety programs (e.g. 112 and 911) because of its immediacy, efficiency, lack of
crossed messages problem, increased ability to interact with confused person, and the
additional information that can be observed from watching the message as it is composed.

4-----------------------------------------------------------------------
Current wording:
Req-73: SIP telephony devices SHOULD support GSM codecs found in
               various 3G wireless phones.

Proposal because AMR codecs are default for 3G:
Req-73: SIP telephony devices SHOULD support GSM and AMR codecs found in
               various 3G wireless phones.
5--------------------------------------------------------------------------
Current wording:
4.3. Privacy

        Media Encryption
               Secure RTP (SRTP) [41] MAY be used for the encryption of media
               such as audio and video, after the keying information has been
               passed by SIP signaling.
               Instant messaging MAY be protected end-to-end using S/MIME.

Proposal because SRTP is propossd to protect text as well:
4.3. Privacy

        Media Encryption
               Secure RTP (SRTP) [41] MAY be used for the encryption of media
               such as audio, text and video, after the keying information has
		   been passed by SIP signaling.
               Instant messaging MAY be protected end-to-end using S/MIME.
6-------------------------------------------------------------------------------
Current wording:
        [26] S. V. Anderson, et al.: "Internet Low Bit Rate Codec", draft-
        ietf-avt-ilbc-codec-04.txt, IETF, November 2003.

Proposal because this spec is now an rfc:
        [26] S. V. Anderson, et al.: "Internet Low Bit Rate Codec", rfc 3951,
        IETF, December 2004.
7--------------------------------------------------------------------------------
Current wording:
        [27] A. Duric: "RTP Payload Format for iLBC Speech", draft-ietf-avt-
        rtp-ilbc-04.txt", IETF, November 2003.

Proposal because this spec is now an rfc:
        [27] A. Duric et al.: "RTP Payload Format for iLBC Speech", RFC 3952,
        IETF, December 2004.
--------------------------------------------------------------------------------

Regards

Gunnar
-------------------------------------------
Gunnar Hellström
Omnitor AB
+46 8 556 002 03
Mob: +46 708 204 288
[email-masked]
--------------------------------------------

>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of Peterson, Jon
>Sent: Friday, January 21, 2005 8:13 PM
>To: [email-masked]
>Subject: [Sipping] FW: New Version Notification
>-draft-sinnreich-sipdev-req-05.txt
>
>
>
>The IETF Last Call that was announced for draft-sinnreich-sipdev-req-04 should
>be considered to apply to this new, -05 version of the draft.
>
>Jon Peterson
>NeuStar, Inc.
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 27 Jan 2005 01:28:04 -0600

These are very useful comments and are mainly due to the progress of ToIP
work in the IETF and also to the emergence of the iLBC as RFCs, all during
the work on our I-D on SIP Telephony Devices. We plan to make the proposed
changes. 

Thanks, Henry

Henry Sinnreich
MCI
1201 E. Arapaho Rd./Office 1020
Richardson, Texas 75081
USA

-----Original Message-----
From: Gunnar Hellstrom [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2005 10:50 AM
To: [email-masked]; Peterson, Jon
Cc: Henry Sinnreich
Subject: RE: [Sipping] FW: New Version Notification

It is very positive that the sipdev-req-05 is in last call. I see it as a
good harmonising factor that will increase opportunities for
interoperability and common functionality for the benefit of all users.

Most of the proposals relate to Req-55 requiring Interactive text support.
Therefore in places where actions for audio is described, it is also valid
to mention the text medium.

Proposals:

Proposal because the importance and characteristics of real time text
conversation needs to be more clearly explained and is essential for
emergency services and is a feature of general usefulness. This text could
be moved to be an introduction to section
3.9:

Note: SIP telephony devices supporting Instant Messaging based on SIMPLE
[50] support text conversation based on blocks of text. However, continuous
interactive text conversation is often preferred as a parallel to voice due
to its interactive and more streaming-like nature, thus more appropriate for
real time conversation. It also allows for text captioning of voice for very
noisy environments and those who cannot hear or hear well.
Finally continuous, character by character text is what is preferred by
emergency and public safety programs (e.g. 112 and 911) because of its
immediacy, efficiency, lack of crossed messages problem, increased ability
to interact with confused person, and the additional information that can be
observed from watching the message as it is composed.

        Media Encryption
               Secure RTP (SRTP) [41] MAY be used for the encryption of
media
               such as audio and video, after the keying information has
been
               passed by SIP signaling.
               Instant messaging MAY be protected end-to-end using S/MIME.

        Media Encryption
               Secure RTP (SRTP) [41] MAY be used for the encryption of
media
               such as audio, text and video, after the keying information
has
		   been passed by SIP signaling.
               Instant messaging MAY be protected end-to-end using S/MIME.
6---------------------------------------------------------------------------
----
Current wording:
        [26] S. V. Anderson, et al.: "Internet Low Bit Rate Codec", draft-
        ietf-avt-ilbc-codec-04.txt, IETF, November 2003.

Proposal because this spec is now an rfc:
        [26] S. V. Anderson, et al.: "Internet Low Bit Rate Codec", rfc
3951,
        IETF, December 2004.
7---------------------------------------------------------------------------
-----
Current wording:
        [27] A. Duric: "RTP Payload Format for iLBC Speech", draft-ietf-avt-
        rtp-ilbc-04.txt", IETF, November 2003.

Proposal because this spec is now an rfc:
        [27] A. Duric et al.: "RTP Payload Format for iLBC Speech", RFC
3952,
        IETF, December 2004.
----------------------------------------------------------------------------
----

Regards

Gunnar

>The IETF Last Call that was announced for draft-sinnreich-sipdev-req-04 
>should be considered to apply to this new, -05 version of the draft.
>
>Jon Peterson
>NeuStar, Inc.
>
>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: "Brian Rosen" <[email-masked]>
Date: Fri, 28 Jan 2005 13:11:12 -0500

In the emergency section, there are two issues I'd like some consideration
on:

1. If a call is an emergency call, the phone should not react to "hang up"
stimuli, but should wait for the far end to send BYE.  Even if the phone
handset is placed back on its hook switch the call should remain connected
to the PSAP.

2. If the phone interprets a dial plan (that is, it always emits a real
telephone number/extension/service initiation) rather than relying on
another element, such as a proxy server to do it, then it should interpret
the local emergency number (9-1-1/1-1-2) to the sos@localdomain.  The
problem with this is that we don't yet have a mechanism to learn the local
emergency phone number.

Should strength on both of these is appropriate I think.

Brian