RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt

["Even, Roni" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt