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

["Gunnar Hellstrom" <[e-mail]>]

Roni,

You say:
"you can say that text in not realtime since it takes me
a long time to type"
Typing a character is instantaneous. In real time text as it is done
with RTP in RFC 4103 it is sent in ral time. As soon as you have typed
and transmitted two or three characters the receiver can start building
an idea of what you are about to type. Very similar to voice. The
listener builds up an idea of what you are about to say while the sounds
keep coming in.

You should not start thinking of sentence-wise messaging as soon as you
see the word "text". There is a very useful real-time usage of text. In
text messaging, where you collect a whole sentence before transmission,
you get the problems of one waiting anxiously, and the other being
stressed and have the feeling of typing slowly. Confusing double
postings easily appear. Real time text with transmission at least every
300 ms solves all these problems.

Could you imagine a voice telephone system building only on voice
messaging? No, the real time mode of each medium is needed.

When we added real time text to H.320 ISDN Multimedia protocol, we made
it as an extension to H.224, because of its similarities with FECC in
need of an intermittently used real time channel. So, I still claim that
the two applications: Real time text and far end camera control have a
lot in common. For H.323 and SIP we made a separate RTP-stream for real
time text ( now RFC 4103), but some vendors carried over the H.224 idea
for text transmission to the H.323 world. That gave them text
compatibility with H.320 and through MCU:s, but created
incompatibilitites with the standardised way of transmitting real time
text in H.323. So, I understand and support the reasoning behind
bringning in an RTP-carried H.224 for FECC. ( And I hope no one intend
to use it also for text as happened in H.323 )


Sorry for this side-track from remote camera control. Now back.
I definitely realize the value of real time transmission of the real
time camera control signals. Especially the signal to stop camera motion
needs to be transmitted with very short delay. One possible alternative
to RTP would be server-free use of MSRP, but I see more problems than
gains with that.

Regards
Gunnar

-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On
>Behalf Of kae
>Sent: Friday, August 05, 2005 2:21 AM
>To: 'Even, Roni'; 'Gunnar Hellstrom'
>Cc: 'IETF AVT WG'
>Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt
>
>
>Roni,
>
>But the slow response of camera makes the slight advantage of using RTP
>irrevalent. That is what I was saying in the previous email.
>If we can make
>camera move very fast. I will agree with you.
>
>Kae
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Even,
>Roni
>Sent: Thursday, August 04, 2005 5:21 AM
>To: kae; Gunnar Hellstrom
>Cc: IETF AVT WG
>Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt
>
>Kae,
>I want to point out that real time has nothing to do with the
>time it takes
>the camera to move, you can say that text in not realtime
>since it takes me
>a long time to type. The realtime here is that you need to see
>the change in
>the picture in real time.
>Roni
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of kae
>Sent: Thursday, August 04, 2005 12:12 AM
>To: 'Gunnar Hellstrom'; Even, Roni
>Cc: 'IETF AVT WG'
>Subject: RE: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt
>
>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:[e-mail]]
>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
>-------------------------------------------
>Gunnar Hellstrom
>Omnitor AB
>Renathvagen 2
>SE 121 37 Johanneshov
>SWEDEN
>[phone]
>Mob: [phone]
>www.omnitor.se
>[e-mail]
>--------------------------------------------
>
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]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,
>>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: [e-mail] [mailto:[e-mail]] 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
>>[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
>
>
>_______________________________________________
>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