RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt
"kae" <k.hsueh@comcast.net> Fri, 05 August 2005 00:43 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0qJD-0007qn-Hn; Thu, 04 Aug 2005 20:43:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0qJB-0007qb-VH for avt@megatron.ietf.org; Thu, 04 Aug 2005 20:43:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19863 for <avt@ietf.org>; Thu, 4 Aug 2005 20:43:32 -0400 (EDT)
Message-Id: <200508050043.UAA19863@ietf.org>
Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0qqB-0004RH-9h for avt@ietf.org; Thu, 04 Aug 2005 21:17:39 -0400
Received: from lining (pcp02403314pcs.reston01.va.comcast.net[68.84.10.31]) by comcast.net (sccrmhc12) with SMTP id <2005080500432301200pc52ee>; Fri, 5 Aug 2005 00:43:23 +0000
From: kae <k.hsueh@comcast.net>
To: "'Even, Roni'" <roni.even@polycom.co.il>
Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt
Date: Thu, 04 Aug 2005 20:43:24 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcV7R/olOsc1rsf/QCK+/d+ny5Qk5AB78D3ABqfZ1pAAB79UkAAedZUgABlLHjAAH6SEsA==
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C0224B400@IsrExch01.israel.polycom.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Content-Transfer-Encoding: 7bit
Cc: 'IETF AVT WG' <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Roni, What I mean FECC is a control protocol is FECC is a device control protocol which does not imply I suggest we have to use SIP. You are right I did not directly comment on draft-ietf-avt-mime-h224-02.txt itself since it only covers the MIME type registration. But do you mean we will redefine a new payload type? But this draft did mention AnnexQ and h224, right? It actually implies the whole implementation, right? I actually have less concern about the payload type or the MIME type registration. But I am more concerned about if we should continue follow H.323 path which is famous for hard to passing NAT/FW. I have seen too many bugs in H.323 ALG. So my recommendation is maybe we need to expand the scope a little bit more. The MIME type registration should come at the end of protocol development. BTW, I spoke to a tele medicine expert. He told me they never move camera and he also said even the local camera is too slow not to mention the far end camera. Kae -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Thursday, August 04, 2005 5:19 AM To: kae Cc: IETF AVT WG Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt Kae, You looked at my general comment on the purpose of the contibution but please look at my in line comments in my response. 1. Adding a new RTP stream will make NAT/FW traversal more difficult than it is today even with helps from ICE/STUN/TURN. RE: I agree that every RTP stream needs to traverse NAT/FW, so are you suggesting we will not use more than one media in a call? BTW even if we open a different control channel for FECC (Using FECC in the signaling path, see your comment 4) we will have a channel signaled by SDP that will need to traverse FW/NAT 2. From security point of view, we do not want to open too many ports. In additions, FECC is general used a couple times during a video call. Most of time there are no packet flows. Most of NAT/FW will close the channel after 1 min of inactivity. RE: The FECC channel can be opened only when there is a payload to send by using re-invites or kept open by having keep alive. This is general procedure and will work if the FECC is in a separate control channel or as H.323 annex Q payload. As for number of open ports, this is a general problem. There was a suggestion to multiplex streams by SSRC which did not progress. In a multimedia conference you may have 1 audio, 2 video and a data connection for each call not including the signaling. 3. I think we should keep the principle that RTP is for medium not for control. If we allow non real time traffic to use RTP, it will make QoS more difficult. A lot of devices are marking DiffServ Code Point based on RTP. If we start to use RTP for non-real time stuff, QoS devices will have to look into payloads which is not scalable. (Please note that we cannot trust end point's DiffServ marking) RE: The contribution is not defining a payload type but just a MIME type for H224. BTW FECC is real-time traffic and that is why it should go end to end. The feedback is based what you see in the received video so real-time is very important. 4. Using Annex Q/H.224, it makes certain architecture assumptions. I think the medium processing function and call control/feature functions should be separate either logically or physically. Given the fact that control paths do not use RTP. This draft will break this principle (except the case controller and media processor are physically the same) and ask the medium process to process FECC functions. Do you think it will be easier just send a SIP based message to the controller directly? RE: FECC is not call control, carrying it using SIP is wrong since we will use the real-time needed. You expect to see the result of the movement fast. This is why you are trying to move the camera. The signaling path is not the way for it. Example of FECC usage that is common is for tele medicine where doctor watch an operation from remote and they control what they see. (You do not want the operating doctor to stop and move the camera). -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of kae Sent: Thursday, August 04, 2005 12:16 AM To: Even, Roni Cc: 'IETF AVT WG' Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt Roni, I do not understand this. Even it goes through gateway, from IP end point's view, it is still IP. I know any changes will increase the coding efforts for existing H.323 device vendors but a better protocol will reduce the total adoption time. I really hate to see the industry spends so much in the lab trial and testing. That is my experience. Kae -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Even, Roni Sent: Wednesday, August 03, 2005 2:58 AM To: kae Cc: IETF AVT WG Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt Kae, Thanks for the comments, I want you to note that the h224 mime type is defined for having interoperability with current video conferencing terminals through a gateway. It does not define a payload. This will enable a signaling gateway to work since the FECC will flow end to end. The payload is described in H.323 annex Q and not in this specification. We intend to look for other ways for FECC and are open to suggestions. As for your questions see online Roni _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] Comments on draft-ietf-avt-mime-h224-02.txt Magnus Westerlund
- [AVT] RE: Comments on draft-ietf-avt-mime-h224-02… Even, Roni
- [AVT] Re: Comments on draft-ietf-avt-mime-h224-02… Magnus Westerlund
- Re: [AVT] RE: Comments on draft-ietf-avt-mime-h22… Tom Taylor
- RE: [AVT] RE: Comments on draft-ietf-avt-mime-h22… Even, Roni
- RE: [AVT] RE: Comments on draft-ietf-avt-mime-h22… Even, Roni
- [AVT] Comments on draft-ietf-avt-mime-h224-02.txt kae
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… Even, Roni
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… Gunnar Hellstrom
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… kae
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… kae
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… Even, Roni
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… Even, Roni
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… kae
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… kae
- RE: [AVT] Comments on draft-ietf-avt-mime-h224-02… Gunnar Hellstrom