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

From: "Even, Roni" <[email-masked]>
Date: Wed, 3 Aug 2005 09:58:26 +0300

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
kae
Sent: Wednesday, August 03, 2005 6:17 AM
To: Even, Roni
Cc: 'IETF AVT WG'
Subject: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt

Roni,

I am not sure if we should continue using Annex Q for FECC particular in
SIP based systems. My concerns are:

1. Adding a new RTP stream will make NAT/FW traversal more difficult
than it is today even with helps from ICE/STUN/TURN. 

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. 

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)

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?

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

This is my humble opions. 

Kae

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

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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 3 Aug 2005 10:30:53 +0200

Roni and Kae,

Your discussion on transport of FECC takes analog turns as the
discussion on real time text does.
Real time text is defined for RTP transport in RFC 4103. It has its MIME
type text/t140.
In a video call there may be long moments when the participants just use
video and audio, and thus there is no traffic in the text stream. But
when someone types it should be transferred in real time, and it can
occasionally be substantial amounts of text being transmitted.

It is sometimes proposed that we should multiplex text in the audio
channel. In the early beginning of the discussions it was also proposed
to send it in the call control channel.

The result has always been that it is clean and according to SIP
architecture to have the text as a separate RTP stream. In reality there
are the risks and problems you mention with FW/NAT traversal. Not much
though. Proper SIP aware NAT routers tend to keep the path open without
a need for keep-alive traffic.

I would like to see the NAT/FW traversal discussions take this kind of
intermittent media in account and not close paths on timeout because of
lack of traffic during sessions.
And I agree with Roni that intermittent use of connected RTP sessions is
a proper way of handling this kind of real time need.

Regards
Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Even, Roni
>Sent: Wednesday, August 03, 2005 8:58 AM
>To: kae
>Cc: IETF AVT WG
>Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt
>
>
>Kae,

---

From: "kae" <[email-masked]>
Date: Wed, 3 Aug 2005 17:11:32 -0400

Gunnar,

FECC and T140 over RTP are different. One is control message and one is
medium. 

I also want to point out that since camera moves very slow (they are
mechanical driven), we really do not need real time control for FECC. 

Kae

-----Original Message-----
From: Gunnar Hellstrom [mailto:[email-masked]] 
Sent: Wednesday, August 03, 2005 4:31 AM
To: Even, Roni; kae
Cc: IETF AVT WG
Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt

Roni and Kae,

Your discussion on transport of FECC takes analog turns as the discussion on
real time text does.
Real time text is defined for RTP transport in RFC 4103. It has its MIME
type text/t140.
In a video call there may be long moments when the participants just use
video and audio, and thus there is no traffic in the text stream. But when
someone types it should be transferred in real time, and it can occasionally
be substantial amounts of text being transmitted.

It is sometimes proposed that we should multiplex text in the audio channel.
In the early beginning of the discussions it was also proposed to send it in
the call control channel.

The result has always been that it is clean and according to SIP
architecture to have the text as a separate RTP stream. In reality there are
the risks and problems you mention with FW/NAT traversal. Not much though.
Proper SIP aware NAT routers tend to keep the path open without a need for
keep-alive traffic.

I would like to see the NAT/FW traversal discussions take this kind of
intermittent media in account and not close paths on timeout because of lack
of traffic during sessions.
And I agree with Roni that intermittent use of connected RTP sessions is a
proper way of handling this kind of real time need.

Regards
Gunnar

>I am not sure if we should continue using Annex Q for FECC particular 
>in SIP based systems. My concerns are:
>
>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.
>
>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)
>
>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 
>(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?
>

---

From: "kae" <[email-masked]>
Date: Wed, 3 Aug 2005 17:15:45 -0400

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: [email-masked] [mailto:[email-masked]] 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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of kae
Sent: Wednesday, August 03, 2005 6:17 AM
To: Even, Roni
Cc: 'IETF AVT WG'
Subject: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt

Roni,

I am not sure if we should continue using Annex Q for FECC particular in SIP
based systems. My concerns are:

1. Adding a new RTP stream will make NAT/FW traversal more difficult than it
is today even with helps from ICE/STUN/TURN. 

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

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)

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?

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

Kae