Subject: Re: [AVT] draft-basso-avt-videoconreq-00: H.245 and Section 7.8

From: Nermeen Ismail <[email-masked]>
Date: Fri, 24 Oct 2003 11:19:41 -0700

>I am concerned about the potential direction the requirement stated in 
>section 7.8 may bring us.  Here is the text:
>
>   7.8 Interoperability with other protocols
>
>       The codec control transport protocol MUST allow inter-operability
>       with the most commonly deployed IP-based video communication
>       protocols, such as H.323, H.324 and H.324M.
>

It needs rewording. The intent was that to make sure that if we are to use 
one of the existing IETF protocols to carry these commands that
there can be a way to inter-operate with the H.323 systems (i.e. build 
gateways) without breaking other usages of
that specific IETF protocol.

nermeen

>What does this mean.  On one level, it sounds straightforward.  If I have 
>a video system, and you have a video system, then we should be able to 
>communicate.  In fact, given a lexicon, how could one NOT create mappings 
>between different grammars for that lexicon?  In that sense, this is a 
>non-requirement and should be removed.
>
>However, at another level, and taken in conjunction with the statement of 
>section 6.3 (protocol duplication), it is hideous.  Direct 
>interoperability means that we should take the common signaling 
>denominator for these three protocols, namely H.245.
>
>H.245 sound innocent enough, as it is independent of H.323 and 
>H.324.  However, when one looks closer, we find a lot of overlap between 
>H.245 and SDP and (please look at the protocol) SIP.
>
>I would offer that if H.245, or something like H.245, is what is being 
>thought of for this requirement, then there is no reason for this 
>draft.  Use H.323/H.324/H.324m/H.320 and Be Happy.
>
>If there is any requirement that should be in the document, it is an 
>emphasis on Section 6.2.  I would offer that the call control and content 
>negotiation capabilities of H.245 "break" SIP and SDP (or conversely, 
>would not interoperate in the ITU direction).  Since this is the IETF, I 
>really only care about not breaking IETF protocols.  You can break the 
>broken protocols to your hearts content :-)
>
>
>
>_______________________________________________
>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: Nermeen Ismail <[email-masked]>
Date: Fri, 24 Oct 2003 16:28:49 -0700

>draft.  Use H.323/H.324/H.324m/H.320 and Be Happy.

Would rewording the statement from:
"
The codec control mechanism SHOULD NOT duplicate the functionality
       of existing protocols."

to :
"
The codec control mechanism SHOULD NOT duplicate the functionality
       of existing IETF protocols."

calrify the text?.

6.3 intent is to say that if thre is already an IETF protocol that can be 
used for the transport of these commands then we should do that
rather than come up with a new different protocol. Putting it bluntly if 
RTCP is not going to be used as the transport mechanism then
there should be good reasons for that.

I think so far the options are:
- Use RTCP with the AVP feedback extensions and create new payload-specific 
FB messages for things that are missing such as pictureFreeze etc.
- Use a different protocol (TBD) to carry these 
contrl/feedback/notification messages and use SDP to initiate it. It would 
take such a sad sad
   person to suggest H.245 to be that protocol :-).

It is time for a draft that looks at which one is a better go and makes a 
concrete proposal.

nermeen

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 26 Oct 2003 17:22:47 -0500

Comments in-line.

> -----Original Message----- From: Nermeen Ismail [mailto:[email-masked]]
> Sent: Fri, October 24, 2003 7:29 PM

Sounds good.

> It is time for a draft that looks at which one is a better go 

I don't see it as an "either/or" choice.  Rather, both work.

RTCP makes sense for FastVideoUpdate.  The connection (RTCP) already exists in the right direction, it is media related, and the RTCP connection is often connected to the codec.

That said, another option, like a TCP control m= line, has LOTS of advantages.  It is reliable, works for implementations that don't connect RTCP to the encoder or decoder (depending on direction), and fits in to the "IETF Framework."  As an example, check out the use of the m= line in speechsc.

This mechanism makes sense for the forward-direction commands, like FreezeFrame.