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

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. 

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)

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?

This is my humble opions. 

Kae

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt