[Sipping] Unofficial communication from ITU-T on T.38
Glenn Parsons <gparsons@nortelnetworks.com> Thu, 14 March 2002 21:04 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00752 for <sipping-archive@odin.ietf.org>; Thu, 14 Mar 2002 16:04:26 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07778 for sipping-archive@odin.ietf.org; Thu, 14 Mar 2002 16:04:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05713; Thu, 14 Mar 2002 15:37:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05683 for <sipping@ns.ietf.org>; Thu, 14 Mar 2002 15:37:00 -0500 (EST)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29907 for <sipping@ietf.org>; Thu, 14 Mar 2002 15:36:56 -0500 (EST)
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2EKaIY03487; Thu, 14 Mar 2002 15:36:18 -0500 (EST)
Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GTWL3RHX; Thu, 14 Mar 2002 15:36:17 -0500
Received: from [192.168.0.200] (zrchh234.us.nortel.com [47.102.144.6]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQSZHR3X; Thu, 14 Mar 2002 15:36:16 -0500
User-Agent: Microsoft-Entourage/9.0.1.3108
Date: Thu, 14 Mar 2002 15:35:06 -0500
X-Sybari-Space: 00000000 00000000 00000000
From: Glenn Parsons <gparsons@nortelnetworks.com>
To: sipping@ietf.org
CC: jf.mule@cablelabs.com, jieying.li@ivoxnetworks.com
Message-ID: <B8B673A9.9436%gparsons@nortelnetworks.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3098964907_76380"
Subject: [Sipping] Unofficial communication from ITU-T on T.38
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
X-BeenThere: sipping@ietf.org
Folks, I am not sure if the official communication from ITU-T SG16 on T.38 has been sent/received on what is now draft-ietf-sipping-realtimefax-00.txt (it was draft-mule-sip-t38callflows-02.txt. ) As a result, in order to ensure that the group is aware of this before the meeting next week, I have attached a copy of the communication below. Cheers, Glenn. _____________________ COMMUNICATIONS STATEMENT TO: IETF SIPPING WG APPROVAL: Agreed to at SG16 meeting (Geneva, 5-15 February 2002) (proposed) FOR: Action DEADLINE: April 2002 CONTACT: Mr. Tom Geary Rapporteur Q14/16 Tel:+1 949 483 4092 Fax:+1 714 446 9642 E-mail : tom.geary@conexant.com _____________________ 1. Introduction At the ITU-T SG16 held 5-15 February 2002, the facsimile experts of Q14/16 had the opportunity to review the proposed call flow examples of draft-mule-sip-t38callflows-02.txt. We have a number of general and specific comments that we would like to present. 2. General Comments Q.14/16 is interested in collaborating with the SIPPING WG on the T.38 SIP call flows work. We would appreciate if future comments on this Internet Draft could be copied to our experts mailing list to allow ITU-T fax experts an opportunity to comment. The group¹s mailing list is: tsg16q14@itu.int Also, Q.14/16 would like to point out that at our meeting held 5-15 February 2002, a revised Recommendation T.38 was consented (similar to IETF last call). As well as fixing minor issues, this revised Recommendation incorporates all of the pieces of T.38 into one document. If it is approved (that is, no negative technical comments are received), this Recommendation will be available on the ITU-T website in May 2002 at the following URL: http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-T .38 IANA has finally registered the requested T.38 SDP extensions. They can be viewed at: http://www.iana.org/assignments/sdp-parameters. Note, however, that the addition of the image/t38 MIME type is still in process as it requires the approval of an RFC documenting the registration (see draft-parsons-itu-t38-reg-00.txt ). Q.14/16 would like to suggest adding the call flows of this Internet Draft to Rec. T.38. Unfortunately, the ITU-T process will not allow the referencing of a non-Standards Track¹ IETF RFC in an ITU-T Recommendation. As a result, we would suggest referencing this document in a future informative Appendix to Rec. T.38 (similar to the current Appendix describing H.248 call flows). We note from the SIPPING WG status web page that the intent is to include call flows for modems over IP (MoIP) in this document. V.MoIP is currently under study in Q.11/16 (the group¹s mailing list is: tsg16q11@itu.int). As this work is expected to be significantly different, Q.14/16 recommends that SIP call flows for MoIP be detailed in a separate document. It would make sense in this separate document to describe the SIP call flows of V.34 half-duplex T.38 as well as V.MoIP as both will require V.8 control signal analysis for call discrimination. This would allow the immediate publication of the current draft for the benefit of the industry. 2. Specific Comments We reviewed text on call discrimination in section 4. We agree with this process for pre-V.34 implementations. As a result, the section title should indicate ³and fax detection up to V.17 (14400bps)². SG16 is currently working on extensions to T.38 to support V.34 fax, as well as a new Recommendation to support modems over IP. We therefore suggest that the following sentence be added to the end of section 4.1.: Note that V.34 half-duplex fax (up to 33600bps) over T.38 will require use of more complex call discrimination methods that will require analysis of V.8 control signals (that are also used for V.34/V.90 data). An Amendment to Rec. T.38 to support V.34 fax, as well as a new Recommendation V.MoIP to describe data modem over IP are under study in ITU-T SG16. Further, we confirm that fax detection (of V.21 flags) by the receiving gateway is the preferred method. This was our original intent and we have modified Rec. T.38 section D.2.2.4 to reflect that. In addition , we have also indicated that both voice and fax¹ and fax replaces voice¹ modes are possible. We note that you recommend fax replaces voice¹ and would be interested in understanding the rational for this choice. In section 4.4 (and at least example 6.2) it is indicated that when falling back to pass-through¹ mode several characteristics should be followed. You should note that Q.11/16 is defining specific characteristics for a pass though mode in V.MoIP that is called voice band data¹. For your information, the current definition in V.MoIP is: For Voice Band Data (VBD) mode of operation, the path between G1 and G2 remains in a voice configuration. The modem signals are encoded using an appropriate speech codec suitable for the task and the samples are transported across a packet network. VBD should: o Use a voice codec that passes voice band modulated signals with minimal distortion. o Have end-to-end constant latency. o Disable Voice Activity Detection (VAD) and Comfort Noise Generation (CNG) during the data transfer phase. o Disable any DC removal filters that may be integral with the speech encoder used. o Be capable of tone detection, including mid-call DTMF, as well insertion of tones, announcements, voice prompts etc. VBD should consider the appropriate application of: o The use of echo cancellers on a VBD channel. o Forward Error Correction (FEC) (e.g. RFC 2733) or other forms of Redundancy (e.g. RFC 2198). o Voice packet loss concealment techniques and algorithms that may not be suitable for VBD. While SG16 agrees that G.711 is a valid codec that can be used for this, we are concerned about your the choice of enabling the echo canceller. You will note that we have not made a recommendation for enabling or disabling echo cancellation in VBD. In T.30 transmission, however, echo cancellers may be turned off (by the appropriate answer tone) for a more effective fax transmission. Hence there are varying perspectives on the most applicable setting for echo cancellation amongst ITU-T fax and modem experts. We would appreciate understanding your rationale for this recommendation. In addition, you should note that the presence of adverse network conditions (notably jitter and delay) will have a significant effect on whether the fax connection will be successful. Section 5.1 indicates that the T.38 Annex D is a temporary document this is incorrect. T.38 Annex D should be introduced earlier in this document. However, in this case, we suggest that a more appropriate description would simply delete everything after the comma: The mechanism for supporting T.38 in SIP & SDP is detailed in T.38 Annex D [9]. In section 5.2, contrary to section 4.1 (and the terminology of Rec. T.38), the term terminating gateway¹ is used instead of receiving gateway¹. The document should be consistent and use the terms emitting gateway and receiving gateway (as defined in Rec. T.38) throughout. In section 3.1 and before F11 of section 5.2.2 and 5.3.2 it notes that the CNG (and other tones including V.21 flags) can be sent in-band. You should note that CNG and these other tones sent in-band in any codec besides toll quality codecs¹ like G.711 A or mu-law (and especially in compressed codecs) will not be recognizable by the receiving fax machines. This should be explained in the text. In section 7 (and in many of the examples in section 5), values of 0¹ are given to the boolean SDP attribute names. This is incorrect, the attributes are defined as boolean without values. That is, their presence on an a= line indicates that they are true for the session. As a result, this informative table requires modifications. Further, many of the examples will also need modification. For example, the SDP in the first example in section 5.1.2 should be: F1 INVITE I.FAX UA -> PROXY INVITE sip:+1-650-555-2222@obelix.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ifax.here.com:5060 From: sip:+1-303-555-1111@ifax.here.com;user=phone;tag=ab111 To: sip:+1-650-555-2222@obelix.wcom.com;user=phone Call-ID: 1717@ifax.here.com CSeq: 17 INVITE Contact: <sip:+1-303-555-1111@ifax.here.com> Content-Type: application/sdp Content-Length: 320 v=0 o=ifaxgw1 2890846527 2890846527 IN IP4 ifax.here.com s=Session SDP c=IN IP4 ifaxmg.here.com t=0 0 m=image 15002 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval a=T38FaxTranscodingMMR a=T38FaxTranscodingJBIG a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:72 a=T38FaxMaxDatagram:316 a=T38FaxUdpEC:t38UDPFEC a=T38FaxUdpEC:t38UDPRedundancy _____________________
- [Sipping] Unofficial communication from ITU-T on … Glenn Parsons
- Re: [Sipping] Unofficial communication from ITU-T… Allison Mankin
- [Sipping] SIP authentication problem when using R… John W Noerenberg II
- Re: [Sipping] SIP authentication problem when usi… Jari Arkko
- Re: [Sipping] SIP authentication problem when usi… Niemi Aki (NET/Espoo)
- Re: [Sipping] SIP authentication problem when usi… Jari Arkko
- Re: [Sipping] SIP authentication problem when usi… Greg Rose